>>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
>bother.
>
>
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
>popular.
>
>
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
translations.
>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.
>
>
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