Step #1: Determine whether data is Fixed or Variable
Variable data is the part of an entry or sentence that changes every time the data is presented, such as the number “5” in the sentence “You have 5 messages”. Fixed data is everything else – and while certain words may change based on the variable (i.e., “message” vs. “messages”), these linguistic variances are still considered fixed data because they do not matter to the application programmer – it’s not their problem. The first step in the localization process is to internationalize the original language for the software – called the “master language.” Note that in the examples of complexities earlier in this document, most of the information that changed word order and content had variable information inserted. A full statement like “Thank you for calling ABC Company” is considered fixed data. Variable data includes dates, times, numbers, telephone numbers, email addresses, people’s names, company names, serial numbers, and any information that will be changing each time data is presented when the software is live.
First, the software application is studied, and text for translation divided into:
1) Fixed sentences/paragraphs with no variables. (“Thank you for calling ABC”)
2) Text with Variable Information (“You have messages” or “Item shipped ”)
3) Other media can also be categorized, such as images, movies, and audio, if developer wishes to vary them with the user or some other criteria.
Developers can choose whether they want the System Localizer to handle all presentation entries, or only the Text with Variable Information. Personalization can also be considered variable information; the System Localizer enables hundreds of personalizations of the user data, without changing the host software’s code.
Step #2 Assigning name to each event – entry
In order to assure correct, natural translation into other languages, it is necessary to work in complete thoughts. Typically, software is designed to re-use phrases. For example, consider the phrases: “User added…”, “User deleted…”, “User changed…”. It is logical to assume that parts of these voice files can be re-used in other contexts, such as “Mailbox added…”, “Mailbox deleted…”, “Mailbox changed…”.
Unfortunately, these words that are common in English (“added”, “deleted”, and “changed”) are different in some languages depending on whether you’re talking about a user or a mailbox. Therefore each full thought, or sentence/paragraph, should be identified, and given an alpha-numeric name, like “UserAdded” or “MboxDeleted”. These sentences/paragraphs are called entries.
If the application is text-only, the entries can be up to 30 characters. For audio products, like telephone or kiosk audio files, the names should be no more than 10 characters because this name is the basis for a file naming convention that facilitates the handling of multiple thousands of voice files.
Step #3 entry online – original master language
There is a special way to enter this data online into a secure, private database via the web. This database need not be accessed by the developer’s software but data can be exchanged via API after the design process. This online accessible database is for storage, translation activity and eventual creation of usable exportable automatically generated hard code or Runtime Engine Extract files.
The entries are entered into the database via the web in the Developer Center. Entries without variables data can also be mass-imported. For the entries with variable information, a new type of variable will be inserted in place of traditional variables. These new variables are internationalized variables, such as dates, times, numbers and more. These internationalized variables are vastly different from what has been used in the past – and are also central to the “design-once-translate-forever” philosophy.
The theory behind the change is that the traditional approach to localization is based upon “exceptions”. Something is translated, then, when it doesn’t work linguistically in another language or a client wants to personalize the content, more code is added or modified or data tables are changed by engineers until it works. The “localizing by exception” approach generally results in programming such as “if English then…if German then… if Mandarin then…” Because programmers are designing linguistic algorithms for languages they may not even know, there is an inherent risk of error, requiring extensive testing, time-consuming recoding, and data table tweaking. With the System Localizer, once your software works in the original master language, the code will work in all languages.
To make this “one code fits all” possible, the traditional approach to using variable information has been revamped. A byproduct of this revamping, is that it is now much easier to use variable information. Now, with the Developer Center, variable information is painless to handle, and the translations are natural and high quality grammatically in all languages.
Step #4 Translation Mode
Once the original master language has been entered, the translation phase begins. Translations and personalizations can be managed by marketers, managers, and customers. The Developer Center offers a way to assure that the software’s original creators have strong quality control, even in languages they do not speak.
3 approaches to translation are possible:
1) Professional translators
2) Internal staff or customer personnel
3) Third party auto-translation software
With regard to quality:
#1 Professional translator: This approach is the most likely to be outstanding. Quality is most assured if reviewed and approved. You can use your own translators, or the translators of @International Services, or use one of the recommended professionals from the Directory of Approved Translators.
#2 Internal or Customer staff: The resulting quality will depend upon your staff or your client’s skills.
#3 Auto-Translation: Always a roll of the dice.
How translation works:
Translators perform their translations online, in secure environment. Each time “SAVE” is clicked, a concatenation check is performed and displays the translation with all variable information inserted, so that the translator can see the entry “in use” and assure that the result is correct.
Reviewers can follow in the translator’s footsteps to review the translations performed. There is also an approval process, if desired. If your company wishes to keep a glossary, the words and expressions can be pre-translated by clicking a button, to increase consistency.
Also from translation mode, other elements can be localized to be specific to the exact target market, such as pictures, movies, background audio.
Step #5 Personalization
Personalization uses the same “mode” as translation. Text and prompts can be personalized for the customer, with as many variations as desired per language family. Additionally, media can be personalized by swapping company logos, background pictures, and other elements.
Variable information can also be personalized, date and time formats can be changed, and word usage can be changed.
Menu order can be swapped based on common information and a customer preference variable. One customer can have “For English press 1, for Spanish press 2”, and this can be swapped online to be “For French press 1, for English press 2” for a different customer. The same applies to software interface menus and pulldown lists; items can be swapped or even deleted without changing the original software code.
In some traditional approaches to personalization, a copy of the original application is made, and then the prompts that need to be personalized are changed. With the system Localizer, the personalization is considered a new “language”. So, if your system original master language is EnglUS (English for the U.S.), then a personalization might be EnglUSHD (English for the U.S. for Home Depot).
If you are using the Runtime Engine of the System Localizer, languages are organized in a hierarchy, and called using a language precedence order. So, for Home Depot, the language EnglUSHD would be used ahead of any other English variant. If the entry is not found, then it will default down the line to EnglUS. There can be up to 8 items in the language precedence order without losing notable speed. If you are using the automatically generated hard code approach, hierarchies can be customized and hard code exported in which the online System Localizer performed the hierarchical searches.
Step #6 Review and Approval
There is a Review and an Approval mode. Other translators can proofread and edit translations, or customers can input their thoughts and ideas.
@International Services also offers “watchdog service”. “Watchdogs” are professional translators who, upon request, review translations performed by your translators or your customer’s translators or staff. Watchdogs can perform spot-checks or do full review of your translations. The Watchdog mode is discreet and private, and designed not to offend those doing the actual translation. Reports are viewable only to those with permission.
Step #7 Reports and Scripts
Once all data has been entered, a wide variety of reports and scripts can be created, including talent scripts, database studies, database queries, and similar.
Step #8 Audio File Verification
If your software uses audio files, there is an online Audio File Tester. This Tester is used to review all audio file content to ensure that the audio content matches the script. Plus, there is an Audio Concatenation feature, to play all of the entries (sentences) sequentially, with variables inserted, to assure that the complete phrases function as planned and sound the way they should. In translation mode, there is a written concatenation check, the idea being to eliminate concatenation errors before recording (and thereby saving money on recording costs). This audio test will catch any lingering possible errors, and most errors can be corrected by simply editing an audio file.
Step #8 ASR Code Translator
For technologies that use speech recognition, new localization ASR design area is expected to be available in 2011.
Step #9 Press a Button for Code or Extract
When the language translation or personalization has completed all of its cycles (developer original master input, translation, review, approval, testing), the chances of success are outstanding, far greater than any usual approach. If @International Services performs the translation and testing, the results are guaranteed.
To finish the localization cycle, the host software needs to receive its data, its auto-generated hard code, or Runtime Engine Extract File. Press a button and code can be exported as customized C#, C++, XML, Java, VXML, and more. Or, press a button and receive an Extract File, email to the developer to place in or near the software. The Extract file contains a highly condensed agglomeration of the database decision-making content – but without the database, and feeds the System Localizer Runtime Engine.
Step #10 Testing
The System Localizer software exports scripts for talent recording for audio products, text scripts for general use, database content studies. Plus, it offers online concatenation testing, online audio concatenation testing. Plus following audio file recording, the audio files can be heard and their content studied online as well.
