windows issues with gettext

Dirk Hohndel dirk at hohndel.org
Mon Oct 15 17:22:40 PDT 2012


"Lubomir I. Ivanov" <neolit123 at gmail.com> writes:

> On 16 October 2012 02:14, Dirk Hohndel <dirk at hohndel.org> wrote:
>> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>>
>> During a break I got a quick Windows installer built and tried it in a
>> VM.
>>
>> Everything is localized for German with the exception of buttons that
>> use GTK_STOCK_xxx - we ran into the same problem with menu items before,
>> so this may be a Gtk bug. I'm not sure how to force Gtk to translate
>> those - this works just fine under Linux :-(
>>
>> See this screenshot - the Add / Edit / OK / Cancel buttons clearly
>> aren't localized - but everything else is, right? The menubar on top
>> (including its entries that you can't see), everything in the yearly
>> statistics, etc...
>>
>
> it has to be the runtimes then or something in the toolchain when i'm
> compiling natively.
> here is a complete screenshot from me as well:
> http://i49.tinypic.com/2vn56j8.png
>
> intl.dll over here is bundled with the all the other gtk libraries
> from the official(?) ftp.
> libintl is 0.18.1.0.

I am using a mixture of the libraries that come from Fedora's mingw32
install and a couple from the "official" package (as I get the weird
boxes instead of fonts with the Fedora ones).

What I think I should do is ONLY use the "official" packages (that will
make the "provide source" requirement much easier, too).

Have you tried using Process Monitor with a filter for subsurface.exe
and Path contains ".mo"? This is how I found the issue causing my
problem (see below)... 

> i wonder if this could be caused in the .mo files i.e. from msgfmt

Ok, I figured it out. The way I installed the different .mo files is
inconsistent. We are not bundling the gtk-related ones at all (and I had
manually copied them at some point which is why you and I are seeing
different results, I think).

I need to update the .nsi file so that it picks the correct .mo files
from the gtk installation and puts them into the subsurface installer
bundle. That way we can make sure that the correct files are found.

I now have a fully localized Windows binary - the only thing missing is
correct formatting of dates (and that will require code changes). I hope
I'll have time tonight to get a working .nsi file that can reproduce the
"bundle" (that's the Mac term) that I have manually assembled right now.

/D


More information about the subsurface mailing list