On 30/5/02 6:45 PM, "Greg Stein" <email@example.com> wrote:
> On Thu, May 30, 2002 at 05:06:03PM -0500, Karl Fogel wrote:
>> I see three options on the table:
Five? Or Six? Seven anyone?
- Add a repository wide property that gives the charset for log
messages. It could vary from 'local' to 'UTF-8' to ...
- Add a local configuration option that switches the translation on or
- Interpret not having a locale set as 'use no translation'. If you
set a locale, then svn will use it. If you want to use random charsets,
then don't lie in your locale settings.
> - add a second parameter to the relevant data structures and routines
> to hold the character set of the string in question (while we're
> talking about log message here, I think there are others; the rule
> for log msgs will apply everywhere)
>> - Keep them as char *, declare them UTF-8, and convert user input
>> as best we can.
>> - Keep them as char *, declare no particular charset, but don't
>> allow zero bytes.
>> - Convert them back to counted-length strings and treat them as
>> binary data again (I guess this is the most militantly charset
>> neutral option).
> Of the above [seven] approaches:
1) Would require the implementation of global properties in the repository.
In 'no property' was interpreted correctly then this could be implemented
post-1.0 and still be backwards compatible.
2) Config options are not always a good idea. Having a local config option
is worse as it removes any guarantees about log messages in the repos.
3) This mostly the same as option 2.
> ) a second param is very heavyweight from a conceptual and coding
> standpoint. and, in the end, we'll probably have to do conversions
> anyways, so allowing an arbitrary charset rather than fixed doesn't
> seem to buy a lot.
> ) my favoriate. note that the *client* does the conversions. the libraries
> simply assume all text strings are in UTF-8.
> ) untenable for the clients.
> ) this is similar to (), but we just allow more flexibility.
There seems to be a consensus forming for translation. Might I suggest that
people keep option 1 in mind so that if repos properties are implemented at
some later stage they could be used.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Jun 1 14:11:58 2002