[Freeipa-devel] [PATCH 46/46] ticket 1669 - improve i18n docstring extraction

John Dennis jdennis at redhat.com
Thu Aug 25 15:02:21 UTC 2011


On 08/25/2011 10:36 AM, Alexander Bokovoy wrote:
> This would have been enough if only gettext supported fallback between
> language translations on the same domain. I.e. if Russian translation is
> not available, try English one and if not, return translation Id. There
> is discussion about similar cases in ambiguous translations of GUI
> messages and solution proposed is a wrapper around gettext() to lookup
> other means for fetching translations.

Gettext does support fallback to the original msgid. In other words if 
the msgid (the original string, English in our case) cannot be located 
in the current catalog (i.e. the mo file mapped to the locale in domain) 
then the original msgid is returned.

The difference is the gettext uses strings as id's, other systems use 
integers and require a default catalog to be installed. If the integer 
id is not present in the locale it's fetched from the fallback locale.

Each approach has advantages. On the plus side the gettext approach is 
the fact you'll always get the most current string provided by the 
programmer in the source code, there are fewer catalog maintenance 
issues and penalties for letting the catalogs drift out of sync. Of 
course the other approach has some compelling features too.

Bottom line, there are no plans to move away from gettext nor 
re-implement it, so it is what it is :-) We just want to make sure we're 
using gettext and Transifex ecosystem to it's full advantage.

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the Freeipa-devel mailing list