Justin Erenkrantz wrote:
> --On Wednesday, March 31, 2004 1:01 AM -0500 Greg Hudson
> <ghudson@MIT.EDU> wrote:
>
>> Hm. It seems like Nico's suggested approach is a much simpler change
>> than what you're suggesting, and they both have weaknesses of roughly
>> equal magnitude. (Nico's fails when the server doesn't have a language
>> file for your language; yours fails when the client doesn't know about
>> the particular error generated by the server.)
>
>
> Yes, but whom do we think is going to be more likely to upgrade? If
> it matters to you as a user to have the 'latest' translations, then I
> think it's reasonable to place that burden solely on the client. If
> we place the burden on the server, then we'd force them to upgrade to
> deliver new translations to their users. To me, that seems harsh -
> especially when we're going to all this effort to maintain
> client/server compatibility between versions.
"newer translations" are not that important. What it's important is
translations for new messages. New messages will always be introduced
with new server releases. If a server upgrades it will probably get some
new or modified messages, and clients will see them right away.
> Of course, if you don't recognize the error code, you just display the
> 'raw' message. But, if you get back a bogus translation, that doesn't
> help you at all as you can't fall back onto something better. So, I
> think the failure mode with client-translated errors is easier to
> recover than being fed poor/out-of-date translations over the wire.
> -- justin
But gettext will not ever deliver an out-of-date message. Never. Why?
Because the lookup search is done using the original message as the key.
When the original message changes, obsolete translations are no longer
found in the .mo, and the English message is shown. That's a very nice
handling of the issue on the part of gettext.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 20:16:34 2004