Sales Software Globalization

Software Globalization:

Developing world-ready applications requires focused attention to a variety of issues beginning in the software application design phase. In addition, you need to determine the extent of world-readiness your application will support.

Your first step in the process of developing a world-ready application is globalization. A globalized application can correctly accept, process, and display a worldwide assortment of scripts, data formats, and languages. However, while your globalized application may possess such flexibility, the language of the user interface remains unchanged. That is, you have not localized the application for another culture/locale.

An intermediate step prior to localization is a process known as localizability. Localizability is about ensuring you have enabled a globalized application for localization by separating the resources requiring localization from the rest of the application. Proper localizability results in source code you will not have to modify during localization.

The final step, localization, is the process of customizing your application for a given culture/locale. Localization consists primarily of translating the user interface.

Probably the biggest misconception we encounter when talking about Globalization is that software “Globalization”, “Internationalization” and “Localization” all mean the same thing, and that thing is somehow related to something almost anyone can understand: Translation.

Internationalization (commonly abbreviated as I18n) is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. It is an engineering exercise focused on generalizing a product so that it can handle multiple languages, scripts and cultural conventions (currency, sorting rules, number and dates formats…) without the need for redesign.

Internationalization typically entails:

• Designing and developing in a way that removes barriers to localization or international deployment. This includes such things as enabling the use of Unicode, or ensuring the proper handling of legacy character encodings where appropriate, taking care over the concatenation of strings, avoiding dependence in code of user-interface string values, etc.
• Providing support for features that may not be used until localization occurs. For example, adding markup in your DTD to support bidirectional text, or for identifying language. Or adding to CSS support for vertical text or other non-Latin typographic features.
• Enabling code to support local, regional, language, or culturally related preferences. Typically, this involves incorporating predefined localization data and features derived from existing libraries or user preferences. Examples include date and time formats, local calendars, number formats, and numeral systems, sorting and presentation of lists, handling of personal names and forms of address, etc.
• Separating localizable elements from source code or content, such that localized alternatives can be loaded or selected based on the user’s international preferences as needed.

Localization (L10N) refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale). Translating the product’s user interface is just one-step of the localization process. Resizing dialogs, buttons and palette tabs to accommodate longer translated strings is also part of localization.

Often thought of only as a synonym for translation of the user interface and documentation, localization is often a substantially more complex issue. It can entail customization related to: numeric, date and time formats, use of currency, keyboard usage, collation and sorting, symbols, icons, and colors. Text and graphics containing references to objects, actions or ideas which, in a given culture, may be subject to misinterpretation or viewed as insensitive. Varying legal requirements and many more things.

Translation (T9N) is simply converting the meaning of a text in one language into another. In a software product, the content that is translated is user interface, documentation, packaging, and marketing collaterals. Most translation work is done by professionals, although in recent years, some companies started exploring the use of ‘community’-translation, and machine translation.

Globalization (G11N) refers to a broad range of engineering and business development processes necessary to prepare and launch products and company activities globally. The globalization engineering activities are composed of internationalization and localization while the business development activities focus on product management, financial, marketing and legal aspects.

Internationalization significantly affects the ease of the product’s localization. Retrofitting a linguistically- and culturally-centered deliverable for a global market is obviously much more difficult and time-consuming than designing a deliverable with the intent of presenting it globally. (Think back to the Y2K effort and trying to “undo” two-character year fields that were built on the assumption of “19xx”).

So ideally, internationalization occurs as a fundamental step in the design and development process, rather than as an afterthought that can often involve awkward and expensive re-engineering.

Cultural and Political Issues

Sensitivity towards cultural and political issues is an especially important topic when developing world-ready applications. In general, these items would not prevent your application from running; instead, they are items that may create such negative feelings about the application that customers may seek alternatives from other companies. Political issues, such as disputes related to maps, can induce governments to prevent distribution in entire regions. The following are areas in which problems commonly occur:

• Avoid slang expressions, colloquialisms, and obscure phrasing in all text. At best, they are difficult to translate; at worst, they are offensive.
• Avoid images in bitmaps and icons that are ethnocentric or offensive in other cultures/locales.
• Avoid maps that include controversial regional or national boundaries. They are a notorious source of political offense.

One of the great difficulties of teams of development is the need to have someone understand foreign languages and cultures and have some technical knowledge, such a person can be hard to find.

Another difficulty is the duplication of effort for maintenance and routine update of system messages in parallel to the development of the software and adding new features, consequently, the creation of new messages to be translated. For example, if a message displayed to the user in one of several languages is modified, all translated versions should be changed. There are software libraries that help to minimize this problem, such as gettext.

There are also some platforms as Transifex which is a web-based translation platform, also known as globalization management system (GMS). It targets technical projects with frequently updated content, such as software, documentation, and websites and encourages the automation of the localization workflow by integrating with the tools used by developers

Transifex is offered as software as a service. It features commercial plans, as well as a free plan for localizing open source software. Transifex itself was originally an open source project, but the development of an open source version of the software was discontinued in 2013. Hence, any further improvement of Transifex is only available to SaaS customers.

Internationalization using Scriptcase

Scriptcase, which is an environment for developing applications and web systems, started its internationalization process in 2011, today the software is available in more than 150 countries and its interface is translated into 10 languages (Portuguese, English, Spanish, French, German, Italian, Japanese, traditional and simplified Chinese).

Initially, the Scriptcase translation was made by freelance translators, those translators can be found in various online communities such as Freelancer.com or Upwork.com. Today, we are a group of native clients of each language to contribute voluntarily to the translation and version improvement.

Applications created with Scriptcase can be internationalized for over 70 different locales. The Scriptcase has its own translation system which is also available to the software users, a tool called “Data Dictionary”.

Using data from the Scriptcase dictionary users can create a data repository for use of generated applications. The data associated with the fields in the database table are stored for use in different applications. It is very useful to create an environment for data standardization. It also improves the development, accelerating the update of data and minimizing errors (updates the data only once in one place-the repository-and have used it in all applications).

The data dictionary of Scriptcase stores all labels and messages and turns them into variables. Creating an association table and allowing a rapid adaptation of systems created within the Scriptcase for various languages.

Data Dictionary within a Scriptcase project.

Inside the Scriptcase, the project already created (click here to see how project creation is), we will choose the languages and create a data dictionary.

 

Step-by-step for project creation within Scriptcase – Locales Step.

Step 1: Data Dictionary creation

 

Criating a data dictionary with Scriptcase

Step 2: Select the tables that will be part of the data dictionary and click “Continue”. 

Selecting tables that will be part of the data dictionary

Step 3: Finish and synchronize with existing indexes.

 

Adding tables to the dictionary.

Step 4: Review tables and synchronize with applications and dictionaries (if already exists).

Now that the data dictionary is already created. The labels translation must be made within the menu “Locales” > “applications Languages “.

 

System tables

All tables included in the data dictionary will be available for translation, you will need to access table by table to translate all the fields to the project languages. In the case of this example, the languages are Portuguese and English.

 

Labels translation variables used within a Scriptcase Form application.

The Scriptcase manages automatically all the applications translation, you will just need to translate table fields and internal system messages. Scriptcase will handle all these names through variables (i.e. {lang_tableName_fieldName}). It will not be necessary to track the local, because Scriptcase will make that according to the languages chosen during the project creation.

 

Form application using the language variables from data dictionary.

Sample system translated with Scriptcase data dictionary:
http://www.scriptcase.net/sistemas/v8/recruitments_tracker/login/

Tutorial vídeo teaching how to create and use Scriptcase data dictionary:
https://youtu.be/DLr_Tk9Tb98?list=PLDMYt0EmYW5xKNVdQ8s16L_eyCp3hNoU6

Check out more content on our blog.