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

Server side i18n

From: Nicolás Lichtmaier <nick_at_reloco.com.ar>
Date: 2004-04-14 05:58:24 CEST

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 _().
    * Messages have parameters (%s). What would we do with them? There
      would need to be an infrstructure just to handle this issue.
    * 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?
    * 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.

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.

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.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Wed Apr 14 05:58:51 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.