Call for volunteers [was: Re: Localization]

[Lubomir I. Ivanov]

On 13 October 2012 16:00, Mikko Rasa <tdb at tdb.fi> wrote:
> On 13.10.2012 15:25, Lubomir I. Ivanov wrote:
>>
>> erm, i for instance am not a english native, yet prefer all my
>> software to be in english, while keeping a non-english locale.
>> looks like i have to use enviroment variables for subsurface to obey
>> that...but wait subsurface on windows may overwrite my env. variable
>> value by default, so i won't be able to do that...
>
> Out of curiosity, what locale settings do you use?  LC_MESSAGES is the one
> that controls the language used for messages, so I assume you have that set
> to en_US or en_GB.  If other programs respect that but subsurface doesn't,
> then we're doing something wrong.
>
> I use en_US.utf8 for most categories, but fi_FI.utf8 for LC_TIME and C for
> LC_COLLATE.
>
> Windows also offers several categories for localization settings, though I'm
> not certain which one controls (or is supposed to control) the language.
>

i only tried setting LC_ALL with putenv(..) within subsurface, but
from my tests on windows it seems that gettext is only interested in
the LANGUAGE env. variable, but
also the menu text are not translated.
my main point here is that LC_* in the LANG, LANGUAGE env. variables
are not used at all by other windows software and users don't know
that they even exists.
since these values don't exist, we have to force a value on subsurface
runtime for it to be translated. but if we force a value, how would
the user switch languages is completely beyond me.
i'm only seeing this ATM:

adding a command line option:
subsurface.exe -lang=xx_XX

and telling the user that he/she can use it to control the language.

>
>> here an example of a small defragment utility that can switch
>> languages dynamically and store the user setting:
>> http://db.tt/GUu9axn8
>> obviously a vastly superior method...and yet another minus for
>> gettext() from my perspective. :-(
>
>
> The POSIX locale system is pretty broken, I can agree to that.  It allows
> you to do some things that don't make sense (ISO-8859-1 date strings in an
> otherwise UTF-8 system?) and doesn't allow you to do some things that make
> sense (why can't I define a custom date format as an strftime string?).
> It's also generally impossible to change the locale settings of an existing
> session, so you'll have to restart your session if you change anything.
>

ouch. well, that's unfortunate...
it seems there are more restrictions than freedom when depending on locales.

lubomir
--