Difference between revisions of "Pseudo Localization"
(→Video) |
(→What is Pseudo-Localization?) |
||
Line 5: | Line 5: | ||
which covers the topic on this Wiki page. |
which covers the topic on this Wiki page. |
||
+ | |||
== What is Pseudo-Localization? == |
== What is Pseudo-Localization? == |
Revision as of 21:49, 10 April 2024
Contents
Video
For an introduction video on the subject, please see:
which covers the topic on this Wiki page.
What is Pseudo-Localization?
Pseudo-localization is an effective way to test the localization-readiness of an application. By pseudo-localizing the resource files, an application can be tested for internationalization without waiting for localization.
A pseudo-locale is like a regular locale, like de-DE for German translation, but instead of a translation, it modified the source strings in the following way:
A source string like:
- Order placed successfully!
will be localized as:
- [Öŕðéŕ þļåçéð šûççéššƒûļļý!------------- П國カ내]
The pseudo-localize accented string is still legible, so the developer or QA can run the application. A start character, [, is added at the beginning of the string. The string is expanded to reflect possible width of target locales strings. Some characters from other writing systems are added to check for encoding or font issues. An end character, ], is added to show there that the source string ends to help detect concatenations.
When the application uses the pseudo-locale, the pseudo-localized resource text will be displayed.
Creating pseudo-localized resource files help test for
- embedded strings,
- text that was externalized but should not be,
- text expansion issues,
- character-encoding problems,
- text concatenation issues, and
- UI boundary issues can be identified.
An application typically retrieves strings based on a locale, such as French. A pseudo-locale is like a normal locale, but the strings are not translated, they simply show differently.
How to identify i18n Issues with Pseudo-localization
This section shows how to use pseudo-localization to find and correct issues.
UI in the source Locale
First, let's show the user interface in the source locale, here English/US:
UI in the pseudo-locale with issues
Below, the application is running with the pseudo-locale (for example 'esperanto') and the English strings have been pseudo-localized.
Some issues can be identified when the application is running using the pseudo-locale:
- 1 : Truncation: The end characters have been truncated, indicating a likely UI issues around the space set for the text. The UI may need to be refactored to accommodate for longer text in languages such as German.
- 2 : Mojibake: When the pseudo-localized text is showing as mojibake, such as �, this likely indicates a character encoding or a font issue. The application does not support non ASCII characters or non Latin-1 characters.
- 3 : Embedded String / Hard Code String: If the text shows in the original source locale, here English, as opposed to being pseudo-localized, it indicates a likely hard coded string which has not been externalized into a resource file. That string cannot be sent to translation and will show in the interface as the original source string. This is a common internationalization issue.
- 4: Concatenation: The pseudo-localization shows that two strings have been put together to make up Y-Wing Galactic Fighter, since the end character shows up after Galactic Fighter and a start character shows up before Fighter.
UI in the pseudo-locale without issues
If the i18n issues above were corrected, running the application using the pseudo-locale would look like the following:
Configuration
Localyzer makes pseudo-localization quite simple: For the resource files in a repository to be pseudo-localized, edit the Locales by clicking the pseudo-locale checkbox and enter the locale to be used as shown below with eo (esperanto):
Once this configuration is save, every time the project is analyzed, the resource files will be pseudo-localized.