Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> My idea would be to cache the translated text instead of
Abdelrazak> translating each time updateLabels() is called. But I am
Abdelrazak> not sure I can do that on untranslatable layouts.
This is a problem with multiple languages. I _think_ the problem is
that switching language is expensive with gettext (I am not sure
gettext is designed to change languages very often, like we do).
I think you're right.
If this is the case, then we could cache string/lang pairs.
You mean at gettext.[Ch] level?
Or rather at messages.[Ch] level. As this is set to one unique language
Apparently, this is not true and I don't understand why. The language is
set at construction of the Message class. A language change in the
document will reset the Message object to the new language. Up to that
point I understand.
But, updateLabel() is using Messages::Pimpl::get() and this can change
the language at each call! This is because of this code that checks ans
sets environment variables:
docstring const get(string const & m) const
{
if (m.empty())
return from_ascii(m);
// In this order, see support/filetools.C:
string lang = getEnv("LC_ALL");
if (lang.empty()) {
lang = getEnv("LC_MESSAGES");
if (lang.empty()) {
lang = getEnv("LANG");
if (lang.empty())
lang = "C";
}
}
#ifdef HAVE_LC_MESSAGES
char const * lc_msgs = setlocale(LC_MESSAGES, lang_.c_str());
#endif
This last line in particular looks suspicious. Why do we set environment
variable at each translation request?
This other chunk of code rings a bell in the context of the hebrew RTL
bug (related to LC_TYPE):
// CTYPE controls what getmessage thinks what encoding the po file uses
char const * lc_ctype = setlocale(LC_CTYPE, NULL);
string oldCTYPE = lc_ctype ? lc_ctype : "";
I don't know anything about gettext but this stuff looks awfully
complicated. Couldn't we simplify the thing a bit?
Abdel.
