Subject: Re: XAP_EncodingManager Question
From: Vlad Harchev (hvv@hippo.ru)
Date: Tue Nov 07 2000 - 02:53:41 CST
On Mon, 6 Nov 2000, Dom Lachowicz wrote:
Hi Dom, Hi abi-dev
> Vlad and others,
>
> I have a question about the XAP_EncodingManager::getLanguageISOName()
> function. Why does it always return "en"? I was thinking that it might be
> better to return "en" if you're writing in an English-speaking locale, "ru"
> for Russian, "de" for German, etc...
It's a stub. XAP_UnixEncodingManager::getLanguageISOName()
returns correct language name since it's a virtual function.
If it always returned 'en', i18n wouldn't work at all under unix.
And yes, it guesses language name from $LANG and some other vars, looks into
locale.alias in various dirs to expand aliases to fully indentify language and
locale name.
> Perhaps there's another way to do what I want? Basically, in my new Pspell
> code, I need to get the 2-letter or 4-letter description of the current
> language. So I need "en" or "en_US" or "en-US" for American English, "de"
> for German, etc... How might I go about getting this information from the
> EncodingManager class without doing some ugly getenv("LANG") hack?
Use getLanguageISOName() and getLanguageISOTerritory() from
"XAP_EncodingManager::instance" to get them.
> Also, I want to add some flexibility to the EncodingManager class, so that
> it can dynamically switch Languages/Locales via some dialog's input. Do you
> think that this is possible?
Current code assumes that there will be only one instance of that object and
that there won't be many initializations of it (i.e. most initialization
functions don't bother to free memory they used if they are called several
times and static variables are used as a cache for values various function
return).
On the other hand, a lot of functions in XAP_EncodingManager such as
conversion from unicode to native charset and vice versa should return the
same values independant of the language of current portion of the document. So
I think for retriving various locale-dependant values such as default marker
for list items or rules of quotes' use should go in other class, like
XAP_LocaleInfo. Several instances of that class would be allowed to exist,
in fact there will be a MRU list of its instances. Each instance should
correspond to one language.
That class could easily use the underlying "database-like" structures and
functions from XAP_EncodingManager (like _[r]map). The prototype as I see it:
struct XAP_LocaleInfo
{
/* this will look up already created instances in the list of already-created
for given lang/terr combination. If it's not there, new instance will be
created and ptr to it returned. User code should use this function for
getting a reference to XAP_LocaleInfo they want. The return value can
be cached.
*/
static XAP_LocaleInfo* get(const char language,const char* territory);
/*
Functions for getting various properties follow. They return values
from member variables that were filled in by "_init()" method.
*/
UCS_Char list_marker() const { return _list_marker; }
UCS_Char* left_quote() const { return _left_quote; }
UCS_Char* right_quote() const { return _right_quote; }
private:
/*these are "cooked answers" filled in by _init(). */
UCS_Char _list_marker,*left_quote,*_right_quote;
/*
this one is called by "get()". It fills all "cooked answers".
it can use config files and static tables (of type _map and _rmap
as in xap_EncodingManager.cpp) using language and territory as
keys.
*/
void _init();
};
Sorry I don't have time to code it myself in full.
> Any help is appreciated,
> Dom
Best regards,
-Vlad
This archive was generated by hypermail 2b25 : Tue Nov 07 2000 - 03:33:24 CST