[sword-devel] swlocale question

[Matthew Talbert]

> It looks like you can call GetUserDefaultUILanguage() -- see
> http://msdn.microsoft.com/en-us/library/dd318137%28VS.85%29.aspx
>
> That returns a LANGID which is a numeric code.  There seems to be a
> (very recently published) conversion table from the language part of
> this at
> http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-LCID%5D.pdf
>
> That (if you are willing to include a table like that in your code,
> because I can't find an existing MS library function to do the
> conversion!) gets you an RFC4646 language code, which I think is what
> you are after.   http://www.ietf.org/rfc/rfc4646.txt

Well, for us it's easy, because we just use a glib function that does
all this for us. I doubt that it would be worth putting all of this
into the library, though I could be wrong. I don't know who else needs
this functionality who doesn't already have a simple way of doing it.
That is, if we have 5 applications, and each has a 1-line way of doing
this, then that's less code than trying to do this ourselves.

> (1) Is it worth removing a period and everything after it (a character
> encoding), rather than the "first 5 characters" restriction?  If a LANG
> value such as
>
>  AR.utf-8
>
> is valid, then the "5 character" rule gets you AR.ut when you should
> really be comparing just AR.  I think such a construction is
> theoretically valid, but there are no such locales in
> /usr/share/i18n/SUPPORTED on my machine here.

It probably is. I think that the setLocale function actually does this
already, so this could be merged with that. However, with the code we
have, if it didn't match with 5 characters, it would just try again
with 2 which would work. I really don't know if we need anything other
than that. That is, it would be faster (theoretically) if we removed
everything after '.' before we started, because it would make it more
likely that it would get a perfect match sooner. In reality, I doubt
that this matters much at all.

> (2) Rather than only looking at LANG, you might want to check
> LC_MESSAGES, then LC_ALL if LC_MESSAGES is empty/unset, then LANG if
> LC_MESSAGES is empty/unset, to be consistent with the way setlocale()
> does things in the Unix world.  man 3 setlocale.

Currently, SWORD doesn't try to read any environment variables at all
to determine locale. It's up to the application to set it. I would
imagine that if it really mattered, the application would need to
check all of these. What we're considering adding to SWORD would just
be matching up relatively common constructs with available locales.

> Lastly, while on this topic: Does SWORD respect the LOCPATH variable
> when finding locale information?  Should it?

As above, SWORD doesn't do anything about finding locales for itself.
It's up to the application. SWORD looks for locales in a couple of
places, but primarily in $SWORD_PATH/locales.d. What does LOCPATH do
and how do you think it should apply to this?

Matthew