Translation Service — how to do internationalization
Imaging you have a product that’s successful in US, now you want to expand your business and gain users from international markets. An important part of your internationalization work would be to translate the whole product interface to some language, and in the future, every string that a developer wants to put to production needs to be translated to different versions.
You may have a translator team responsible for that or there might be a third-party translating company to do works for you. However, your engineers feels annoyed that they’ll need to collect their new strings, email translators their requests, urge translators to prioritize their requests, and update their branch with newly translated strings. Sometimes it makes them mad if translators mistakenly translated something or an already translated string is submitted for translation again.
To avoid such mess, you’ll need a translation service to automate translation process.
[Big Picture]
Service scale:
- internal service (low traffic)
- only contain site translations (low memory requirement)
Primary requirements:
- developers are able to submit new strings and get translated strings
- translators are able to see translation requests and submit new translations
Basically db will contain string — translation (language) pairs, but apparently they might be different status over the workflow. The two main status are:
- (status 1) untranslated
- (status 2) translated
Further requirements:
- easily hook translation package to production
- notify dev about prepared translations, notify translators about new requests
- dev submits strings easily with dev tools
Below will talk about how to meet each requirement by modify the existing infrastructure.
[Commit translations to git repo]
To use translation in production, the immediate way come up to our mind is to request translation service for translations. However, adding service call will reduce page loading time, and translation service downtime would make production service unreliable.
A better way would be committing translations to a git package for production use. It resolves the above performance / reliability problems. Also, since the scale of translations is small and existing translations are unlikely to be changed in the future, it perfectly suits into git repo.
To go this way, we should design a reasonable translation committing flow and version control for translation git.
[Notifications]
To make work more efficient, developers need to know when their translations are ready, and translators need to know when they have new work to do.
Two notification batches are needed in this case, they could be triggered with new string/translation coming in, or they could run periodically to notify users with collective information.
[Dev tools]
In production code, strings should be wrapped in some function that helps to find correct translation for it in git. We need to build something like this:
T.set_language(‘ja’) # set language to Japanese
T.translate(‘view my profile’) # find translation in git ‘view my profile’ with T’s language
Developers also want some tools that can scan ‘translate(xxx)’ from their code, compare to existing translation db, and detect what are the new strings (translation requests).
Moreover, in many cases strings are translated differently in different situations. Translators will need context in order to translate correctly. Therefore, our T.translate should support adding context:
T.translate(‘view my profile’, context = ‘text at the bottom of main page that navigates to user profile page’, screenshot=’www.screenshot.com/dlglsetgh23f’)
