Documentation, software, and website translation and localization services into over 100 languages. 
Phone:
Email: 
Taking inventory of your software project
Before moving a software project to the localization phase, there are a few things that can save time and money by addressing the issues ahead of time. Depending on your software, there may be existing behaviors that are inappropriate for localized versions. Data entry involving proper names, addresses, phone numbers and currency are all areas that could cause problems during the localization phase. Additionally, user interfaces and text display functions can cause unforeseen localization problems. Addressing these issues ahead of time, on the source content, saves time and money in the localization and testing phases for each target language.
Numeric input & validation
Any part of software that accepts numeric user inputs, must be able to work with the appropriate numeric data formats used in foreign locales. A phone number format is easy to validate for the US, but the same validation method would not work with a German phone number. Currency values may also need to be converted for different countries. Be sure to address hard coded currency and decimal symbols so that they can be correctly displayed in each locale. Confirm that any numeric input is handled using the system locale format to ensure that localized numbers appear correctly.
Text input
Data entry fields may be required to handle a variety of characters from various locales. If your application stores and retrieves text data, it needs to accept and display the characters form any given locale. Using Unicode encoding should eliminate these problems. This is a good place to start since most modern operating systems have support for Unicode.
Text display
Being able to correctly display each language’s character set is paramount for software localization. Check your software for fonts that are defined. Selecting a font that supports the Unicode range of characters is the best option. Also consider font size for dialogs and controls: eight-point fonts may be easy to read in English but hard to read in Chinese.
Centralizing and formatting string content
Whenever possible, it is best to keep all of the user interface strings together. By isolating the user interface strings from the code, translation and testing becomes easier. Hard coded control labels and response buttons are easy to miss as part of a localization kit. These hidden strings may only be found later during the localization or testing phases, adding more time and money to the localization process.
A good way to reduce the possibility of these errors is to keep strings in a single file with a consistent format. This helps to eliminate string duplication and maintain consistency while also being more portable. Strings with a standardized format for inline code, escape characters, control characters, and text formatting can streamline the translation process. It will also increase parsing efficiency and improve the leveraging of strings that are reused from previous translations. This too can save effort for future updates during the localization process, as strings can be managed from a centralized location.
Sizing up the user interface
Dialog boxes and windows all contain strings. Once the text is translated, it may take up more space on the dialog box than the original string. String length can double in length for some languages (not to mention the translation of common US acronyms into a target language – some of those can take 10 times as much space). Where possible, the user interface should be expanded with plenty of “white space” so that controls and labels have extra room to accommodate translated strings. A possibility is to have the user interface dynamically size to the text. Using dynamically sized dialogs can greatly reduce the engineering time needed during the localization process, since manual resizing is no longer required.
Finalize
Before starting a translation project, it is important to make sure that localization kit is final. Updates to strings and code files containing translations can slow down the translation process. Unfinished code or code that is transition, can also burden the process. When localizing into multiple languages, a single functionality defect or code modification can delay testing, inflate translation/review time and increase chances for inconsistencies. By ensuring your software is internationalized and ready for release up front, a large amount of time and money is saved in the testing and localization phases.
Conclusion
All of the topics listed above can impact the effort, turn-around time, and cost of a software localization project. By heading off potential internationalization issues and designing for subsequent localization, your software can have better consistency across all of your target markets. All of these tasks take time and effort up front, but it saves many times that effort during the localization process. Above all, software is more robust and usable when there is continuity across all localized versions.
ENLASO's Software Internationalization Solutions
For more information on how ENLASO can assist you with all of your localization needs, please contact us at Contact@enlaso.com, call 303.516.0857 x127, or complete the quote request form.
