[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Gettext real issues

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-01 05:01:10 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.