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

Re: Gettext real issues

From: Ben Reser <ben_at_reser.org>
Date: 2004-04-03 05:37:32 CEST

On Sat, Apr 03, 2004 at 04:04:55AM +0200, Branko ??ibej wrote:
> Yes, in the command-line client.

First of all the only way for the ra libs to pass an error back up to
the client is an svn_error_t. When the servers return a code they
marshall a svn_error_t. Right now the only number that ever gets
marshalled across separately is the error code. And it's marshalled as
a string, not a binary number.

I don't think there is any value in localizing the error code. The
error code is probably going to be far more useful as a 0-9 as that
matches what's in the code. Not to mention the error numbers aren't
printed except when SVN_DEBUG is turned on, which most end users won't
have turned on anyway.

Now the svn_error_t requires that the error message be allocated in the
pool. So I really don't see us switching away from using the APR
functions anytime soon.

Ultimately the string that gets formated by the APR functions do end up
getting printed out with fprintf. But again, everything that is getting
printed will have been formated with APR functions ahead of time with
the exception of the error code as explained above.

There are some cases of fprintf'ing errors directly out of the client,
but these are locally generated errors. They are entirely irrelevent
when considering how to deal with the trying to translate text of the
server generated errors.

> I don't consider the glbc printf manpage to be a definitive reference. I
> didn't find any language in the standard that would _forbid_ printf to
> use locale-specific digits and/or radix.

It doesn't matter what glibc does or even what the various standards
say. APR has a completely independent implementation of these formating
functions.

In order to change this we'd need to make new fields in svn_error_t and
stop using the APR formatting functions. Changing svn_error_t would be
pretty much impossible given our API and the compatability guarantees.

In summary, we should entirely punt on this. You can only think of one
language that this effects. The numbers we'd be translating are of
dubious value being translated anyway as they are likely error codes,
revisions, and the like. And the API changes it would require aren't
possible anyway for the time being.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 3 05:37:52 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.