latest status and plans

[Dirk Hohndel]

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

> Den 15.10.12 08:06, skrev Henrik Brautaset Aronsen:
>> Den 15.10.12 06:02, skrev Dirk Hohndel:
>>> I think what we have works well enough on Linux and Mac. I still haven't
>>> had the time to look into a good solution for the mess on
>>> Windows. That's definitely on the TODO list before creating 2.1
>>
>> I haven't looked much at it, but don't think we have a working 
>> translation solution for the bundled Mac .app yet.
>
> I just submitted a patch with better support for the mac app bundles.  
> While I was playing around with dtruss to figure out what gettext does, 
> I noticed that gettext behaves differently when I start Subsurface 
> different ways.
>
> Start from commandline (./subsurface):
>
> open("/Users/henrik/src/subsurface/locale/no_NO.UTF-8/LC_MESSAGES/subsurface.mo\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.

> open("/Users/henrik/src/subsurface/locale/no_NO.utf8/LC_MESSAGES/subsurface.mo\0", 
> 0x0, 0x107CC3350)         = -1 Err#2
> open("/Users/henrik/src/subsurface/locale/no_NO/LC_MESSAGES/subsurface.mo\0", 
> 0x0, 0x107CC3350)         = -1 Err#2
> open("/Users/henrik/src/subsurface/locale/no.UTF-8/LC_MESSAGES/subsurface.mo\0", 
> 0x0, 0x107CC3350)         = -1 Err#2
> open("/Users/henrik/src/subsurface/locale/no.utf8/LC_MESSAGES/subsurface.mo\0", 
> 0x0, 0x107CC3350)         = -1 Err#2
> open("/Users/henrik/src/subsurface/locale/no/LC_MESSAGES/subsurface.mo\0", 
> 0x0, 0x107CC3350)         = -1 Err#2

And yes - this appears to be the sequence of paths it would be supposed
to try. From more specific to less specific, finally just trying "no".

> Start app bundle from commandline (open -a Subsurface):
>
> open("/Applications/Subsurface.app/Contents/Resources/locale/no_NO.UTF-8/LC_MESSAGES/subsurface.mo\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.

> Start app bundle from desktop (double click app icon):
>
> open("/Applications/Subsurface.app/Contents/Resources/locale/nn/LC_MESSAGES/subsurface.mo\0", 
> 0x0, 0x10D1FC350)         = -1 Err#2
> open("/Applications/Subsurface.app/Contents/Resources/locale/nb/LC_MESSAGES/subsurface.mo\0", 
> 0x0, 0x10D1FC350)         = -1 Err#2
> open("/Applications/Subsurface.app/Contents/Resources/locale/en/LC_MESSAGES/subsurface.mo\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 subsurface.sh 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.

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

> Also, I think it's safe to drop the UTF-8 suffix from the locale.

Yes and no. It works in the sane cases. But if someone is running in
ISO-8859-x mode and for odd reasons has fonts (or other infrastructure)
that don't support UTF-8 (that would be an ANCIENT Linux distribution -
as in more than a decade old), then in theory they could be running in
de_DE.ISO-8850-1 and then our .mo file would be WRONG for them.

I'll agree that this is a stretch - but what we have now is (I believe)
correct and so I don't see a reason to drop the .UTF-8 unless someone
can show me a case where this fails and dropping it would work

/D