latest status and plans

Dirk Hohndel dirk at
Mon Oct 15 09:41:33 PDT 2012

Henrik Brautaset Aronsen <subsurface at> writes:

> Den 15.10.12 16:16, skrev Dirk Hohndel:
>> Henrik Brautaset Aronsen <subsurface at> writes:
>>> open("/Users/henrik/src/subsurface/locale/no_NO.UTF-8/LC_MESSAGES/\0",
>>> 0x0, 0x107CC3350)         = -1 Err#2
>> I'm surprised why the open fails... that seems to be the path we'd have
>> for the "built locally" case.
> I forgot to point out that I deleted the locales when performing this 
> test -- to check what paths gettext tries to look at.  So it's not all 
> that surprising :)

Ahh - I kinda suspected that after I thought about it some more.

>>> Start app bundle from commandline (open -a Subsurface):
>>> open("/Applications/\0",
>>> 0x0, 0x10B6C2350)         = -1 Err#2
>> That also seems reasonable, we just need to add the .mo files at the
>> right spot to the bundle.
> Yeah, I did that in the patch I sent earlier.

I just finished the merge into master and this is now in master as well.

>>> Start app bundle from desktop (double click app icon):
>>> open("/Applications/\0",
>>> 0x0, 0x10D1FC350)         = -1 Err#2
>>> open("/Applications/\0",
>>> 0x0, 0x10D1FC350)         = -1 Err#2
>>> open("/Applications/\0",
>>> 0x0, 0x10D1FC350)         = -1 Err#2
>> And that's just bat shit crazy. Where the HECK do 'nn', 'nb' and then
>> 'en'(???) come from. If you look at the launcher, then the
>> code we inherited from gtk-mac-bundler carefully unsets the environment
>> variables to set up the Apple specific locale names instead. And since
>> Norwegian is apparently not an Apple supported language, the code
>> appears to create something crazy.
>> My guess is that is where you should fix the problem - in the
>> interesting little piece of sed script in there.
> "nn", "nb" and "en" are the default system locales on my system, in 
> preferred order: Norsk Nynorsk, Norsk Bokmål and English.  Norwegian is 
> definately a supported Apple language.    

Interesting - not on my Mac :-)

> I'll look into and see if I can do some changes there.


>>> So, in order to support all scenarios I need to make an alias or two for
>>> the Norwegian translation.  I guess this might be the case for other
>>> languages as well.  Does adding support for language aliases in the
>>> Makefile sound like a good idea?
>> I don't like that. I'd rather fix it in the launcher, given that WE
>> bundle it.
> I hope so.  Worst case scenario for this solution is that we have to 
> have a language mapping table in

I guess that's what is attempted there already, no?


More information about the subsurface mailing list