Connecting AI Specialists, Linguists, and Project Managers

Published on 01.04.2020

Connecting AI Specialists, Linguists, and Project Managers

by Afaf Steiert

Computers have shifted from serving the sole purpose of word processing and simple computation on top of our desks to fitting into our pockets and providing an assortment of tools to the user. The demand for more and more of these tools that expand beyond simple weather widgets resulted in the inception of a highly organic applications market that retains a relatively low barrier of entry. Considering that this demand shows no sign of slowing as smart phones surpassed desktop computers in 2014, and that the market is predicted to experience a 270% increase in 2020, it is in any app developer’s interest to diversify the penetrability of their product into global markets (Safi, 2017; Takahashi, 2016). Translators have often come to me to express their discontent with projects that are related to mobile apps since there is a disconnect between what an LSP can do and what an app developer demands for their project. Creating a clear and defined scope of the viability of the success of a project and utilizing a translation management system (TMS) that the client can also be involved with will greatly assist in reducing wasted time and money for all parties involved.

To execute a successful internationalization/localization project on an app, it is important that language service providers (LSPs) and app developers increasingly become symbiotic in their knowledge of the other’s industry.

The demand

It has been commonly understood that internationalized applications will naturally have a higher rate of daily active users. That is why all LSP project managers must have a fundamental understanding of what is involved in translating an application, and they must understand the technical jargon that app developers bring while conversely preparing developers for the work localization demands from them.

LSPs that aren’t attempting to reeducate their translators and adapt their pricing models for mobile applications are unfortunately going to miss out on a very large market share. It is especially fortuitous that the United States has typically shared a domination of the global market with Japan in having the most lucrative and successful publishers hailing from within from within the U.S. as seen in figure 1 (App Annie, 2017). With app developers protecting their profit margins, it’s only natural that they will follow growth in the market (Asia, Africa, and the Middle East) and seek localization services accordingly.

Top 52 Publishers of 2016

Figure 1 (App Annie, 2017)

App localization is far more than merely taking texts in an app and translating them. LSPs must make sure to set a strategy with the client to develop an understanding of what markets they expect to proliferate. If the client is keen on translating into one language, it is much more viable to take a deep localization approach to fully integrate into a few markets (e.g., Arabic). The broader the internationalization of the project, the more work that will have to be done to the user interface (Ul). Internationalization within the mobile apps setting refers to the ability of the app to adapt to different languages and present itself as a native app to the user. In order to create multiple languages for an application, translators will need to identify the Ul strings from the app code in order to compile that text into multiple resource files. A fantastic way to simplify this process across large scale projects or highly layered and complex applications, such as social media apps, can be achieved through the investment of a TMS. Large scale LSPs often develop their own TMS, but smaller LSPs can easily remain just as competitive by utilizing various third party TMSs such as Onesky, Smartling, or Wordbee to allow a manager to monitor the overall progress of all parties in the project. It is fundamental to include the client within your TMS loadout to maximize the efficiency of the project. Time is wasted in the process of allowing each contractor team to operate independently under the direction of separate project managers that continue to fragment client demands.

Furthermore, upon standard delivery updates to the client, a lag would exist between understanding the issues that existed in the Ul and how linguists could aim at solving them through the TMS. This fragmentation, or stove-piping of information, is a classic attempt to disrupt any one individual from having too much information on the project.

This fragmentation, however, highly compromises the speed and quality of any of the work, since it perpetuates a cycle in which contractors are constantly left to repair the work they had just finished according to the previously untested and unrefined instructions that were given to them. This only results in contractor fatigue, which further hinders the project’s timely success. It is far wiser to invest your project manager’s time into sourcing trustworthy contractors that can preferably work in-house or can be held highly accountable throughout all stages of the project. By including them directly with the Ul and allowing the client to have plenty of time to check in on how the translation impacts the application, it is far less likely to have a gap between translator and developer. Developers often have a misconception that non-developers will not understand their demands, but one does not need to be a developer to understand the basic demands of a Ul. So, it is up to the LSP to create a dialogue that can be transparently transmitted from developer to contractor.

Incorporate a localization tester that is fluent in both the source language and the target language so that they may be able to view both apps. Depending upon the demands of internationalization, merely mirroring the user interface and changing the text direction won’t suffice for certain languages, and so further development would be demanded from the client. If you have these capabilities as an LSP, then your eye for detail must be sharp since internationalization demands the app to adapt to other languages. Do not wait for issues to arise to provide such information. If all parties are aware of the complexity that exists in translating a mobile application and the capabilities that all parties have, then common inefficiencies can be aptly mitigated.

Finally, your project is not over when your translation is complete. Even with your own tester, components may be missed, a new demographic may begin downloading the application, or a variety of changes in the market will cause the localization project to fall short. It is a necessity for the client and for the LSP to continually check the app’s ratings and comments in order to catch any further glitches and mistakes early before the market decidedly retires the app. If each step of this process is followed, then you shouldn’t have any gaps between developer expectations and linguist abilities.

The Incorporation of Artificial Intelligence

What was covered in this article primarily addressed a traditional mobile phone app that requires analog user interaction to control it. A common trend in application technology had been the incorporation of artificial intelligence (Al) assistants such as Samsung’s Bixby, Google Assistant, or Apple’s Siri. LSPs are a large component of these projects because these Al assistants must first be taught a language and its various nuances to effectively understand it and connect certain utterances to different commands. It is understandable why a certain level of fragmentation exists on such projects si nee the levels of confide ntiality are quite high. Nevertheless, it is in the LSP’s best interest to build upon the fundamentals outlined within this article to avoid large losses in both project expenditure and reputation.


As with any specialization, the environment between developers and linguists will likely improve with time. The better an LSP can familiarize itself with the basics of app development, the more easily it can guide the client In many client interactions, there is an assumption that translating the language in an application should be as easy as translating a document This is far from the truth, since unlike a document in which there is only one variable (words), an app is far more complex. An LSP need not be concerned about providing ample time for the introduction of the project until it gains traction. In an industry that is based on clicks per minute, downloads per minute, and megabits per second, it’s important for LSPs to adjust developers’ working culture to the language industries. We’re an industry that is based on human capital, not code, and it’s our job to make developers understand that.

About the author

Afaf Steiert is an Arabic translator and interpreter. She obtained her M.SC in plant molecular biology from the University of Basel, Switzerland. She presently lives in California and serves as President and co-founder of Afaf Translations, where she works as a conference Arabic interpreter and oversees all medical translation services.


App Annie. (2017, March 10). Announcing the Top 52 Publishers of 2016. Retrieved from

Dogtiev, A. (2016, January 20). Mobile App Developer Statistics Roundup. Retrieved August 17, 2017, from

Saifi, R. (2017, January 6). The 2017 Mobile App Market: Statistics, Trends, and Analysis. Retrieved August 17, 2017, from

Takahashi, D. (2016, November 04). Mobile app market to grow 270% to $189 billion by 2020, with games accounbng for 5554. Retrieved August 17, 2017, from