Recap and Lessons on Research Software Localization from February Talk

How does software written in one language come to be available in other languages? And how is this process, known as localization, different for research software? Those were key questions adressed by Christopher Hertweck’s talk delivered on February 24th, 2026 online.

To begin, Christopher briefly introduced us to the use of SketchEngine, a web-based tool for compiling and analysing linguistic data collections (so-called corpora, or in singular corpus). SketchEngine exists both as a commercial product and an open-source variant, NoSketchEngine, with somewhat reduced functionality. The localization from English into German was done by a team of students as part of an internship project supervised by Lexical Computing (the company behind SketchEngine), and myself, Oliver Czulo (then a professor at Leipzig University). During the localization project, the team of students faced various challenges that often occur in localization.

Internationalization addresses various challenges in localization

A common challenge is to keep translations of terminology consistent. Even without the complications of multiple languages, the use of terminology can be inconsistent in the source language used in software development. In a well performed localization, however, this should not affect other languages. In order to keep terminology consistent in their translation work, the team relied on a shared spreadsheet to coordinate between themselves and the open-source tool Weblate that developers at Lexical Computing used to organize localizable strings for translation.

Another common challenge is properly sizing user interface (UI) elements. For example, English tends to be shorter than other European languages, therefore elements designed for English with a small fixed size present the possibility that the best translation will break the UI, or that an unsatisfying compromise needs to be chosen for the translation.

The challenge of concatenated strings occurs when sentences are broken into sub-parts and rejoined with middle bits that change depending on user input or the result of a computation. Since sentence structures across languages can be wildly different, when sub-parts are presented as separate localizable strings, such concatenated strings are often hard to translate in way that would yield a meaningful whole. A good solution is to reformulate sentences leading to concatenated strings with the variable element presented outside of the sentence.

An example of concatenation in the UI, where several syntactic elements are joined. As an additional challenge, the option ‘containing’ is consolidated, i. e. it is used all over the UI and can mean different things in the various contexts, and may thus afford different translations..

On these as on other issues, Christopher made the case that internationalization must happen before localization. Internationalization is a concept in software that asks developers to consider how their design decisions can be adapted to other languages and cultures. This important concept ensures that the process of localization is easier and helps avoid issues in localization that would create new development work.

Consolidated strings and context, context, context!

Another common translation challenge is that of context, where the meaning of a word can be quite different depending on the context in which it is used. For example, the word yes could be meant to confirm a proposed action or be an answer in a range of answer options to a question. The translation of these two meanings could differ for some target languages. This becomes a challenge if yes is a consolidated string—words that are used all over a UI but only appear once as a localizable string, so that only one translation can be proposed. In the case of SketchEngine, the words all, any and none were presented as consolidated strings, however, these words do not have only one uniform translation into German.

One of the problems is that German has three grammatical genders, so for all, any and none, their default translation (i. e., the first option that would typically show up in a dictionary) will change in form depending on the noun they modify. On top of this, the word any may have at least two different translations into German depending on whether it should mean at least one or no matter which in the given context.

Furthermore, negation does not always work the same way as in English, so in places where a simple none works in English, there may need to be a different syntactic structure in German, potentially colliding with the order of UI elements. Ideally, there would have been multiple localizable strings for these words separated based on their linguistic context. In the end, the translations alle (plural), ein beliebiges (‘an arbitrary’) and keine (plural) where chosen, with only minimal potential for disruption of the syntactic structures.

Research terminology

In research, we approach our work through a tradition or school of thought. By committing to certain terminology when producing or localizing software, we contribute to its propagation. On top of this, when translating these terms, we cannot trust that such traditions or schools of thought are mirrored in different linguistic communities, resulting in an additional challenge.

One example can be found in electrical engineering and computer technology, where culturally loaded words such as master have seen various suggestions for renaming. In this vein, the need to mirror its various meanings in different contexts became apparent. For instance, master does not carry the same implications in master branch vs. master device, where the latter implies control over other devices. The various proposals for renaming have introduced conceptual distinctions that had not been previously made and, to this date, do not seem to be uniform even within English. In translation to German, the newly introduced terms may meet different traditions in terminology, some English-leaning, others more rooted in German tradition, adding to the overall challenge. Metaphors also usually fall into this category of challenge. They are highly prevalent in all types of research terminology.

In the localization of SketchEngine, the prime example of a research terminology challenge is the function that gives its name to the whole tool. The word sketch function computes which words and their grammatical functions co-occur for a given query word; i. e., using the word sketch function for a verb like search would display typical subjects, objects and other syntactic elements that co-occur with search in the corpus at hand. A term such as distributional analysis would highlight the quantitative nature of the analysis whereas the term colligation analysis has strong roots in grammatical models of language. By using this product-specific term, the makers of the SketchEngine avoided the dilemma of choosing one of the many competing terms for this kind of corpus analysis.

Translators can do more than just translate

During his summary of all the challenges the team encountered, Christopher pointed out that translators can do more than just translate as part of the localization. The linguistic quality assurance (QA) can extend to the first language in which the software was produced, addressing quality issues that may hinder translation. The iterative nature of the localization process positions translators to perform QA not just linguistically, but also in terms of the UI design and user experience. Last but not least, the glossary that is produced by translators constitutes a valuable resource for the owners of the localized software, helping to inform future localization efforts and representing a structured knowledge resource of key concepts.

The talk ended with an open question period where various other aspects of software localization were brought up by translators, software designers, and researchers. The concept of internationalization was of particular interest to the Translate Science core contributors as an important design consideration with regard to shared software infrastructure and research objects (especially those considered modular) that seek to be more multilingual.


OpenEdition suggests that you cite this post as follows:
Oliver Czulo (March 3, 2026). Recap and Lessons on Research Software Localization from February Talk. Translate Science. Retrieved March 14, 2026 from https://transci.hypotheses.org/219995


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.