Internationalization- name of mo files Windows / Linux Topic is solved

[TobiasA]

Hi,

I have an application that is available in English US (EN_US) and german (DE_DE).
Languagefiles are stored in <exe directory>\de_de\appname.mo and en_us\appname.mo.
Under windows, this works. Under Linux, it does not- seems it can't find the file even if it is placed in the same directory as under windows, same name.
Is there any special requirement under linux, like requiring en_us somewhere in the name of the mo file or a specific path for it?

Thanks in advance everyone.

[DavidHart]

Hi,

1) Generic answer: look at the relevant wx sample ('internat' in this case) and see what you do that's different .

2) More specifically, a Linux program expects to find its locale files under /usr/share/locale/ so if yours are somewhere different, you may need to announce this with wxLocale::AddCatalogLookupPathPrefix before your AddCatalog() calls.

Regards,

David

[TobiasA]

Strange thing is that I did add the catalog path
I could not find any difference given both the sample and the exact same (working) code under windows

So the name of the file itself doesn't play any role as well as where the file is placed (as long as it gets added via wxLocale::AddCatalogLookupPathPrefix of course)?

If yes, I guess I'll have a coworker looking on some weird typos or something...

[TobiasA]

Well, guess the reason was simply using "en" instead of "en_us" for wxLANGUAGE_ENGLISH_US. I don't know if this is correct, but... Hey, it works.
Will have to use different directories for windows and linux tho since windows will accept en_us.
The question remains how one is able to sort out between english UK and english US, but I think this won't matter this much in reality since rarely ever someone provides both options.

[DavidHart]

Well, guess the reason was simply using "en" instead of "en_us" for wxLANGUAGE_ENGLISH_US

Linux is case-sensitive, so that probably should be en_US (or en_US.utf8 or...)

[TobiasA]

That might be worth a try. However, using "en" with "en_us" works too... Will try en_US too. Thanks for the hint!

[DavidHart]

I should have mentioned: doing in a terminal
locale -a
will tell you what locales are installed on your system.