FOR ARCHIVAL PURPOSES ONLY

The information in this wiki hasn't been maintained for a good while. Some of the projects described have since been deprecated.

In particular, the "Ushahidi Platform v3.x" section contains information that is often misleading. Many details about this version of Platform have changed since.

This website is an extraction of the original Ushahidi wiki into a static form. Because of that, functions like logging in, commenting or searching will not work.

For more documentation, please refer to https://docs.ushahidi.com

Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

This page is about Localization best practices for developers. If you are looking for information on adding Languages to you deployment go here

Ushahidi is built on Kohana which provides language some localization helpers. See the Kohana docs for more info: http://docs.kohanaphp.com/general/i18n

Tips when creating strings

Never hard code strings

Good
Bad

Don't split strings

Example:
You're including a heading 'Approved Reports'.

Good

There's already a translation string for 'Reports' so we could just reuse it:

Bad

However thats a bad idea..
1. it provides translators with no context
2. it assume the words will always appear in that order, when for example the French translation is more like: 'Rapports approuvés'

Use arguments and string formatting

Example:
You're including a reports count: 'Showing 10 - 20 reports'

Good
Bad

Use explicitly ordered placeholders:

Good
Bad

Why? Because ordering my vary in other languages. The 1st version gives translators no context and assumes all languages structure sentences the same way. Using arguments and formatted strings is much better.
In some languages the string transliterated back to English might read something like:

Alternative Text

Exception: when there is only 1 placeholder
When theres just 1 placeholder in the string, its ok to use unordered placeholders

Don't create string in ALL CAPS

Creating strings in all caps means when the design changes and you want search in lower case.. all the translations have to change.
And if themers want the text in lower case, they have to hack the translation files.
If you do this the good way, when the design changes you can just update the code..

Good
Bad

Even better might be to replace the string to upper call with a CSS text-transform, making life even easier for themers.

Use utf8 functions when transforming text

PHP's built in string manipulation functions don't always handle UTF8 characters. Use Kohana's utf8 library where you can instead (http://docs.kohanaphp.com/core/utf8)

Good
Bad