[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: Branko Čibej <brane_at_xbc.nu>
Date: 2004-05-06 00:02:10 CEST

Peter N. Lundblad wrote:

>On Wed, 5 May 2004, [UTF-8] Branko Ä^Libej wrote:
>
>
>
>>Peter N. Lundblad wrote:
>>
>>
>>
>[...]
>
>
>>>Then we have the SVN_REVNUM_T_FMT matter. I think the consensus was to
>>>add
>>>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.
>>>
>>>
>>>
>>I'm not sure this goes into svn_types.h, though. I'd suggest
>>svn_cmdline.h, and call the functino svn_cmdline_cstring_from_revnum.
>>Also note that this function should return the revnum either in UTF-8,
>>or in the output encoding (which is _not_ the same as the native
>>encoding, thanks be to Windows...).
>>
>>
>>
>Except for the command line programs (svn, svnlook, ...) it would also be
>used in error messages in libsvn_wc, libsvn_repos, libsvn_ra_dav,
>libsvn_fs_fs, libsvn_fs_base and libsvn_client. Should all of these depend
>on something that's named cmdline? Wouldn't it be better to have something
>returning UTF8. I proposed svn_types.h because there are already some
>small helpers in there, for example SVN_STR_TO_REV. Maybe we want
>#define SVN_REV_TO_STR(pool, revnum) \
> apr_psprintf((pool), "%" SVN_RENUM_T_FMT, (revnum))
>?
>
>
Good point. Yes, such a macro would be better. But do make sure the
output is UTF-8 -- what you wrote above yields the native encodong.

-- Brane

>//Peter
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 6 00:02:42 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.