[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: Ben Reser <ben_at_reser.org>
Date: 2004-04-15 01:22:02 CEST

On Wed, Apr 14, 2004 at 06:38:14PM -0300, Nicolás_Lichtmaier wrote:
> Why do you need to change how errors are handled? You don't agree that
> the server should be the one doing the translation?

There are a number of problems with this:

a) You're assuming the only protocol we have to support is DAV. This
isn't the case. We have the svn protocol (svnserve) to support. I'm
not sure how easy passing along a locale would be to craft onto it
without running into comptability issues.

b) You're still assuming packages always install all locales. This is
simply not true. At one time it was. But modern package management
systems handle only installing the locales the users says they want.
They can optionally install all locales, but most users aren't going to
bother.

c) There are thread safety issues here if we use gettext. So we'd end
up writing our own library. Something that I doubt is going to be very
popular.

d) Branko has made the convincing argument that users are the ones who
want localization. Given that subversion is (hopefully) going to be
adopted by the the open source community. I think it is a poor choice
to require server admins to install extra things in order to make i18n
work for users.

e) Branko has already said he would veto such a server side
implementation.

So while server side translation might get us i18n sooner for server
generated messages, I think it is in generally the wrong way to go.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 15 01:23:25 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.