[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Remaining l10n issues

From: Peter N. Lundblad <lundblad_at_softhome.net>
Date: 2004-05-05 22:55:52 CEST

On Wed, 5 May 2004, Erik Huelsmann wrote:

> [ snip stuff about converting from utf-8 ]
> > we already have suc a function. It's called
> > svn_cmdline_cstring_from_utf8 (or svn_cmdline_cstring_from_utf8_fuzzy,
> > if you don't need strict conversion).
> Yea. Peter got there before I did, but I was about to propose using the
> _fuzzy() variant for user messages, since it generally is more important to
> show half the message then to error out. OTOH that would mean that locale
> settings problems will show up somewhat cryptic...
I don't follow you here. Doesn't _fuzy() convert everything non-ASCII to
?\XXX? I agree that this is good if there is a conversion error, but not
in the normal case. What convert_string_for_output in error.c does is to
try svn_cmdline_cstring_from_utf8() first and if it fails, falls back on
svn_cmdline_cstring_from_utf8_fuzzy() to at least get something out even
if it looks ugly. Isn't that what we want?

About my svn_printf() proposal: We could ofcourse expect all arguments
(format string, and string arguments) to be in UTF-8, use apr_pvsprintf(),
and convert the output afterwards and use fputs() to do the output. I
think, if we standardize on this, it would be less often forgotten in the
future and the code would be easier to read.

> [ ... ]
> > > Then we can localize the strings with revision numbers.
> > >
> > >If anyone is working on one of these (Erik?), please tell me. Otherwise
> > >I'll start tonight.
> > Go ahead.
> Yes, please go ahead. I'm not working on either subject.
I start with SVN_REVNUM_T_FMT, so we can discuss the encoding thing a
little more.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 5 22:47:09 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.