Localization (L10N) is the process of adapting products and services originally designed for a single Market, so it can be launched in international markets. The adaptations go far beyond the language (translation) and include changes to any information that could compromise the understanding that the user has of the product.

Although the localization and the localization testing are not strictly a part of the process of software development, localization only becomes possible once you have developed the software and prepare it for localization; this process is called internationalization.

Localization testing checks how well the software has been localized to a specific target language. In addition to verification of the translated content, called a language test, functional tests should be performed. In these tests, we check whether the entire application is really working and is ready to be marketed and is ready for use in the market for which it was localized.

In the next post I will talk about what should be taken into account in the localization testing process and where you should focus on when carrying out the tests.

In bidirectional languages, not only the alignment and reading order are changed. All layout elements of the user interface should be also displayed in the new order. This can cause various problems in title bars, tree structure displays, combo boxes, etc.

Below are two examples of mirrored desktops:

Windows XP desktop in Arabic

Windows Vista Control Panel in Arabic

Did you notice the “mirrored” positioning of the Start button and interface elements, such as the Back and Forward buttons?

In fact, to mirror is simply to transform coordinates, as displayed below:

The origin (0,0) is in the upper right corner of the window and not in the upper left corner; scale factor of x is -1 (values are incremented from right to left).

Transformation of coordinates

An interesting aspect of mirroring is how it processes the images. Direction-sensitive images present new challenges with mirroring, because some of them mean different things when they are mirrored.

For instance, Internet browsers configured for a left to right (LTR) layout, the concept of “return to previous page” is represented by an arrow pointing to the left, while the concept of “advance to the next page” is represented by an arrow pointing to the right. When these arrows are mirrored in a right-to-left (RTL) layout, then it is exactly the opposite, as shown below.

Other graphics, however, must never be mirrored, as they represent trademarks or logos and lose their meaning when mirrored incorrectly, as seen below:

Information about which files should be mirrored, or not, are normally passed on to the operating system, which then processes them correctly.

Ok, with this post we reach the end of the series about Internationalization. I really hope you liked it. If you have any questions or need consulting assistance on Internationalization, do not hesitate to contact me. Simply click on my name under Team on the right and email me your questions and concerns.

But keep in mind that I am already thinking about the next series and I hope to have more information soon. Until then!

But like I said, it is not that simple. There will be situations where the writing will be read from left to right, just like with Western languages.

Bidirectional (or Bidi) is the term used to describe a text whose writing flows both from Left To Right (LTR) and from Right To Left (RTL). The graphic below, with Arabic text and insertions in English, is a good example:

There are some issues you should consider when preparing an application to support bidirectional languages. They are as follows:

1) Internal data storage:

As mentioned above, Bidi text flows from left to right and vice versa. Even if it flows in two different ways, the text should be stored (on the hard disk, for example) in the same order, from the first to the last character. The best way to visualize this situation is to imagine that the text is stored in the buffer in an orderly fashion, with a directional mechanism to present the data, which will display the characters in the correct way (RTL or LTR).

Internal data storage of the example above

2) Presentation Flow

In the past, most Latin languages were represented in a character-by-character format. Today, it is better to save the line being displayed in a buffer and display the entire buffer each time a character is changed in that line. This is due to the different properties of bidirectional text, related to character positioning, writing flow and the way ligatures (elements characteristic of the Arabic language) change the format of the character, depending on what comes before or after it.

3) Line size

Also due to character ligatures, it is not recommended to obtain the line size by adding the size of the characters together. To obtain line sizes, take the size of the text that is stored in the buffer using operating system tools specifically designed for this.

In the Arabic and Indian language families, a glyph can change dramatically depending on its position in a word and the character that precedes or follows it. In Arabic, for example, the same character can have different formats, depending on the context, as shown in the table below.

In Latin, there is a one-to-one relationship between characters and their corresponding glyph. The character h, for example, is always represented by the same glyph h. In complex writing systems, however, several characters can be combined, thus creating a completely new glyph that is independent from the original characters. There are also cases where the number of new glyphs is greater than the number of characters used to generate them.

Characters are often stacked or combined to generate a new group, indivisible in most complex writing systems. The following figure shows an example of how this happens.

From left to right you see three languages: Hindi, Tamil and Arabic. In the first character set on the top line, the four individual characters (please note the separations) are joined to create one glyph, which is displayed on the bottom line. In the second set, the two characters are joined to make an indivisible group of three glyphs. In the third set, two characters form a group composed of only one glyph.

Another important consideration is how to treat the text alignment. To justify Latin text, spaces are added between the words and/or characters. But we cannot use this method to justify Arabic texts, as the contextual formatting mentioned above would be affected. Therefore, continuous lines called “kashidas” are inserted between the characters so that each word is a little longer.

The figure below shows an example of a piece of text in Arabic with inserted kashidas (in gray) to create the justified alignment:

Isn’t this cool? We are nearing the end of this series and I have saved my favorite for last. It is a very peculiar visual feature of bidirectional languages. Curious? So stay tuned for the next post!

The figure below clearly shows the difficulties involved.

Have you noticed? The “special treatment” can involve one or more of the following characteristics:

• Character reordering
• Contextual modeling
• Combined and diacritic character display
• Special rules for syllable separation and justified alignment
• Cursor positioning
• Filtering of illegal character combinations

Complex writing systems include the following:

• Arabic language family
• Hebrew
• Thai
• Vietnamese
• Korean
• Greek
• Indian language family

Regardless of the support from the operating system to complex writing systems, some points should be taken into consideration when dealing with the languages above:

• Characters should not be displayed one at a time, but stored in a temporary location (known as a “buffer”) and displayed as a full string (or word), drawing on resources from the operating system for this manipulation.

• To calculate the amount of buffer memory needed, a glyph should not be considered the same as a character. Use the OS support to reach a precise calculation.

• To calculate line sizes, do not consider only character lengths.

It is getting a little complicated, right? Did I not tell you? But keep it up as this is still a very interesting topic and we are about to finish this internationalization series.

In the next post, we will find out what the Arabs and Jews have in common.

US Keyboard Layout

Arabic Keyboard Layout

Thai Keyboard Layout

Russian Keyboard Layout

Brazilian Keyboard Layout

Not all characters exist on all keyboards. To address this lack of physical space, keystroke combinations were created. However, when you are using such combinations, make sure they will work on keyboards of different languages.

Since each region uses a different keyboard, it is preferable to use function keys (F4, F5, etc.) and numbers instead of letters for hotkey combinations. Function key combinations and/or numbers are not as user-friendly as letter combinations, yet they do not need to be adapted according to the region. Creating combinations that can be used with the keyboard of each locale will be more convenient for most international users. But it could be complicated for other users, since regions like Central Europe, Western Europe and Arabic and Hebrew speaking countries have more than one standard keyboard.

Another important point for displaying text are line breaks and syllable separation. In Western languages, the use of line breaks follows hyphenation rules or whitespace-based word boundaries (spaces, tabs, end of line, punctuation, etc.). However, Asian language rules are completely different. Chinese, Japanese and Korean, for example, do not use spaces to indicate differing words. In these languages, internationalized applications cannot position line breaks according to spacing or standard hyphenation rules.

Here is an example in Japanese: The line breaks in Japanese are based on the kinsoku shori rule, according to which line breaks can be placed between any two characters, with the following exceptions:

• A line of text cannot end in open quotes or open parenthesis as they cannot be separated from the characters that follow.
• A line of text cannot begin with closed quotes or closed parenthesis, as they cannot be separated from the preceding characters.
• Currency symbols cannot be separated from the numbers that follow.
• Certain punctuation characters can extend beyond the right margin (in a horizontal text layout) or the bottom margin (for vertical text layout).

Rather complicated, is it not? Speaking of which, we will learn about complex writing systems in the next post. Not to worry, it will be much easier than it sounds.

 You may think that all existing ways of ordering are already known and that this process should be easy to resolve during the internationalization of an application. However, end users could have differing perspectives as to what constitutes an “ordered” list. Not only can alphabetical order vary between languages but also ordering conventions of dictionary entries and telephone book listings can be completely different from what you are used to.

 In French, for example, words that are spelled identically (except for diacritics , remember them?) are classified by a comparison of the characters from right to left instead of a comparison from left to right, as it is used in English. Asian languages, on the other hand, have diverse ordering, which will vary depending on phonetics, radical order, etc.

 Below are some examples of character ordering:

•  In Norwegian and Danish, æ comes after z; ø after æ; and å after ø.
• In Swedish and Finnish, ü is equivalent to y; w is equivalent to v; å comes after z; ä after å; and ö after ä.
• In German, æ is equivalent to ä, which comes after a; œ is equivalent to ö and comes after o; ue is equivalent to ü, which comes after u; and ? is equivalent to ss.

 See, not everything is as easy as it appears and you could easily get disordered…

In the next post we will talk about some more differences between languages. Stay tuned; there is much more to come…

Therefore, before proceeding with our series on internationalization, I think it’s better to explain two concepts that will be used often moving forward: glyphs and diacritics.

1. Glyphs

The term glyph is used to describe the physical appearance of a character. Computer fonts, for example, form a set of glyphs. Following are some:

Glyphs representing lower case letters ‘a’ with Zapfino font.

Block of Mayan glyphs.

Egyptian glyphs (also known as hieroglyphics).

2.    Diacritics

According to Wikipedia, a diacritic is an ancillary glyph added to a letter, or a basic glyph used, for example, to change the sound of a letter to which it was added. Among the various diacritics in the Portuguese language, there are the acute and grave accents, the cedilla, the tilde, the umlaut…hold on! They don’t have that one anymore!

Now that you have been introduced to my old friends, Glyph and Diacritic, you will see how it will be much easier now to understand the next few posts. Until then!

The most popular measurement system is the Metric System (liters, grams, etc.) yet most English speaking countries use the Imperial System (feet, inches, pounds, etc.), due to British colonization.

The various types of units used for measuring are:

• Length
• Weight
• Area
• Volume
• Temperature
• Paper Size
• Notation of angles, etc.

Once again, as most of the applications that we use on a daily basis are developed in the US, if certain care is not taken during Internationalization, you could have problems to express measurements correctly.

Although this one was rather short, things will start getting pretty technical in the next post. Be prepared…

If an application was not developed in a way to universally tell time and you need it to alert you of something you have scheduled, you could end up being very late. Therefore, it is very important to give your undivided attention to this important detail.

There are two points that should be considered in relation to time display:

a) Use of the 12- vs. 24-hour clock
European, Asian and Latin American countries use a 24-hour clock as opposed to the 12-hour (AM/PM) format used in the United States.

b)  Hour, minute and second separating character
Although the colon (:) is the most commonly used character to separate hours from minutes from seconds, some Asian languages prefer using ideograms. In other parts of the world, one must use a character representing the hour (h), minute (m) and second (s).

A frequent method to indicate a time zone is to use the Greenwich Mean Time (GMT) or the Coordinated Universal Time (UTC) as a base, followed by the time zone. This can be shown as a positive or negative difference in the hour (or the minutes, when the time difference is 30 or 45 minutes). Rio de Janeiro, for example, is at GMT -03:00, while New Delhi is at GMT +05:30.

Another way of indicating time zones is to use the name of the local time zone, which is commonly done in the US. Some examples include PT (or Pacific Time) and ET (or Eastern Time). Still, some points should be taken into consideration:

• Not all countries use time zone names
• Time zone abbreviations can vary from one place to another
• Not all countries consider daylight savings, which doesn’t even start on the same day in the participating countries
• A time zone could have differing names and be translated differently depending on the country and the language

You can find interesting details (even with photos) about the real Observatory in Greenwich, at Wikipedia: http://en.wikipedia.org/wiki/Royal_Observatory,_Greenwich.

In the next post, we will analyze measuring units.

Production Manager Cassius spoke about the opportunities in the localization industry market and the new challenges that resulted from a heated market. You can also see some of our superstar PMs working here at the office.

The piece covered just a bit of everything — localization, sworn translations, companies, freelancers — and showed that the demand for translators in increasing exponentially. This is because Brazil is on the spot due to its economic situation and because it will host major sporting events, such as the World Cup and the Olympics.

Ccaps was feeling already an increase in its workload, which has caused our team to grow significantly in the last few years. Besides Project Managers, we have hired Janayna as our Vendor Manager. She has been coordinating with tighter control and efficiency our search for qualified freelance translators.

Speaking of which, if you are not already part of the Ccaps team, send Janayna your resume already! You can use the hr @ ccaps.net email address, but please remember that we only work with language pairs that include Portuguese or Spanish!

And do let me know what you thought of the Ccaps TV channel on YouTube, OK? We will soon be posting more videos there for you to enjoy.

See you soon!