The Process of Software Localization
Software localization service emerged in mid 1990's when Microsoft launched its first GUI operating system - Windows. With more than a decade of evolution of localization technology which makes supporting multilingual applications never simpler and quicker, even small software companies can afford to localize their software for the international market thanks to the reduced overall cost and shortened to-market time. By localizing your software into multi languages for the international market, you can gain benefits such as increasing revenue and profit potential, reducing international development costs, empowering any user anywhere, increasing customer satisfaction, and moving ahead of the competition.
Software localization goes far beyond textual translation of user interface and help file content. It involves extracting and preparing the translatable content, utilizing special software localization tools and adapting the software to the specific locale you aim at. For example, we will make the interface friendly to users in different countries and regions by taking into consideration the specific cultural norms rooted in them. In doing so, we must work deeper to modify and engineer the original interface in respect of local conventions, time/date displays, measurement systems, numbers and currency, character encodings and fonts as well as dropdown list of cities and areas. Software localization involves higher sophistication and complexity than textual translation. For example, it is very sensitive to the placement and rearrangement of translated elements in limited interface sections which have been designed for the source text, yet may not fit the target one. In short, everything concerned will be addressed with technical proficiency and extreme care, so that the user can seamlessly interact with the software in their own languages.
The software localization process usually consists of four phases: Prepare, Translate, Compile, and Test.
1. Prepare - resource files extraction. This phase aims to separate those localizable resources from the code, i.e. extracting resources. Depending on the platform and programming language used for developing the software and specific requirement from the developer, proper localization tools such as Alchemy Catalyst, Passolo, Lingobit etc. will be used for extracting resources from the original software. The resulting files are extracted Translation Database (TDB), which are to be translated by experienced translators. Besides a latest TDB, each extraction will generate word count files as well, which may contain added and updated character count. This statistics, on one hand, provides references for project managers to assign translation tasks, and, on the other hand, help the developer and the localizer calculate the workload for billing purpose after the project is finished. The preparation phase of localization is critical as it directly influence the efficiency of the following stages. In this stage, we need to accomplish the following steps:
1) Check what UI elements are not within resources therefore not available for localization.
2) Check whether changing the length of strings causes errors
3) Research how target language locale/codepage effects the application UI.
2. Translate: resource files, online help and user manual. The translator translates the extracted TDB as well as other documents incorporated in the software, such as online help, user manuals, etc. Thereafter, the publishing specialist proceeds by typesetting the user manuals and other documents. Normally the circulation of different versions of software requires the extracted TDB to be translated respectively, but the typesetting of online help document and user manuals are usually done in the late period of the project. To maintain accuracy, specialty and consistency of the translated terminologies, the developer normally provides a list of terminologies used in previous versions of the software for reference before the project starts. And for fast and precise translation of the localizable content, some particular translation memory software are being used, e.g. Trados.
3. Compilation. The compiling engineer, according to the compilation instruction document and the compiling environment, exports the localization resource files from the translated TDB, copies the translated online help document and files of similar nature inside the compiling environment, and, thus, compile the localized version of the software. Compiling environment is an aggregate of tools and pertinent files required for the compilation of the localized software, which is normally provided by the developer for the use of compiling different languages versions.
The following is the general procedure to create localized compilation version:
1) Set compiling environment.
Install a compatible Operating System (OS) and necessary applications, set OS environment variables, and install the original language version of the software that needs localizing.
2) Review translated TDB.
Adjust the size and relative position of the control in the dialog box, rationalizing and prettifying the layout, removing characters that cannot be properly displayed; Scrutinize the shortcut and hot keys, ensuring their consistency with those in the original language version.
3) Export localization resource files.
Export localization resource files (DLL, EXE, OCX, etc.) from the examined TDB. Thereafter copy the resource files, translated help document, end-user license agreement (EULA), readme and other documents inside the compiling environment.
4) Create localized version
Proceed with a series of processes as stipulated in the instruction document, calling utility programs in different compiling environments and thus creating the localized version.
5) Review localized version.
Review the localized version of the software, the procedures of which may include installation and basic functions test, menu structure comparison between the localized version and the original language version, etc.
6) Create terminologies list
Create a new terminologies list with special resource extraction tools in accordance with the very TDB used to create this localized version.
4. Pilot Test and Defect Repairing. After the localized version is created, a pilot test will be conducted, which shall test the installation/uninstallation, translation and function of the user inter face and online help document, and a special double byte compatibility test for languages like Chinese, Japanese, Korean, etc. Software defect management is an important part of the pilot test. And a complete defect management procedure consists of four steps, i.e. report, confirm, repair, verify, and close, each requiring a detailed description. To update, query, track and repair the defect at any time, database management is usually introduced, which in overall is called Software Problem Report (SPR) or Defect Tracking System (DTS).
In the defect repairing stage, the software compiling engineer dynamically tracks, timely confirms and makes repairs to the defects reported during the pilot test of the localized software, so that the newly compiled version can be exempt from such defects. Certain experience and skills are needed for the defect repairing, including proficient operation of both the localized software and tool programs to track and repair the defects. Software defect repairing requires utter coordination between the developer’s engineers and those of the localizer, so as to ensure if the detected defects are true defects of the software. And if such defects are repeatable in the original language version, it will require modifications of the source code by the developer’s engineers as well. The process of repairing the defects of the localized software is also a process of modifying the TDB. The modified TDB will be used for the circulation of the next version of the software till the last one.
The localization approach to Java applications
The above four-phases localization process, i.e. prepare, translate, compile and test, also fit in with the localization of Java based applications well. With our extensive research and pratice, we identity Passolo as one ideal tool to extract the Java resources also integrate the above process.
The Passolo Add-In for Java permits the localization of internationalized Java applications. The add-in supports all the common resource formats used in source files, in compiled binary files, and in compressed JAR files:
Java Property files
Property files have the file extension PROPERTIES and contain a simple list of IDs and strings. With property files, the Java source files can be stored in ANSI or UNICODE format, and will be generated in the same format after translation, using the target codepage where appropriate.
Java Resource Bundles
Passolo can identify and process both ListResourceBundles and ArrayResourceBundles. Its Java add-in can process source files with the file extension JAVA as well as compiled binary files with the file extension CLASS. Compiled ResourceBundles are always encoded in UNICODE.
JAR and WAR Files
Passolo supports JAR and WAR files. JAR files are archives that contain all the files belonging to a Java application. Including the compiled Java classes, the ResourceBundles and property files, the data and configuration files, etc. JAR files can be set up as multilingual archives containing the localized data for multiple languages. In this case the localized data is stored in separate files for each language, with filenames based on the described naming convention.
Passolo can extract the data to be localized from JAR files and create multilingual JAR files. If more than one target language is to be included in a JAR file, it is advisable to define the source language as one of the target languages, so that all the target languages can be added successively to the same JAR file. The Java add-in can extract property files and ResourceBundles from the files contained in a JAR/WAR file, and can insert the translations into the JAR/WAR file in compliance with the Java conventions.
After utilizing Passolo tool to extract the above key resource formats, we can then run the subsequent lingusitc and engineering process as per the best practice in the industry to make sure a quality output of localized Java application.
Software Localization @ CCJK
As an expert in software localization, CCJK is able to provide clients with one-stop solution from preparing, translating, engineering to testing of their softwar into multilingual version. With a well organized team of experienced, disciplined linguistic and engineering experts available at your service, we are capable of helping you extend your user base worldwide.
Words translated by CCJK146,096,379
We are Certified
Over 95% of our clients recommend our language services to others