Standard gettext PO format

[Chusslove Illich]

> [: Nicolas Goutte :]
> As for an example that a user might use, I can think of the system
> having not his language installed and that he install it on its own
> directories.

This would still be possible if Gettext handles language resolution. What 
would not be possible is to have a non-English fallback in that case.

For example: user sets German as his default language (catalogs in system 
dir), but wants to test a bit of Upper Sorbian (catalogs in home dir), so 
he gives KDE_LANG=hsb:de; then, if there is no Upper Sorbian translation 
of a given message, he wouldn't get German translation, but English 
fallback.

I would argue that this situations is quite rare, and if the user has 
copied something to the correct place in his home dir, it wouldn't be to 
hard for him to do it again for the additional fallback language. If the 
translation in home dir is complete enough, or the user wants English 
fallback, then there is no problem at all.

>> [: Chusslove Illich :]
>> 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.
>
> [: Nicolas Goutte :]
> I think that we are misunderstanding us about the use of $LANGUAGE.

Could you clarify? I mean this: if we let Gettext handle language 
resolution, and it looks for order of languages in LANGUAGE, it is easy to 
set LANGUAGE from inside KDE to whatever order KDE defines; eg. first 
languages in KDE_LANG, then settings from config (as chosen in Control 
center), then what was in LANGUAGE originally. Or whatever other priority 
we define.

-- 
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/9ed9221b/attachment.sig>