Standard gettext PO format

Chusslove Illich caslav.ilic at gmx.net
Fri Dec 30 15:09:31 GMT 2005


> [: Josef Spillner :]
> Note that when unloading is not in place, you really need to increase
> the (external) _nl_msg_cat_cntr variable, or otherwise cached results
> might give back wrong translation values.

This kills the performance in the worst case (one language switch on each 
i18n call), but from 150 to 30 kmsgs/sec on my 1.67 GHz Athlon, which 
should still be quite enough.

Then, perhaps it is not really needed in our situation, as language switch 
is performed only when the translation is not found in the first place, so 
there is nothing to cache.

If we drop the full flexibility in catalog locations, the manual language 
switching is not needed. Note that user could still use catalogs from his 
home, that possibility would remain.

>> [: Chusslove Illich :]
>> Third, there is no way to tell if Gettext found a translation, or just
>> returned a fallback string. [...]
>
> [: Josef Spillner :]
> Another reason to request some changes in gettext. In fact there are a
> lot of functions which should be added while still retaining backwards
> compatibility, like the above or the ability to load catalogs directly 
> (specifying a file name).

Again, we need to know if translation is found only if we stick to 
arbitrary location for same catalog in different languages.

I've been asking yesterday about direct catalog loading on Translation-i18n 
(where Gettext maintainer lurks), the reply was that "This is really not
the normal way of using gettext()." And I can't disagree much, as adding 
too many specialized stuff can lead to maintenance nightmare.

While we're at it, yesterday I also got reminded by the compiler that the 
new gettext context call, pgettext(), is a macro which needs string 
literals for msgctxt and msgid. This prevents me from using it as is in 
translate() methods of KCatalog (but it is easy to circumvent), and it 
seems to me that pgettext() should be able to work with const char* even 
in pure Gettext programs (eg. for NOOP stuff). This inquiry is pending...

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051230/3b1d32fa/attachment.sig>


More information about the kde-core-devel mailing list