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.
Thought?
Bye!
---------------------------------------------------------------------
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