Journal of Global Research in Computer Sciences
MenuISSN: 2229-371X
ISSN: 2229-371X
Manisha Bhatia*1, Varsha Tomar2 and Aparna Sharma3
|
| Corresponding Author: Manisha Bhatia , E-mail: manisha_bhatia23@yahoo.com |
| Related article at Pubmed, Scholar Google |
Visit for more related articles at Journal of Global Research in Computer Sciences
Localization concerns the translation of digital content and software, and their appropriate presentation to end users in different locales. Localization is important because having software, a website or other content in several languages, and meeting several sets of cultural expectations is an important international marketing advantage. This paper presents the difference between software localization, globalization and internationalization and compares the traditional document translation with respect to software localization. The paper further includes the survey of various localization software and software localization services, methods and tools available worldwide. As part of conclusion the steps followed for localizing a software project is included. We intend this paper to be useful to researchers and practitioners interested in software localization.
Keywords |
| Localization (L10n), Internationalization (I18n), Globalization (G11n), Document Translation, Indic Computing. |
INTRODUCTION |
| Localization is the process of adapting a product or service to a particular language, culture, and desired local "look-and-feel (Rouse, 2005). Software Localization is more than the translation of a product's User Interface. Companies localize software in order to overcome cultural barriers for their products to reach a much larger target audience [1]. |
 |
| In computing, internationalization and localization are means of adapting computer software to different languages, regional differences and technical requirements of a target market. Internationalization (i18n) is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization (L10n) is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text [2]. |
| Some companies, like IBM and Sun Microsystems, use the term "globalization" for the combination of internationalization and localization. For example, by creating technical illustrations for manuals in which the text can easily be changed to another language and allowing some expansion room for this purpose. This enabling process is termed internationalization. An internationalized product or service is therefore easier to localize. The process of first enabling a product to be localized and then localizing it for different national audiences is sometimes known as globalization [3]. |
DIFFERENCE BETWEEN SOFTWARE GLOBALIZATION, INTERNATIONALIZATION AND LOCALIZATION |
 |
 |
| Localization primarily includes: |
| 1. Translating text content, software source code, web sites, or database content; machine translation may be used in early stages. |
| 2. Adjusting graphic and visual elements and examples to make them culturally appropriate. |
| 3. Post-production quality control of content, systems and the integrated product. |
| Internationalization may include: |
| 1. Creating illustrations for documents in which the text can easily be changed to another language and allowing expansion room for this purpose. |
| 2. Allowing space in user interfaces (for example, hardware labels, help pages, and online menus) for translation into languages that require more space. |
| 3. Creating print or web site graphic images so that their text labels can be translated inexpensively. |
| 4. Leaving enough space in a brochure to drop in different length languages. |
| 5. Separating the language elements from the graphic elements, or abstracting content from markup in a web application and software. |
| 6. Using written examples that have global meaning. |
| 7. Insuring that the tools and product can support international character sets. |
| 8. For software, ensuring data space so that messages can be translated from languages with single-byte character codes (such as English) into languages requiring multiple-byte character codes (such as Japanese Kanji). |
| Globalization describes a comprehensive process that incorporates, augments, and extends: |
| 1. Research on and identification of global markets. |
| 2. Market validation and selection. |
| 3. Identification and formalization of global business requirements. |
| 4. Language translation and cultural integration (a.k.a. Internationalization and Localization). |
| 5. Identification of technology standards and solutions (format and structure). |
| 6. Identification of cross-market affinities (to enable marketing and technology asset reuse). |
| 7. Alignment with and support for Internationalization (i18n) and Localization (l10n) processes [6]. |
HOW DOES SOFTWARE LOCALIZATION DIFFER FROM TRADITIONAL DOCUMENT TRANSLATION? |
| Software localization is the translation and adaptation of a software or web product, including the software itself and all related product documentation. Traditional translation is typically an activity performed after the source document has been finalized. Software localization projects, on the other hand, often run in parallel with the development of the source product to enable simultaneous shipment of all language versions. For example, the translation of software strings may often start while the software product is still in the beta phase. |
 |
| Translation is only one of the activities in a localization project – there are other tasks involved such as project management, software engineering, testing and desktop publishing [7]. |
| Comparison between translation and localization, may be done using the following categories– |
| 1. Activities |
| 2. Complexity |
| 3. Adaptation level |
| 4. Technology used |
Activities |
| Traditionally, translation is only one of the activities in projects where material is transferred from one language into another. Other activities that can be distinguished in traditional translation projects include terminology research, editing, proofreading, and page layout. In localization, many more activities have been added to this list. Examples of activities in localization which are not necessarily part of traditional translation are multilingual project management, software and online help engineering and testing, conversion of translated documentation to other formats, translation memory alignment and management, multilingual product support, and translation strategy consultancy. |
Complexity |
| Compared to traditional translation projects, managing software or web localization projects can be very complex. First of all, localization projects contain a large number of components, such as software, sample files, online help, online and printed documentation, collateral materials such as product boxes and disk labels, and multimedia demos. In most cases translation starts before the source material is final, so in most localization projects the source files are updated several times during translation. Because volumes are usually very large and all components contain dependencies, managing localization projects is a tricky task. Large volumes and tight deadlines require teams of translators, who all need to be reviewed carefully to maintain consistency. For example, when translator A translates the software and translator B the online help files, all references to the running software translated by translator B in the online help must exactly match the software translations that translator A has chosen. Also planning localization projects is a complicated task, because many tasks depend on completion of previous tasks. For example, screen captures of localized software to be included in the online help or documentation cannot be created until the localized software has been engineered and tested. |
Adaptation Level |
| Localization is derived from the word locale, which is defined in the Collins Cobuild Dictionary as "a small area, for example the place where something happens or where the action of a book or film is set". In a software localization context, a locale is a region which is defined by a number of characteristics, such as language, culture, and all types of regional standards such as character set, currency, default page sizes, address formats, custom calendars, date/time formats, and other things that give many American software developers headaches. For example, a language is French; a locale is the region in Canada where French is spoken. In software localization projects, all local characteristics need to be implemented in the final product. A truly localized product shouldn't only be in the target language but should also use default settings for the target locale. So, a product sold in Germany should automatically use A4 as default page size, support input and output of accented characters, and display currency amounts using Marks and Euros instead of dollars. |
Technology Used |
| In software localization, the integration of translation technology is ahead of traditional translation. Because of the nature of software products and web sites, which are highly repetitive, and updated on a regular basis, smart re- use of existing translations has become a competitive advantage and the use of translation memory a must. Most software products are updated at least once a year, and web sites are often updated on a daily basis. As a result, translation memory tools have been used successfully for many years in the localization industry. Other examples of translation technology that is widely applied in the localization industry are software localization tools for software user interface translations, terminology extraction and management tools, and machine translation. To sum up, localization has never and will never replace translation. It's just a term used to cover all activities related to adapting a software product or web site to be used in a target locale. Translation will always remain one of the most important activities in any localization project. [8] |
RELATED WORK ON SOFTWARE LOCALIZATION |
| Alchemy software development limited (Ireland) developed a software suite for internationalization and localization that is Alchemy CATALYST. Alchemy CATALYST is a software localization tool and was one of the first tools that contained integrated translation memory technology [9]. Alchemy CATALYST is an integrated translation environment with powerful project management features. CATALYST seamlessly integrates editors and tools for Translators, Localization Engineers, Quality Assurance (QA) Specialists, Project Managers and Software Developers. The software supports all Windows™ program (DLL, EXE, INI), resource files (RC) and help files (RTF, CNT, CPP, HPP), as well as XML/XHTML based files and Internet applications [10]. The latest version of Alchemy CATALYST version 9.0 SP2 was released on the June 6th 2012[11]. |
| The company PASS Engineering GmbH (Germany) develops their own localization tool that is Passolo. Passolo became available as an independent localization tool in 1998. In June, 2007, SDL acquired PASS Engineering [12]. SDL Passolo allows the user to Use the visual localization environment to see which translation is best when no context is available and view the translation of dialog boxes and menus in real-time and adjust them accordingly. SDL Passolo 2011® is the latest version of the award-winning software localization tool. With one visual environment for software localization, translate graphical user interfaces (GUI) more quickly and easily than ever before [13]. |
| Schaudin.com (Germany) [14] is a software designer company developing custom-made applications running on Microsoft Windows that is RC-Win Trans. RC-WinTrans supports the localization of the Graphic User Interface (GUI) of Microsoft Windows software consisting of dialog boxes, menus, string tables, accelerator tables and bitmaps. RC-WinTrans conveniently translates Windows resource script files (.RC, .DLG, .RC2), Program files (.EXE, .DLL and .OCX) as well as Java .PROPERTIES files, simple C/C++ text definition files (.H), Windows INI files (:INI) and InstallShield string table files (.SHL) [15]. |
| According to chine’s company EPRO process of localization is: |
| 1. Complete pre-analysis of software projects and solution of any possible problems prior to initializing localization. |
| 2. Translation and adaptation of software user interface and messages. |
| 3. Localization engineering and testing, also at the client's location, if requested. |
| 4. Complete help localization, including compiling, functionality tests and screen shots. |
| 5. Implementation of current commercial and client-specific localization applications, compilers and other tools [16]. |
| According to MORAVIA software localization engineering is a critical complement to the software localization and software testing cycles. It covers all the steps crucial for successful localization and testing, including software analysis, build engineering and mastering, bug fixing, scripting and overall localization process automation. They provide the following software localization engineering services: |
 |
 |
| To address the issues and to add simplicity to the process the software localization experts of Shakti Enterprise (India) work in coordination with their client right from the inception of the localization process so as to help them define and drive development and then perform engineering, translation and testing for more than hundreds of foreign languages. |
| The software localization process comprise of difficult technical task that is to be carried out by variety of specialists including graphic designers, programmers, project managers, testers, engineers and translators. To make the software localization process successful, integration of all these specialists is must. Shakti Enterprise has the expertise and in-depth knowledge about linguistic connotations, taboos, cultural nuances, regulatory requirements and languages that helps us to make the application as functional and useful for foreign users as it for currently for the domestic users. We specialize in providing up to date localization solutions to our clients for a wide variety of software platforms. We consider all the crucial aspects of software localization and strive to deliver high standard localization. |
| Shakti Enterprise has expertise in the following areas and this greatly influences the successful accomplishment of any assigned software localization project [18]: |
 |
 |
SOFTWARE LOCALIZATION SERVICES |
| Localization is the process of adapting products and services to a new location. This includes cultural, linguistic, legal and technical considerations and requires an in-depth knowledge of the local market. According to Integrated Language Solutions (India) the best possible localization service: |
Analysis |
| They analyze the local market to identify any linguistic, cultural, environmental and business factors that could affect your product or service. They also analyze our product or service to ascertain which areas require modification and adaptation. |
Modification |
| They extract any culturally sensitive or linguistically incompatible material from our documentation, translate text using an expert translator with in-depth local knowledge, and adapt all necessary aspects to the local market. |
Testing and Review |
| These test the new product or service in the local market to ensure that it meets local requirements and exceeds our expectations [19]. |
LOCALIZATION METHODS |
| Localization has been tried by varying methods. However, every method has been developed for certain requirements. Some of the popular localization methods are: |
1. Source code localization |
| The localization process started with localization of source code and it was carried out by the original developer. The steps involved in the localization on process with source code are: |
| i. Extracting user interface strings: In this task all the user interface strings like Menus, Dialogs, Messages, Status bar text; Tooltips etc are extracted from the source files. |
| ii. Adapting language specific conventions: The user interface strings are translated and number and Date & Time formats are applied. Appropriate character set, Code |
| Pages, Font names are also adapted and applied as per the requirement. String buffers are adjusted to store the translated strings. This also means altering and adjusting of dialogs to accommodate the translated strings. If enough care is not taken at this point truncation of strings would result in incomplete translated strings being displayed. |
| iii. Compile and testing: After adjusting the language specific interfaces, the source code is recompiled and is ready for testing. On successful testing, the product is ready for the market. |
| This method is still continuing in the open source community. The established software organizations like Microsoft also followed this method for the earlier products. |
2. Executable Localization |
| As the runtime binaries are matured and PC penetration increased, the localization need for various applications have also increased. And also there is a compelling reason to localize the product and release in local market simultaneously. To meet these requirements, the software developed should take care of the international requirement at design and development of English version itself. Thus developed product will be sent to localization team, the localization team in turn extract and translate the user interfaces using some localization tools, normally with visual testing capabilities. The translation and testing goes on hand in hand. This localization process normally takes less time compare to earlier source code localization. The product is distributed with translated resources. |
3. Runtime Localization |
| The recent development in localization is to localize the software during runtime. In this method also the localization was carried out with running process in the memory. But the resources are not embedded into binaries but distributed separately [20]. |
TREND IN LOCALIZATION |
| Indic Computing means "computing in Indic" i.e. Indian Scripts and Languages. It involves developing software in Indic Scripts/languages, Input methods, Localization of computer applications, web development, Database Management, OCR, Spell-checkers, Speech to Text and Text to Speech applications etc. in Indian languages. |
| Most of the Indic scripts nowadays use Unicode for working on Computers and Internet. In Unicode 5.0 following Indian Scripts have been encoded: Bengali script, Devanagari, Gujarati, Gurmukhi, Kannada, Limbu, Malayalam, Oriya, Sinhala, Syloti Nagri, Tamil, Telugu. |
| A lot of Indic Computing projects are going on. They involve some government sector companies, some volunteer groups and individual people [21]. |
PROBLEM RELATED TO LOCALIZATION |
| There can be many reasons why the localization of a string can cause a bug, be it user interface or functional. In the functional space bugs can be caused by [22]: |
 |
INTERNATIONALIZATION DO’S AND DON’TS |
| Here are 11internationalization Do’s and Don’ts that all software development companies can consider and implement at work. |
1. Do externalize messages in Message Catalogs, resource files, and configuration files: |
| Messages are textual objects that are translatable components. These catalogs or files, such as Java resource bundle message files or Microsoft resource files, are installed in a locale-specific location or named with a locale-specific suffix. This i18n practice will facilitate the localization process, since localizers can work on these resource bundles without the need to modify source code. It will also permit the use of a single source code for all languages, where only the resource bundles will have different language flavors. |
2. Don’t internationalize fixed textual objects: |
| These are objects that should not be translated, such as comments, commands, and configuration settings. Only externalize the strings needing translation. If these objects appear in resource or configuration files, they should be marked “NOT_FOR_TRANSLATION.” |
| Here are some examples of fixed textual objects not requiring i18n: |
| a) User names, group names, and passwords |
| b) System or host names |
| c) Names of terminals (/dev/tty*), printers, and special devices |
| d) Shell variables and environment variable names |
 |
 |
11. Don’t alphabetically sort strings in string tables and resource bundles: |
| Try to offer as much context as you can with the externalized strings. This will help the translator better adapt the translation to that context. If context is non-existent, run-time QA will take much longer to correct the translation [23]. |
PHASES OF A PROJECT- |
| Phases in a localization project are project setup, translator training, terminology definition, user interface translation, test of user interface translation, documentation translation, review of documentation translation, finalization of documentation translation and lessons learned. |
Phase 1: Project setup: |
| The basis for managing any project, including localization, is the project plan. Set up your project plan with milestones, time buffers and constraints. |
| To estimate the effort, count the words of the user interface and the documentation to be translated; add times for translation preparation and review. |
Phase 2: Translator training: |
| A translator’s first contact with our software should not be the translation of a context-less list of words. Instead, train the translators in the software to be localized. Invite the translators to our site to participate in a standard user-training course or provide translators’ training. Use this training to establish a relationship on a personal basis. Because the translators might reside in another time zone, country or even continent, the training could be a computer-based training, a simulation or a demonstrator version located on your website. |
Phase 3: Terminology definition: |
| In project documents with yet undefined terminology, the use of a consistent terminology will only be achieved after various cost-intensive iterations. Define the basic terminology to be used for translation of the user interface and the documentation. The basic terminology includes button labels, menus, functions and concepts used in the software. |
Phase 4: User interface translation: |
| After defining the basic terminology, start to localize the software. User interface localization can be performed with support of a localization tool or by translating string resource files. Software localization tools work the way translation tools do, with the segmentation rules applying to user interface strings rather than to sentences. A software localization tool supports the user in the definition of unique menu hotkeys and offers to display the form currently being localized. |
 |
 |
Phase 5: Test of user interface translation: |
| To achieve our own product requirements, it is essential to thoroughly verify the localized version of our software. The user interface’s translator should preferably perform the test of the localized user interface. The tester must turn his or her attention to a wide range of topics. A complete localization is only achieved if all controls (button labels, tooltips, menus, field labels and system messages) are translated. |
Phase 6: Documentation translation: |
| If we localize both the user interface and the documentation, we should finish and verify the user interface translation before starting translation of the documentation. Each modification of the user interface translation requires repetition of testing that translation with all its checks. So, provide enough time for the tests of the user interface translation. |
Phase 7: Review of documentation translation: |
| Our documentation quality and usability requirements also apply to localized versions. If possible, a translator other than the documentation’s translator should review the translated manuals. In addition to the linguistic check, the review must ensure the consistency between user interface and documentation. This consistency is important. It supports the user in locating the description of a user interface’s form in the manual and vice versa. |
Phase 8: Finalize documentation translation: |
| After completion and review of the documentation translation, we can finalize the documentation. Insert the graphics in the documents, perform the final formatting, update the table of contents and index and compile the online help. |
Phase 9: Lessons learned |
| This phase applies to every project, not just localization projects. Review your lessons learned log [24]. |
C0NCLUSION |
| As part of conclusion we conclude the number of points that have to be considered, in order to effectively localize a software product or website. |
| The localization process includes analysis, assessment, creation and maintenance, translation, adaptation, media localization, testing, quality assurance and project delivery. |
 |
References |
|