How I think of localization tech and localization engineer

I wrote down this article to discuss what a localization engineer normally does and where their responsibilities are, which is from my experiences, starts from a real world l9n story and covers more practical examples.

A not rare l9n story

Background first: Company A wants a solid integration from their central database of multilingual string texts to Company B's CAT platform. This central database already connects to Company A's many in-production apps. So, very briefly, strings need to be sent to CAT via certain integrations coded by a 'localization engineer'.

Solution 1: The CAT platform provides APIs like receiving strings, creating projects, sending translations back and so on like other modern CAT platforms. So the integration can just use these APIs and make them work with the central database, which is the primary or core responsibility of this engineer. However, even though the localization work of translating all the strings seems fulfilled successfully, I'm thinking this solution lacks a very fundamental consideration of the localization workflow: projecting.

Solution 2: Actually based on Solution 1, we develop a localization center platform in between called Loc A-1. Loc A-1 connects to both the central database (extracts translatable strings and sends translated strings back to in-production apps) and the CAT platform (sends translatable strings for translations and gets translated strings back) with the two parties' APIs (internal ones of the central database and external ones of the CAT platform). Every time a localization action/operation is triggered with the above APIs, a related 1 to 1 localization project (this definitely depends on how a team defines the scope of their projects, e.g. only translating one string can be seen as one localization project but this might be too much if this team doesn't have enough project management resources) will also be created automatically with other (customization) capabilities, e.g. having more project info (deadlines, assignees, etc.) by project managers or tech info (length of a Russian translation, pluralization rules of languages like Arabic, etc.) by engineers who own the in-production apps.

Because without projects, for example, when in-production untranslated strings or wrong translations are found, it'll be much more difficult to find which projects caused these issues and arrange very related people and resources combined with the project and tech info to resolve the issues. And especially, how to do 'change management' is also very crucial to localization works because for localization projects there are always changes back and forth (client doesn't want a certain translation of a certain word even though the translation of this very experienced language manager is 100% correct but the client has some campaign and marketing considerations, which can also be recorded on the related project's info for future retrospections or better continuous works with the same client). There are other benefits of good localization projecting besides the examples mentioned above.

Not only basic project-related works are all recorded and organized on the platform but other solutions can be built on this foundation, for example:

• better UI/UX solutions or at least warnings to potential errors from the CAT platform because we use APIs they write and sometimes there's not much we can do to solve certain connection issues from our side;
• various i18n solutions like currency, date formatting or pluralization accumulated by working with different projects,
• specific l9n solutions like how to correctly label all French phonetic notations of a client's special article (I learned this example from a localization engineer who is specialized in solving similar kind of issues with Python),
• and so on,

which can all be recorded and reflected with the same platform.

I'm not saying we can never accept Solution 1 (it's actually a much more practical idea if that team really needs a solution within quite tight timeline) but Solution 2 and related following practices might actually be the core responsibilities of a localization engineer with many localization-related thinkings when coding localization solutions because we not only code for our current works on hand but also need to consider future developments especially the good but hard ones.

Other things a localization engineer might do

• Evangelize localization ideas, e.g. i18n and l9n is best to be considered at the very beginning of a project or when the app is in-production already with tones of thousands of hard coded strings, things can be supper hard not to say different frameworks have different methodologies of how to be localized.
• Design and build the overall i18n and l9n infrastructure of a project.
• Build or maintain connectors/integrations among different platforms, e.g. CAT and CMS, CAT and new MT engine (this also introduces the AI part of i18n and l9n and a localization engineer needs to research on and implement these new techs when needed).
• Know the basics of frontend and backend code of a project so that when a specific localization issue (a wrong translation very deep in the codebase, a UI overlapping with a very rare language pair, how to work with languages read from right to left, etc.) appears, he knows how to fix it.
• Help the team maintain a localization knowledge and resource site that both internal and external parties can use it to support and facilitate their daily works.

There're many other things and localization can be a huge task especially you want a high-quality localized result. But again, during this AI age, things might be very different and maybe we'll have the Babel Tower quite soon.