Tag Archives: software

Expand Your Reach with Software Localization

Globalization has made the world a smaller place. Now, it is possible to manufacture a product in the eastern nations of Asia, and sell them on the western coast of Europe, all in a matter of days. As such, the need for having a global presence of your business has increased and is a must if you want your product or service to be successful on a global scale. Software localization becomes an essential component in this regard.

What is software localization?

Software localization involves the process of localizing or adapting any software to the technical, cultural, and linguistic requirements of various target markets. This is a labor intensive process and usually needs substantial time and effort from the developers.

Software localization is quite different from translation. It involves the process of translating and adapting a web product or software, and every other documentation related to the product. Translation barely translates the document without any reference to the local cultural and linguistic traditions. Software localization often runs parallel to the source product development and enables the manufacturer to simultaneously ship the product in different language versions. For instance, software strings translation may generally begin even when the product is going through the beta phase. Translation is simply one of the steps in the software localization process; completing this step doesn’t mean the product is ready for the market yet.

Tips for localizing your software

Many organizations are now actively seeking localization of their software offerings for different markets throughout the world. In this endeavor, many attempts on software localization are met with frustration after the software has been developed. The fonts may not be exact, the text may be garbled, and the encoding might be off, sentences may not come in an aesthetic format, or the overall design may not look as expected. The tips given below will guide you to successfully localize your software for specific markets.

Plan in advance: Proper scheduling must be done for localizing your software for different markets. Most companies tend to rush localization just before the actual software release, which compromises on the quality of the localization.

Test the software: Localized software should go through the same rigorous testing as the original product. The awareness resulting from looking at a different language “in context” inside your product is irreplaceable.

Leave sufficient space for expansion of text in foreign language: There are many languages which, on average, take up 30% more space than English. In case you have designed a software where English text just about fits in the space, it is likely you will face problems later on. As such, leave sufficient space when designing your product for compensations later on.

Localization-friendly string encoding: Wherever possible, you should source software resources or string tables in Unicode/UTF-8 format. This avoids garbled text, debugging, and unnecessary conversion steps.

Remove hard-coded strings through “pseudo localization”: In temporary branches, you can use general expression to take the place of all letters inside the text, with one repeated text like “XXXX”. Create the product, and all hard-coded text will throw up on the screen, showing IDs which aren’t given in string tables.

Avoid overusing single strings and concatenation: The structure of a sentence in English may not be followed in some other language. Strings used in different contexts, and concatenated strings will have gender and grammar agreement issues. Be generous with memory while localizing your software.

Overall, software localization has become an important step in the process of adapting your product for specific markets, and can potentially decide the success of your product in those markets. As such, you should make sure to perform localization in the best possible manner.

Best Practices for Software Localization

Software localization – where your software is customized to suit a specific language or region – is a great way of expanding your business. But if you are not prepared, it may cause many hassles such as garbled text, wrong encoding, and crashes. All these frustrations may be avoided if you prepare well for the localization.

Plan In Advance

More often than not, the reason software applications fall apart at attempts on localization is because the application was not conceptualized with localization in mind. As a result, there were no provisions created for language change or other modifications required for localization. Planning in advance can prevent this.

Design your software with provisions for localization like character support for different languages, so that the grammar of these languages can also be incorporated. Along with content localization, you should also focus on testing localization so that your software localization is more effective. Build a detailed testing plan in English and use the same plan in the localized tests also.

Remember that the feel of your software should be like the locally built software for native users. They should be able to use it without feeling like it was built by someone unfamiliar with their culture. Planning ahead will ensure that your software has this local feel.

Leave Provision for Text Expansion

Languages other than English have a more extended character set, so just using English standards will not be enough if you want to make truly localized software. Using UTF-8 standards always is the best practice for software localization. This prevents extra conversion and garbling of text. Keeping provision for dynamic expansion of UI is also a good practice.

Never use hard coded strings, especially for date and time formats. This is because different countries use different date and time formats. Same goes with currency. Naming conventions may also be different for different countries. Some write the given name before the family name, and some the opposite. Some cultures even have just one name for a person.

Grammar varies from language to language. “Red pencil” in English translates to “crayon rouge” in French. So if you are thinking of concatenating strings, it will not work out for software localization. Keep in mind, no string should ever be overused.

Other Considerations

The GUI and other aspects of the software will be translated by professional translators, and not by your engineers. So if you make the context and the meanings of the translatable parts clear to them through comments, they will be able to do it more easily. Furthermore, they will be consistent with the context right from the beginning to the end of the translation.

Make sure that the translation company you choose is an experienced and expert one, so that they can help with the translation of your software as well as help in documentation and at the same time maintain consistency between the two.

Always remember changing the language does not fully localize the software unless you use the full locale for that region. For example, if the software is supposed to be in English, it can be used in the America or in Britain, but then the spelling and naming conventions would change for software localization, even though the language remains the same (color vs. colour, or elevator vs. lift). Internalization support is also important in your software. It will allow the native formats for currency, date, and time for individual regions to be shown in a way familiar to the region-specific users.

As is evident from this article, software localization is never complete unless it is aligned to the local customs, conventions, and culture of the region it is being localized for. While planning and designing your software, keep provisions for not only language support, but also for other region-specific local conventions to avoid last minute worries.

Six Important Software Localization Guidelines

Imagine a scenario where you have translated your software into a number of different languages. You have announced the release date also. And then, you may suddenly realize that you have made the software available in most languages, but have not really tested them in all. The fact that you do not know if the software actually runs in a particular language can lead to panic. To avoid stressful situations like this, here are some rules that you can follow.

Convert User Strings into Resource Files

When you have a string that is visible to the user, make sure that you convert it into resource files. Examples of user visible strings are error messages, product names, titles, image strings, etc. When you add these strings in resource files, you can easily translate them. Most translators specify values to different translated strings. When a user selects a particular language, the software matches it with the translator value you have assigned and text in the corresponding language is displayed.

Avoid String Concatenation

Concatenation bug is one of the most common bugs that localization experts have to deal with on a regular basis. Take the example of a shopping site that allows you to buy t-shirts. The shirts available on the site could be of different colors. When you write the translator code for, let’s say French, you would use the commonly used French term for shirt and just append the translated version of the color that the user picks. But for French, this kind of translation does not work. French uses modifiers before some words and don’t use it for others and ignoring this aspect will result in wrong translation. So, the best way to avoid this bug is by completely avoiding string concatenation.

Include Punctuation Marks in Resource Strings Only

Punctuation marks also work like concatenations, except that punctuation rules differ from language to language. So, you cannot let punctuation marks be as they are and just translate the words. The best way to deal with this is to put all the punctuation marks into the resource strings. This way, you can add the relevant punctuation marks wherever necessary according to the translated text, without any grammatical errors.

Be Careful With First Names

In North America, people tend to use the last name more regularly. In some eastern countries, predominantly Asian, some people will have only one name. You cannot figure out if it’s the first or last. Obviously, the direct translation algorithm will mess this up and the blunders can be frankly embarrassing. The errors will be in the prefix to the name. To avoid this, make sure to add a gender tag to the name so that you have a comparative parameter while translating the string and add the right prefix.

Make Provision for Extension and Compression of Strings

When the user interface is designed, sentences will have a specific number of characters. But the problem in translation is that some words that are short in one language are long in another. The best way to deal with this issue is not to have any limitation in characters in the layout. You can just allow the text to orient itself in the space available. Just ensure that there is enough space for the strings to grow or shrink.

Stick to UTF-8 Character Encoding

Another issue that you are going to face with translated text is character encoding. There is the UTF-16 standard that you will be tempted to use. But keep in mind that UTF-8 is ideal for all your needs. Make sure you invoke the encoding at the top of your page to avoid any confusion and ensure that the standard is maintained throughout. Make sure you maintain this uniformity across all UI pages’ code.

Challenges of Software Localization

Software development is a constant necessity and a booming business in today’s IT world. There are a number of companies that produce high quality software. To ensure the global reach of the software that they produce, developers make it available in multiple languages. While this is a logical move by the company, there are a number of hurdles that the developers have to overcome. The basic source code will remain the same, but the user interface (UI) designers will have to work with the translation team to ensure that the software is effectively localized. Here are a few solutions to the challenges that the developers would face while localizing the software.

Localization Should Begin When the Coding Starts

If you are familiar with the software development cycle, you are aware of the fact that the user interface (UI) design is finalized before the coding part actually begins. So, the team responsible for the development of UI will already have started working even before the source code work starts. As a result, the UI team will have to work with the translation team to ensure that the UI is effectively localized. For each region, a separate UI is designed and coded. The basic design and layout remains the same. Only the text in the UI will be made available in the regional languages.

All Editions Should Be Rolled Out Simultaneously

One of the secrets of successful software is its simultaneous global release. When you release software on a global scale, your competitors have fewer chances of getting the jump on you to release their products. As a result, translators also have to work on a tight schedule to ensure that the localized UIs are ready for a global release. This is not an easy task especially if the localization is handled by a single company. They will have to work on tight deadlines and ensure that the quality is of the highest order.

Help File and Legal Documents Translation

One of the biggest challenges that a localization team will face while working with software localization is its technical documents. Localization experts are well versed in languages but they are not aware of the minor technical details which are crucial for a technical manual or a help file that is provided with the software. So, the translators will have to work with the technical team to ensure that they get all the minor details spot-on.

The same is true for legal documents. Without being aware of the legal ramifications, a translator might use terms that are considered legally wrong. To avoid this, translators should closely co-ordinate with the legal team to translate the legal documents accurately without any discrepancies.

Although the aforementioned activities are fairly simple and straightforward, they consume a lot of time. Also, quality is something that cannot be compromised on while localizing software.

Updated Content

When an update or a patch to the software is released, the developer team must ensure that the UI patches, if any, should be localized. The localization team will again have to work with the developers to get the terms in question right. If any content in the help file or the software content has to be updated, the relevant patches should be localized before they are released.

Cultural Barriers

There are certain cultural barriers that the localization team should be aware of while working on localizing particular software. For example, the usage of specific terms might be culturally inappropriate in some parts of the world, although it is accurate on a grammatical basis. Similarly, these small cultural details should be at the back of the localizing experts while they are working on software localization.

Terralíngua