From: Dom Lachowicz (doml@appligent.com)
Date: Thu Oct 31 2002 - 21:52:27 EST
> 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
This archive was generated by hypermail 2.1.4 : Thu Oct 31 2002 - 22:01:24 EST