On 08/25/2011 07:50 AM, Alexander Bokovoy wrote:
Read through whole patch. This is one of rare cases where gettext's use
of original text as translation id isn't helpful from both performance
(longer calculation of Id hash during run-time) and maintenance. Looks
like we have to live with that if Transifex is unable to work with
indirected translation ids -- that would mean authoritative original
text would be in 'en' translation, not as original translation id.
If that can't be solved, I'm fine with this approach.
To the best of my knowledge gettext can only use the original string as
the message id. Transifex is built upon the gettext architecture. To the
best of my knowledge gettext is the only i18n translation framework in
use for the software in our distribution. I agree with you that hashing
the original string for lookup is less than ideal but given the above I
think we have to live with it. I'm not aware of any performance
complaints due to the hashing, but I don't read the gettext mailing list.
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
Freeipa-devel mailing list