[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-02 22:46:57 CEST

Ben Reser wrote:

>On Thu, Apr 01, 2004 at 05:01:10AM +0200, Branko ??ibej wrote:
>
>
>>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.
>>
>>
>
>Actually it'd always be strings. I doubt we'd be sending literal
>numbers for error messages down the wire.
>
>
Note that if we /do/ have to send numbers, we can't simply convert them
to strings on the server -- numbers are represented differently in
several languages.

>With DeltaV I think our error messages are already in some XML format.
>But I haven't looked at how flexible this format is. If it could
>support a way of replacing certain contents with certain tags this could
>work, e.g.:
>
><ERRORMSG FILENAME="foo">Couldn't find the file named '%FILENAME%'</ERRORMSG>
>
>If we can let the server know that the client is capable of handling
>such error messages then it can send them. Or if the client isn't then
>it can send the current pre-replaced messages.
>
>I'm inclined to say let's punt on this for now, worry about getting
>local client generated messages translated and then deal with server
>generated stuff.
>
>
Oy, +1.

>If we implement things like above it shouldn't matter which gettext
>implementation we use.
>
>

-- 
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 Fri Apr 2 22:45:40 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.