[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-04-15 19:23:21 CEST

On Wed, 2004-04-14 at 19:22, Ben Reser wrote:
> 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.

FTR, that wouldn't be difficult at all.

But it would probably also be possible to extend the svn_error_t
structure before 2.0, if we don't mind duplicating some information. It
would go something like this:

  * Add fields msg_fmt and msg_args to the end of the error structure.
    msg_args is an array of string.

  * svn_error_createf would format the message into the message field,
    and would also quasi-format the message into a format string
    containing only "%s" format specifiers and string arguments. (One
    gross way to perform this quasi-formatting step would be to plant
    distinctive markers around the format specifiers, and then pull the
    strings out of the formatted result.)

  * Find a way of extending the ra_dav error marshalling syntax so that
    we can send the msg_fmt and msg_args data in addition to the regular
    data, without angering old clients.

  * In ra_svn, transmit the msg_fmt and msg_args fields at the end of
    each error tuple.

  * Write a simple routine to perform "%s" substitutions on msg_fmt and
    msg_args. (We can't use apr_psprintf for this purpose because it
    can't take a programmatically-determined list of arguments. Also,
    need it to be proof against malicious data from the server, such as
    an intentionally short argument list.)

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