Standard gettext PO format

[Chusslove Illich]

>> [: Chusslove Illich :]
>> It does, I've just checked, my oversight. But it also requires that all
>> languages of the requested catalog are in the same directory, as
>> bindtextdomain takes only catalog name and directory name.
>
> [: Nicolas Goutte :]
> But if you give the resource dir to bindtextdomain, will it not be the
> same? Or very similar? (It is not exactly a problem if we need to change
> where KDE installs the *.gmo files.)

The problem is in this: imagine you have your KDE_LANG (or LANGUAGE) set to 
aa:bb languages. MO files of bb are in system locale directory, and you 
added a few MO files of aa that you want to test in your user locale 
directory. Gettext couldn't handle this case, as it would search for 
catalogs of both aa and bb in the same place.

However, I wonder if this flexibility is really needed. We could say that 
playing with several languages and custom MO files is advanced use anyway, 
so such user could also copy the MO files of bb in the example above to 
his user locale directory when testing. (I guess it wouldn't be a problem 
to bind search directory to first catalog/language combination actually 
found.)

> I suppose that $LANGUAGE should be defined very early while loading KDE.
> (However I do not exactly where, as KDE's initialization is not a part
> of KDE that I know well. Also changing the KControl setting should set
> it too, somehow.)

There is code in klocale.cpp which handles changes to catalogs inside 
KLocale (and is called on startup, before any i18n calls), so I guess I 
could read LANGUAGE there and add its contents to catalogs.

-- 
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/03e301f9/attachment.sig>