Hi

I'm working on localization for the fpGUI project. My idea is for the fpGUI toolkit to look for "fpgui.%s.po" files. Where %s is the language ID. e.g.: 'en' or 'af_ZA' or 'en_GB' etc.

Under Ubuntu Linux, if I call GetLanguageIDs() it returns the following two IDs.

SystemLanguageID1 = en_ZA.UTF-8
SystemLanguageID2 = en

The problem here is the '.UTF-8' part. Normally the translation (.po) files look like the following. 'fpgui.en.po' or 'fpgui.af_ZA.po' etc. It never contains the '.UTF-8' part in the po files. So in the case of the Afrikaans translation (af_ZA), the .po file is never found. Am I supposed to handle that, by maybe looking for the '.UTF-8' part and stripping it, or can we extend GetLanguageIDs() to return 3 IDs instead?

SystemLanguageID1 = en_ZA.UTF-8
SystemLanguageID2 = en_ZA (stripping anything from the . onwards) SystemLanguageID3 = en (stripping anything from the _ onwards)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote / napísal(a):

I use getText in my game and I strip anything after 2 chars since I consider only the 2 char lang codes to be valid. Depends I guess...

Ales

At the moment I changed my code to strip anything from the '.' onwards in the first language ID returned. That seems to fix my problem for now. I can't strip anything after two characters because of differences in languages like: pt_BR (Brazilian Portuguese) and pt_Pt (Portugal Portuguese)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys ha scritto:

Usually this difference is ignored in text translation. It becomes relevant for other issues (such as keyboard layout, date and currency format, etc.)

The top, for maximum flexibility wold be: if there's a full match use it, if not find a match with the characters up to "_". So, if you have fpgui.en_US.po, fpgui.en_GB.po, an user from Canada or from Australia (en_CA, en_AU) will still have an English translation (GB or US, the first found), and not a default language af_ZA or whatever.

On Linux it's easy to deal with those matters, because you may just create symlinks, but on Windows, if you use the full qualifier, you're forced to duplicate a lot of files (de_AT,de_DE,de_CH, or fr_FR,fr_CA,fr_CH, etc.).

Giuliano

I already do this. The following example explains the English language search.

1) Look for files like "fpgui.en_XX.po". At the moment I strip the last ".UTF-8" part. Actually anything from the "." onwards (en_ZA.UTF-8 -> en_ZA).
2) If no match found, strip everything from the "_" onwards (en_ZA -> en), which leaves the file "fpgui.en.po"
3) If still no match, then default to the default fpGUI language specified by the developer. English in my case.

.... but on Windows, if you use the full qualifier, you're forced to duplicate a lot of files (de_AT,de_DE,de_CH, or fr_FR,fr_CA,fr_CH, etc.).

Using your example, fpGUI would search for the full qualifiers first. If no match found, then 'de' or 'fr' will be searched, otherwise default to the language specified by the developer.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/