Nicolás Lichtmaier wrote:
> 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.
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. 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...).
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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 15 09:19:25 2004