Locale difficulties [was Re: de_CH translation]

[Dirk Hohndel]

Henrik Brautaset Aronsen <subsurface at henrik.synth.no> writes:

> Den 16.10.12 12:49, skrev Dirk Hohndel:
>> Maybe I'm completely missing what you are trying to tell me, but in
>> a normal POSIX locale world (for some definitian of 'normal'), if our
>> locale WAS named nb_NO.UTF-8 then your OS should search for the various
>> .mo files in
>> .../nb_NO.UTF-8
>> .../nb.UTF-8
>> .../nb_NO
>> .../nb.UTF-8
>> .../nb
>> So this seems to indicate to me that with this name for the Norwegian
>> translation things would Just Work (TM)
>>
>> But I guess I am missing something.
>
> Yeah, I think you are :)
>
> Let's go back to the dtruss logs (Re: latest status and plans, 15.10.12 
> 15:03).    When I open Subsurface from the command line, the following 
> locales are searched:
>
> no_NO.UTF-8
> no_NO.utf8
> no_NO
> no.UTF-8
> no.utf8
> no

Could it be that your environment settings in the shell that you run in
Terminal.app are incorrect? Or at least inconsistent to what Apple
thinks they should be?

If you manually set your LANG (or similar locale environment variable)
in one of your shell init scripts to no_NO.UTF-8 than this might explain
what's happening.

If you instead set it to nb_NO.UTF-8 then things should work, right?

> So, with nb_NO.UTF-8 as the locale, it won't find anything.  On the 
> other hand, if I open Subsurface from the desktop, the following are 
> searched:
>
> nn
> nb
> en
>
> Still, with nb_NO.UTF-8, it won't find anything either.

Oh, so from the desktop it ONLY searches the first component, without
regard for the country code... that might mean that we won't get Swiss
German on Mac...

But in that case we could still rescue things if
a) my guess above was correct and nb_NO.UTF-8 would be a better LANG
setting for you
b) we rename the folder when we create the bundle to just be 'nb'

Am I getting closer?

/D