Greg Hudson wrote:
>On Wed, 2004-03-31 at 21:16, Branko Čibej wrote:
>
>
>>This whole conversation is interesting, but beside the point. The
>>accepted solution in situations like this is that the server sends a
>>structured message in some common language (usually english), and the
>>client is responsible for translating it, and if it cannot, it shows the
>>original. The beauty of gettext is that you don't have to use obscure
>>message codes.
>>
>>
>
>I can understand the appeal to this to some extent, but I'm a little
>tired of people using the word "structured" as if it actually means
>something by itself. It's a little like saying, "we should cut taxes
>and spending," without saying what spending cuts you want to make; it
>sounds good on the face of it, but when you get into the details, maybe
>not so many people would agree.
>
>Our error messages (the specific ones, not the generic ones) are format
>strings with some text substituted in for pathnames and rev numbers and
>whatnot. Once the text is subbed in, gettext can no longer look up the
>message, because it doesn't know what part is variant. How can we
>remedy this without building a full-blown RPC marshalling system into
>our error structures?
>
>
We can't, but on the other hand I don't think we use more than 3 or 4
format codes (%s and several variants of %d) -- and we already have to
get rid of the platform-specific formats defined by APR if we want to
support localization by gettext, so we'll probably end up with %s, %d
and %u. That means marshaling strings (trivial) and sone integer type.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 1 05:03:24 2004