Five Developers’ Pain Points of E-Commerce Localization

We explain some major pain points of an E-Commerce localization process and how to potentially overcome those challenges.

At ePages we offer our customers a cloud-based online shop software in about 15 distinct languages. As an internationally operating company, it is core part of our business to consider translating and localizing our software, while developing new features.

E-commerce software localization might seem like a straightforward matter, yet it arises quite a few challenges in a developer’s day-to-day business. We as ePages developers work in a full-stack javascript environment with Node.js and React. Regarding our e-commerce software localization we are using several i18next modules. In the following we describe our five pain points that arise due to our international focus and localization necessity.

1. Considering Text Decorations

In order to keep translating and localizing our e-commerce software into another language as simple as possible, it is important to keep sentences within one only translation string and not to fragment them into different ones by adding links, symbols, 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 as 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 to fragment 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.

2. 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 to figure 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 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.

3. Prepare UI For Long Texts

One of the mayor pain points that needs to be considered regarding e-commerce software localization is the difference in length and density of all the languages we translate our software to. Considering 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 fancy layout, it is always more important to respect usability.

4. Right Moment To Start Localizing

The big question is: When is the right moment to consider software localization when developing a e-commerce 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 and recommendation we gathered from our initial difficulties is to add comments to the source code when starting to develop. This could for instance be a comment such as “#i18n” or alike, which indicates that this text block is still to be translated and easy to be 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.

5. Coordination With Translation Agency

A potential challenge we’ll 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 be 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 the web-based translation management system PhraseApp, because the translators could work in the PhraseApp 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 an e-commerce 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 take-away from this post is to take into account localizing a shop software from the very beginning in order to avoid lots of work afterwards.

Comments