Locale difficulties [was Re: de_CH translation]

[Henrik Brautaset Aronsen]

Den 16.10.12 13:15, skrev Dirk Hohndel:
> 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?

No, as I mentioned in an earlier mail, the nb_NO locale *does not exist* 
in /usr/share/locale:

$ export LC_ALL=nb_NO.UTF-8
-bash: warning: setlocale: LC_ALL: cannot change locale (nb_NO.UTF-8): 
No such file or directory
$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL="C"
$ export LC_ALL=no_NO.UTF-8
$ locale
LANG=
LC_COLLATE="no_NO.UTF-8"
LC_CTYPE="no_NO.UTF-8"
LC_MESSAGES="no_NO.UTF-8"
LC_MONETARY="no_NO.UTF-8"
LC_NUMERIC="no_NO.UTF-8"
LC_TIME="no_NO.UTF-8"
LC_ALL="no_NO.UTF-8"

>> 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...

And *that's* why I want aliases.

> 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?

Not really. :)

But we could rename no_NO to nb_NO regardless, since it's the Right 
Thing™ to do. And sort out the other problems while packaging.

H