>> You say that strings in Subversion are in UTF-8. That a function will
>> convert them to the current locale. I can see that's true for errors,
>> and for some other things which call svn_cmdline_cstring_from_utf8().
>> But what about all those simple printf's and fprintf's? They should
>> probably replaced by some kind of svn_cmdline_printf function that
>> takes UTF8 strings. After doing this we can call
>> bind_textdomain_codeset(..., "UTF-8). After doing that gettext will
>> feed only UTF-8 to subversion, no matter which is the current stdout
>> encoding.
>
>
> Which "simple printf's" do you mean? Without reading the source, I
> recall a few instances in the command-line client, and the code that
> generates the config files and bits in the .svn directories.
Grepping the code I find some in subversion/libsvn_subr/opt.c, the
svn_handle_warning function in subversion/libsvn_subr/error.c and many
in the subversion/clients/cmdline directory.
> For the first, yes, I think it would be best if we assume everything
> to be UTF-8 and convert before writing to the console.
I agree.
> For the second; the bits in .svn won't get translated anyway, although
> we should at least define the encoding they use (right now I expect
> the entries file is assumed to be UTF-8, but the README file is
> probably in the "local" encoding -- which is mostly ASCII, but will be
> something else on EBCDIC systems. Hm, and translating the README file
> _might_ make sense...).
IMO that's one of the things that should be translated. It's a message
destined for a (nwebie) local user, who might not even understand English.
> We haven't defined the encoding used by the config files, though, and
> that's another aspect of I18N that we have to consider, because we put
> paths in that file. Both UTF-8 and local encoding have drawbacks, and
> I really couldn't decide between them at this point.
Path's encoding is a thought issue in general. The "least surprise" for
me would be to interpret them as specified in the local encoding. But
this can be decided later...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 15 16:57:31 2004