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.