You’re thinking "Translation has been around since the beginning of time and software application localization has been around since computers, what can El Loco do that is new?". Turns out a great deal. El Loco started with two revolutionary ideas.
1) For the translators: deconstruct and present the app visually in a browser, so that they can see the visual context needed to provide accurate translations.
2) For the developers: stop wasting their time on tedious manual error prone tasks by automating those tasks.
As we forged ahead to make app localization insanely easy, we solved problems no one else had ever seen because no one had gone down the path we were traveling. Some of these solutions we have patented, some are just trade secrets.
No software will include translations for all languages. A native speaker might want to translate an app into an obscure language for their family and friends. Also, a native speaker who only reads one language, might appreciate a bad machine translation rather than a language they do not understand, especially if they need to use that app. Being able to request a translation on demand (on demand in-app translation) can allow someone to use an app, even if the developer is never going to translate it into their language.
Machines, users, and even professional translators can mis-translate something. Users will see the error and want to provide a correction. Being able to provide user corrections of translations (In-App User Translations) directly to the developer can only improve the translations. When users can provide immediate and precise translation feedback, the developer can have non-professionals provide translations for languages that are not economic, knowing that enthusiastic users will quickly make the translation perfect over time.
Mobile app translation is very difficult when working from just a list of words or phrases because there is no context. For example, is "Display" a noun or a verb? Translation in visual context (Visual Context with In-App Editing) allows the translator (professional or amateur) to see where the word or phrase is being used, which gives a context to help provide the correct translation.
Mobile app screens are crammed with user interface. The words and phrases have a limited amount of space to be displayed. Not only does the translation need to be correct but translations under constraints (Text Field Overrun Management) must fit translations into the available screen space. Translators and developers can see if any translation is short enough, too long, or too close to the maximum length to calculate and really needs the developer to review once it is in the app.
Even with the visual context, questions about intended meaning can arise. El Loco Talk messaging puts a message bubble next to each phrase viewed by the translator. For any needed clarification, the translator clicks on that phrase bubble, composes a message, which goes direct to the developer, bypassing all the layers of personnel so that the developer can provide a quick feedback to translators by developers. All translators get to see the clarification so that they can adjust their translation if needed.
Other mobile app translation systems capture screen shots to provide translators with visual context. The two fundamental problems with screen shots are; the space allocated to display translations is not known, and connecting translations to fields on screens is a manual process for the developer. For many programming languages, the screen gets composed of graphical elements, composited together, and then pushed to the screen. It is very efficient to convert programs to visual representation by intercepting the screen draw command. It provides a direct connection of translated words to fields on a screen and a direct measurement of the screen space each translation can occupy.
For programming languages that do not push a composited image to the mobile screen, the brute force method of converting programs to visual representation is by reading the compiled binary. This technique works on any app compiled from any programming language and is essentially a specialized decompiler.
As the developer tests their application in the simulator, we gather the visual representations of the user interface descriptions. What if the app has a large number of displays, could we automatically capture those screens for the developer? Yes. Since we know all the buttons on every screen, we can act like a web crawler and click on every button. By doing so we automate the capture of application user interfaces.
In mobile apps, the same word or phrase can appear on multiple screens but, the meaning on each screen might be slightly different. Which "OK" or "Yes" in the code corresponds to which screen? Since we are gathering the actual visual representation, not a screen shot, we can tag source language text with unique identifiers and know exactly which word in the code goes to which field on which screen.
In the source code, words or phrases that need to be altered, depending upon which language is in use, are surrounded with a translation function. Most code starts out with English words scattered among hundreds of source code files. Finding strings that have not been wrapped for localization can be a big challenge, which we have solved.
When finding strings that need to be wrapped for translation, one will find many strings that should not be wrapped; URLs, server commands, etc. When the app is updated and new words are added, they too need to be found and wrapped but, the developer does not want to review again all the words that should not be localized. We developed a way of marking strings to be ignored for localization that is remarkably simple.
Some catalog apps, and other apps with a great deal of data, store that data in a database within the app. We figured out how to pull the database apart, display the words and phrases in visual context to translators, and then recreate translation databases. Automated localization of embedded databases allows translators to see hundreds of screens without creating any work for the developer.
Each operating system expects its apps to be organized in a specific way so that it can grab and display the correct language to a user. To save developers time, we wrote code to automatically prepare app source code for localization. Because it rewrites their code, it doesn’t work for all developers. But it works for most and if it cannot reorganize their code, it tells them what they should look at and fix before their code can be localized.