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 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.
I think the last thing we want is reinventing the gettext wheel.
Performance and correctness are very, very important here.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Apr 14 08:52:27 2004