Research options for translating/localizing the UI

[GoogleCodeExporter]

How will we handle translations of the interface?

Which libraries/frameworks/... already exist to handle this?

How can we implement this in mC?

How can we offer easy localization for plugins?

Do we want complete localization or just translation of strings?

Original issue reported on code.google.com by bjorn.ol...@gmail.com on 9 Apr 2008 at 8:01

[GoogleCodeExporter]

Okay, I will start to integrate gettext 0.17 (http://gettext.sourceforge.net/) 
for
i18n and l10n. Strings are going to be prefixed with _ (e.g. _("this is a 
string"))
to get detected by the gettext parser (xgettext). This will generate a .mo for 
all
available locales/languages where we and also other users can create their own
translation. 

Original comment by an...@woesten.com on 24 Apr 2008 at 7:27

[GoogleCodeExporter]

I tested gettext and I'm not happy with it. There is only an old and official
implementation (v0.13), but for the new version 0.17 there are only self-built
implementations. I tested some of them and most are instable and use bunches of 
DLL
files. Though I also found static libraries, they cannot be linked easily, 
since they
contain references to missing imports and PDB files. It would result in a mess.

Thus gettext is not our solution - for unix systems it can be fairly good, but 
since
Windows also implements own locales (which are not de_DE but German_Germany) and
codepages, this would just result in a bad mix.

That's why I suggest to implement this functionality by using INI files. INI 
files
support 8-bit and 16-bit charsets (WritePrivateProfileStringA/W) and their 
structure
(2 levels -> sections + properties) suffices for our requirements (config and
language files). I

I suggest following structure (e.g. language/english.ini):

--->>> SNIP <<<---

; Language configuration
[config]
; Name which is also shown in the drop-down box, where you can select the 
language
name=English (US)

; Some language strings
[0]
original=Apple
[1]
original=Banana
[2]
original=Milk

--->>> SNAP <<<---

This is the base file - it's original attributes would be used for the 
translations.
E.g. language/german.ini will look like this:

--->>> SNIP <<<---

; Language configuration
[config]
; Name which is also shown in the drop-down box, where you can select the 
language
name=German
; Use english.ini for 'original' properties of translations
base=english.ini

; Some language strings
[0]
original=Apple
translated=Apfel
[1]
original=Banana
translated=Banane
[2]
original=Milk
translated=Milch

--->>> SNAP <<<---

These files are easy to write for users and we can also easily update them if a 
new
version is going to be released. 

On code-side two classes are implemented into win32cpp - Config and Locale. 
Config
provides basic functionality for creating/reading/writing a config file and 
Locale
provides processing of these language files in the first instance. A map is 
created
on initialization of the Cube with original->translated strings. Locale is a
singleton class which provides a static interface to read these translations 
like:

win32cpp::Locale::get("Apple")

We can also shorten this to _("Apple") for sure (like gettext does do it). 

Original comment by an...@woesten.com on 25 Apr 2008 at 10:17

[GoogleCodeExporter]

Original comment by an...@woesten.com on 7 Oct 2008 at 12:00

• Changed state: Fixed