Archives

I will revisit the subject of Software Quality in this post, but now the matter will be more focused on the localization area. Shall we talk about Localization Testing? First, I think it is worth remembering what Localization is…

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.

We have reached the end of the series on Internationalization. As I said before, to me this is one of the most interesting characteristics of Hebrew and Arabic languages.

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!

Have you already discover what Arabs and Jews have in common? A very interesting feature of Hebrew and Arabic languages: they are both written from right to left.

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!

In computer science, complex writing systems are those that need special treatment in order to be processed and displayed; they cannot be handled by the usual methods in the operating system.

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.

As you already know, one way of entering data in the computer is through the keyboard, which becomes a crucial part of our internationalization puzzle. Keyboard layouts vary depending on the location. Below are some examples:

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.