5 Key Developers’ Pain Points in Ecommerce Localization

At ePages, we offer customers cloud-based online shop software in about 15 languages. As an international company, it is at the core of our business to consider translating and localizing our software while developing new features. Ecommerce localization might seem like a straightforward matter, yet it arises quite a few challenges in a developer's day-to-day business. As developers, we work in a full-stack JavaScript environment with Node.js and React. To implement software localization, we use several i18next modules. In what follows, we want to give you an overview of our main pain points arising from our need for international business operation and localization.

Considering Text Decorations

In order to keep translating and localizing our ecommerce software into another language as simple as possible, it is important to keep sentences within one only translation string and not fragment them into different ones by adding links, symbols, or text in bold or alike. In that sense, a specific challenge we're constantly facing is to appropriately place a link within a text block or sentence. If, for example, we aim to place a link within a sentence, then this complicates it for the translator who will find the sentence fragmented into different parts. As we use HTML in our texts, the link syntax then appears in the text and is thus - contrary to intended - not free of code. This arises a major difficulty: the translator needs to not only translate the sentence but also put the link accordingly. Apart from the issue that the translator has to comprehend the code. Yet, the overall aim is for the translator to easily understand the content that needs to be translated. However, this is not given, if the localization source appears with code elements. At the moment, we are resolving this by simply putting the link over the whole sentence. That way, we avoid fragmenting the sentence by putting in code syntax within the sentence. However, this is just a temporary solution, as it is also esthetically unfavorable to tag the whole phrase. In the future, we, therefore, aim to use markdown instead of HTML, which has a simpler syntax and is thus easier to understand for translators.

Static Code Analysis of Missing or Obsolete Translation Keys

Sometimes it remains a somewhat delicate exercise to determine where we added new strings, yet forgot the translation. The question arises whether we actually have a translation for each key. This implies figuring out where we need to translate, but haven't included a translation key yet. When developing new features, this actually needs to be done simultaneously. Static analyses of code could help to report keys that are missing, unused, or obsolete. This brings us closer to the overall aim to have up-to-date and properly running translation keys. However, some translation keys are only put together dynamically when the software is being run. For these special cases, we do not provide a static translation key, but a variable that is put together accordingly during the runtime of the software. Therefore, the static code analysis cannot detect, if these translation keys are obsolete or error-free. At the moment, we are checking on these dynamic translation keys manually. Another possible solution could be to automatically open the pages of the software and look for these keys. However, this would have to be programmed and is thus an elaborate matter.

Preparing the UI for Long Texts

One of the major pain points that need to be considered in ecommerce software localization is the difference in length and density of all the languages we translate our software to. Considering the design aspect, we sometimes wish to find a different esthetical solution than being implemented in the end. Yet, we follow the principle of "design follows function" and in this sense also: design follows UX and wording. In particular, this implies that every design plan needs to be consistent with usability and UI aspects and this calls for compromises. Even if, from a designer's perspective the solution is not ideal, it is always first considered if the new feature or function is easily applicable and easy to understand for the merchant. Therefore, we mostly consider both, German and English, when setting up a new design, as German represents a language of long words and English a language of short words. Again, it is crucial for the designer to be flexible and accept compromises so the layout works in all our shop languages. Although it might be possible to design a fancy layout, it is always more important to respect usability.

The Right Moment to Start Localizing

The big question is: When is the right moment to consider software localization when developing an ecommerce shop software? Of course, the right answer is: from DAY ONE! Nevertheless, we did not create localizable code right from the beginning. And this is what haunted us over a long period of time. Once, a colleague had to go over all our software source code in order to find text blocks that were just directly written into the file instead of putting it in translation keys. Not considering localization when starting to develop is highly time-consuming and requires a few iterations. In our case, we had to go through all the source code in order to find all pieces that still needed to be put in the translation strings. However, this problem is easily avoided, if one uses translation keys instead of putting text directly in the source code. We now only use translation keys to store our text blocks, which we did not do when the development of our software first started. A learning we got from our initial difficulties is to add comments to the source code when starting to develop. This could be, for instance, a comment such as "#i18n" or similar, which indicates that this text block is still to be translated and easily found when the localization process starts. Although, we now fixed the problem by directly working with translation keys, adding comments from the very beginning would have definitely facilitated our work.

Coordination with a Translation Agency

A potential challenge we might be facing in the future is, when we only need to translate the new features. In a project as large as our shop software, our translators are given only the newest translation files that are then merged back into the code. However, this implies that the newly translated files have to be copied back into the original code, which can be quite a hassle. The right place has to be found in the code and this is best done by automatization. Otherwise, this is very time-consuming and unhandy. We now arranged with the translation vendor to always send them all our code, so they can translate within the entire file. We'll see if this comes practical in the future. This, for instance, could be solved by using a translation management system, like Phrase, because the translators could work in the Phrase interface and easily download, translate and update software translations. That way, we would not have a difference between the newly translated terms and the existing code and would avoid the problem of merging translated text back into the code.

Conclusion

In this article, we have seen some major pain points of localizing ecommerce software. Challenges we are currently facing include text decorations that fragment sentences, the length, and density of different languages as well as the proper coordination with the translation agency. An important takeaway is to take into account localizing shop software from the very beginning in order to avoid lots of work afterwards.