Call for volunteers [was: Re: Localization]

Lubomir I. Ivanov neolit123 at gmail.com
Fri Oct 12 04:52:06 PDT 2012


On 12 October 2012 01:21, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>> i can't build due to the new changes (.po/.mo files as such).
>> must spend some time figuring out where to download these gettext
>> tools and how to integrate them with the native build.
>> if you can cross-build for windows i could take a look.
>
> I have uploaded an installer - it's not in the downloads directory (to
> avoid people finding it by mistake and having it fail on them)
>
> http://subsurface.hohndel.org/subsurface-2.0.1-gettext.exe
>

thanks. i was able to run after adding libexpat runtimes (libexpat-1.dll).
not sure why suddenly fontconfig requires it:
objdump -x libfontconfig-1.dll | grep "DLL Name"
        DLL Name: libexpat-1.dll

> This installer does contain the subsurface.mo files that you need.
>
> I'm not 100% sure if subsurface will find them, though, as I don't know
> what the concept of CWD would be during execution of subsurface. I need
> to play with this under Windows today (but first I need to give my last
> presentation at this conference and then head to the airport).
>
> In reality this all will change once we correctly install those files on
> the Unix OSs, too, and change the way Subsurface searches for them.
>

it seem it does not find them and also shows all app text as little rectangles.
i also cannot post any error message, since this is a release build
(i.e. no console output).

i've tried some of the things posted in this thread before running
with no success, like setting:
LC_ALL=xx_XX.UTF-8
LANG=xx_XX.UTF-8

perhaps bindtextdomain() requires an absolute path. it can be obtained
on windows with:
char buf[MAX_PATH];
GetModuleFileName(GetModuleHandle(NULL), buf, MAX_PATH);
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683197(v=vs.85).aspx

atm, can't help much without building.

> I assume that you have a local installation of gtk, so that will have
> gtk's mo files, but for a self-contained Subsurface installer we also
> need to figure out how to package the gtk translations so all this works
> (and I think we only want to package those language/country pairs that
> we support as well, so this will require some more advanced .nsi file
> hacking)
>

not sure how gtk looks for those either. if they are retrieved from an
env. variable, then should be modified / restored on runtime to point
to the "drive:/program files(?)/subsurface/locales" folder. if it also
depends on the bindtextdomain() call then its kind of better...
but yes, having a gtk-dev + gtk-src packages in a folder somewhere
does not means windows knows that gtk even exists, so everything has
to be bundled self-contained when preparing an installer.

lubomir
--


More information about the subsurface mailing list