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 <[email protected]> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
