[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