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

Remaining l10n issues

From: Peter N. Lundblad <lundblad_at_softhome.net>
Date: 2004-05-05 17:19:29 CEST


I'd like to work on the remaining localization issues that have been
discussed on the list before. But I'd like to make sure I understand what
the consensus form these discussions are. I'll start with two of the
remaining things.

First we have the encoding mess... We've converted the .po files to UTF-8
and are going to make _() and friends return UTF-8 strings. So now we need
to convert everything that produces output in the cmdline client to
convert from UTF8 to the locale encoding. I have two proposals for this:
- Either we make something like convert_string_for_output in
libsvn_subr/error.c a public (or internal) function and use it for the
format string in every printf/puts/fprintf/... call.
- We could also invent something like svn_printf(pool, fmt, ...) and the
like. This would expect the fmt to be in UTF-8, recode it and use printf.
This would be easier to use and less verbose. The drawback is that it
would still expect its ... string arguments to be in the native encoding,
or else we would have to rewrite the whole printf functionality.

Any opinions on this?

Then we have the SVN_REVNUM_T_FMT matter. I think the consensus was to
some function svn_revnum_to_string(revnum, pool) function and use it
everywhere, deprecating SVN_REVNUM_T_FMT. Woluld anyone objet to adding
this function to svn_types.h. IMO this shouldn't be a macro, since it is
used in output and not performance critical. Then we can localize the
strings with revision numers.

If anyone is working on one of these (Erik?), please tell me. Otherwise
I'll start tonight.


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