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

Re: Server side i18n

From: Branko ÄŚibej <brane_at_xbc.nu>
Date: 2004-04-14 08:52:23 CEST

Nicolás Lichtmaier wrote:

> Hi. I still consider that translating in the server is the right thing
> to do:
>
> * There are libraries which run both server and client-side. Some
> of these are already marked-up with _().
>
That's not a problem, gettext can be disabled at runtime on a
per-process, per-domain basis.

> * Messages have parameters (%s). What would we do with them? There
> would need to be an infrstructure just to handle this issue.
>
Only error messages are sent from the server to the client, and there is
special infrastructure to handle those already. We'd only have to modify
it slightly.

> * It should be expected that the client is not just subversion.
> Nowadays you can use WebDAV and HTTP clients (which should get
> translated messages). Some interoperativity with DeltaV
> implementations can be expected in the future too.. right?
>
I've never seen an HTTP server translate its error messages based on my
browser's Accept-Language header, so I don't see why Subversion should
do that. Generic clients can live with the limitation.

> * It should be expected that several compatible subversion clients
> will be in use. It won't be posible for a client to know in
> advance every message a server could throw.
>
So if the client is an older version than the server, a few error
messages will be displayed in English. So what?

> In any case, the current gettext implementation is not well suited for
> server use. Changing the locale affects the whole process, so you
> can't do that in an Apache module. And I don't know if it would even
> be efficient. In addition to this, the license makes difficult to have
> gettext modified to suit these needs.

Bravo! You've just mentioned _the_ reason why servers shouldn't bother
with error message translation. :-)

> So: I've wrote a little, sample, gettext implementation. It uses APR
> (I'm a newbie with it =) ). It depends on having mmap support in APR.
> It does not currently use the hashtable, it just uses binary search to
> find the right message. I don't think this is much slower than the
> hash option. The point of this implementation is that it keeps a
> hashtable of several message-files and let the user specify which
> locale wants in each gettext call. I'm attaching what I've wrote so
> far. As you can see is very easy and simple code.
>
> Thought?
>
I think the last thing we want is reinventing the gettext wheel.
Performance and correctness are very, very important here.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 14 08:52:27 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.