Re: Commit: ut_locale.cpp,h

[Dom Lachowicz]

Does it actually come straight from $LANG or does it
come from the internally cached values parsed from
$LANG at program initialization?  I ask this because
the Windows code acts in an equivalent manner but of
course has no $LANG variable.  What does this new code
do on a Windows (or other) system?

Some sort of similar method would need to be done in the Win32 port of this class, behind an #ifdef or something. Right now, it blindly uses $LANG. The idea is that in the future, we'll not do that kind of parsing on application startup, but inside of this class' constructor instead, and the APP will use the no-arg constructor on this class to get any relevant information that it might need.

There are 6 methods:
hasLanguageField,  getLanguage
hasTerritoryField, getTerritory
hasEncodingField,  getEncoding

Also remember that the Unix locale can have one more
field, often in practice it tends to be "@euro" where
"@" is the field separator and "euro" is the
"variant".
This field is a bit vague though ):

I can add support for variants. I'll do this in the future, but it may or may not be very useful for us.

Another thing is that the encoding field does not tell
us everything we need to know about the encodings
needed on any particular system.  Specifically the
GUI can use a different encoding and on some non-Unix
but Unix-like systems, the filesystem may also use
UTF-8 I believe.

The encoding field wouldn't be useful in this case anyway, and is not what that field was intended for. I don't foresee using this field for anything at the present time, it's just there for completeness, and so that I could strip out the language and territory easily (the 2 more useful bits for our needs), while ignoring any trailing information.

Dom