[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: Nicolás Lichtmaier <nick_at_reloco.com.ar>
Date: 2004-04-15 03:05:05 CEST

>>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.

Then only the core should be modified, the DAV, and then the svnserve
situation can be analized.

>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

They won't have the locale... so what? Default installations should have
all locales. Each one won't be larger than 50-60kb. Distributions'
package maintainers will be adviced to ship them all in the package, or
to properly inform the users the situation.

>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

That might be a point =).

>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.

They will mostly not care. Packages will be encouraged to have all the

>e) Branko has already said he would veto such a server side
>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.

Well... I don't think we could convince each other. I won't insist. =)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 15 03:06: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.