You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2004/04/01 02:16:53 UTC
Re: Gettext real issues
Juanma Barranquero wrote:
>On Wed, 31 Mar 2004 18:30:37 -0300, Nicolás Lichtmaier <ni...@reloco.com.ar> wrote:
>
>
>
>>This is not the time for discussing this, it's too early
>>
>>
>
>On the contrary, I think is the right moment because it's being discused
>(or at least it was a few hours ago, I'm not up-to-date with this list's
>mail) whether the i18n will be a server- or client-side affair.
>
>
>
>>but of course
>>there could be a setting to disable sending this Accept-Language.
>>
>>
>
>Perhaps I'm being dense. I have no trouble believing that there'll be a
>setting to disable sending Accept-Language *for the svn client*. But I
>don't know how will you make my web browser not to send it (when I'm
>browsing remote repositories).
>
>
This whole conversation is interesting, but beside the point. The
accepted solution in situations like this is that the server sends a
structured message in some common language (usually english), and the
client is responsible for translating it, and if it cannot, it shows the
original. The beauty of gettext is that you don't have to use obscure
message codes.
I will veto any solution that requires the server to translate messages
into a zillion different languages on the grounds that it is abominable. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Juanma Barranquero <jm...@wke.es>.
On Thu, 01 Apr 2004 04:16:53 +0200
Branko Cibej <br...@xbc.nu> wrote:
> The
> accepted solution in situations like this is that the server sends a
> structured message in some common language (usually english),
That's *exactly* what I wanted to hear. I sure hope it is finally
implemented this way.
Juanma
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-31 at 22:16, Nicolás Lichtmaier wrote:
>
> Isn't subversion supposed to be an implementation of a standard
> protocol? (DeltaV, DAV)
Only you use Apache as your server. Not if you use svnserve.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>This whole conversation is interesting, but beside the point. The
>accepted solution in situations like this is that the server sends a
>structured message in some common language (usually english), and the
>client is responsible for translating it, and if it cannot, it shows the
>original. The beauty of gettext is that you don't have to use obscure
>message codes.
>
>I will veto any solution that requires the server to translate messages
>into a zillion different languages on the grounds that it is abominable. :-)
>
>
Isn't subversion supposed to be an implementation of a standard
protocol? (DeltaV, DAV)
Someday there could be other clients accessing the repository. How will
they get localized messages with your approach?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Ben Reser <be...@reser.org>.
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 <be...@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
Re: Gettext real issues
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Sat, Apr 03, 2004 at 02:33:52AM +0200, Branko ??ibej wrote:
>
>
>>No, but printf does if LOCALE is set correctly. But only if it actually
>>sees %d in the format string. If we marshal the number into a string on
>>the server and replace %d with %s in the format strings on the client,
>>the numbers won't get printed correctly.
>>
>>
>
>Umm we don't use printf. We use apr routines for formating.
>
Yes, in the command-line client.
> Which
>ultimately use apr_vformatter. Which doesn't support this. Not to
>mention as someone else pointed out the flags to do this aren't really
>portable anyway.
>
>
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.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 03, 2004 at 02:33:52AM +0200, Branko ??ibej wrote:
> No, but printf does if LOCALE is set correctly. But only if it actually
> sees %d in the format string. If we marshal the number into a string on
> the server and replace %d with %s in the format strings on the client,
> the numbers won't get printed correctly.
Umm we don't use printf. We use apr routines for formating. Which
ultimately use apr_vformatter. Which doesn't support this. Not to
mention as someone else pointed out the flags to do this aren't really
portable anyway.
--
Ben Reser <be...@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
Re: Gettext real issues
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Branko" == Branko Čibej <br...@xbc.nu> writes:
>> First of all gettext provides no way for dealing with this
>> anyway.
>>
Branko> No, but printf does if LOCALE is set correctly. But only
Branko> if it actually sees %d in the format string.
Uh? Accordingly to the fprintf manpage, this is done *only* when you
specify a flag, such as "%'d". Glibc adds a further flag, "I", to
denote alternative output digits. But I think this is well beyond the
scope: as already stated in the past, nobody should count on the revid
being a particular number in a particular base, and I think grouping
the thousands character is stressing the nature of the value.
I cannot properly judge the "I" flag case, though.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Sat, Apr 03, 2004 at 02:00:18AM +0200, Branko ??ibej wrote:
>
>
>>There's at least one modern language I'm aware of that does not use the
>>digits 0-9 (Unicode U+0030 U+0039) to to represent numbers.
>>
>>
>
>First of all gettext provides no way for dealing with this anyway.
>
>
No, but printf does if LOCALE is set correctly. But only if it actually
sees %d in the format string. If we marshal the number into a string on
the server and replace %d with %s in the format strings on the client,
the numbers won't get printed correctly.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 03, 2004 at 02:00:18AM +0200, Branko ??ibej wrote:
> There's at least one modern language I'm aware of that does not use the
> digits 0-9 (Unicode U+0030 U+0039) to to represent numbers.
First of all gettext provides no way for dealing with this anyway.
Second of all, does that mean we should be translating revision numbers?
I'd be most of our numbers are revision numbers anyway, which I doubt we
want to "translate".
This can get really ridiculous really fast.
--
Ben Reser <be...@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
Re: Gettext real issues
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Fri, Apr 02, 2004 at 10:46:57PM +0200, Branko ??ibej wrote:
>
>
>>Note that if we /do/ have to send numbers, we can't simply convert them
>>to strings on the server -- numbers are represented differently in
>>several languages.
>>
>>
>
>I can think of a few examples of this (none of which I think are
>relevent to subversion):
>
>* Punctuation: 1,300.25 vs 1.300,25
>
>* Spelling of the word e.g two vs dos
>
>Are there really any cases where we're using puncutation or
>programatically converting a symbolic number to a lexical number? Is
>there any realistic cases where we would want to start doing this in the
>future?
>
>Is there anything I'm missing?
>
>
There's at least one modern language I'm aware of that does not use the
digits 0-9 (Unicode U+0030 U+0039) to to represent numbers.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Ben Reser <be...@reser.org>.
On Fri, Apr 02, 2004 at 10:46:57PM +0200, Branko ??ibej wrote:
> Note that if we /do/ have to send numbers, we can't simply convert them
> to strings on the server -- numbers are represented differently in
> several languages.
I can think of a few examples of this (none of which I think are
relevent to subversion):
* Punctuation: 1,300.25 vs 1.300,25
* Spelling of the word e.g two vs dos
Are there really any cases where we're using puncutation or
programatically converting a symbolic number to a lexical number? Is
there any realistic cases where we would want to start doing this in the
future?
Is there anything I'm missing?
--
Ben Reser <be...@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
Re: Gettext real issues
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Thu, Apr 01, 2004 at 05:01:10AM +0200, Branko ??ibej wrote:
>
>
>>We can't, but on the other hand I don't think we use more than 3 or 4
>>format codes (%s and several variants of %d) -- and we already have to
>>get rid of the platform-specific formats defined by APR if we want to
>>support localization by gettext, so we'll probably end up with %s, %d
>>and %u. That means marshaling strings (trivial) and sone integer type.
>>
>>
>
>Actually it'd always be strings. I doubt we'd be sending literal
>numbers for error messages down the wire.
>
>
Note that if we /do/ have to send numbers, we can't simply convert them
to strings on the server -- numbers are represented differently in
several languages.
>With DeltaV I think our error messages are already in some XML format.
>But I haven't looked at how flexible this format is. If it could
>support a way of replacing certain contents with certain tags this could
>work, e.g.:
>
><ERRORMSG FILENAME="foo">Couldn't find the file named '%FILENAME%'</ERRORMSG>
>
>If we can let the server know that the client is capable of handling
>such error messages then it can send them. Or if the client isn't then
>it can send the current pre-replaced messages.
>
>I'm inclined to say let's punt on this for now, worry about getting
>local client generated messages translated and then deal with server
>generated stuff.
>
>
Oy, +1.
>If we implement things like above it shouldn't matter which gettext
>implementation we use.
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Ben Reser <be...@reser.org>.
On Thu, Apr 01, 2004 at 05:01:10AM +0200, Branko ??ibej wrote:
> We can't, but on the other hand I don't think we use more than 3 or 4
> format codes (%s and several variants of %d) -- and we already have to
> get rid of the platform-specific formats defined by APR if we want to
> support localization by gettext, so we'll probably end up with %s, %d
> and %u. That means marshaling strings (trivial) and sone integer type.
Actually it'd always be strings. I doubt we'd be sending literal
numbers for error messages down the wire.
With DeltaV I think our error messages are already in some XML format.
But I haven't looked at how flexible this format is. If it could
support a way of replacing certain contents with certain tags this could
work, e.g.:
<ERRORMSG FILENAME="foo">Couldn't find the file named '%FILENAME%'</ERRORMSG>
If we can let the server know that the client is capable of handling
such error messages then it can send them. Or if the client isn't then
it can send the current pre-replaced messages.
I'm inclined to say let's punt on this for now, worry about getting
local client generated messages translated and then deal with server
generated stuff.
If we implement things like above it shouldn't matter which gettext
implementation we use.
--
Ben Reser <be...@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
Re: Gettext real issues
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2004-03-31 at 21:16, Branko Čibej wrote:
>
>
>>This whole conversation is interesting, but beside the point. The
>>accepted solution in situations like this is that the server sends a
>>structured message in some common language (usually english), and the
>>client is responsible for translating it, and if it cannot, it shows the
>>original. The beauty of gettext is that you don't have to use obscure
>>message codes.
>>
>>
>
>I can understand the appeal to this to some extent, but I'm a little
>tired of people using the word "structured" as if it actually means
>something by itself. It's a little like saying, "we should cut taxes
>and spending," without saying what spending cuts you want to make; it
>sounds good on the face of it, but when you get into the details, maybe
>not so many people would agree.
>
>Our error messages (the specific ones, not the generic ones) are format
>strings with some text substituted in for pathnames and rev numbers and
>whatnot. Once the text is subbed in, gettext can no longer look up the
>message, because it doesn't know what part is variant. How can we
>remedy this without building a full-blown RPC marshalling system into
>our error structures?
>
>
We can't, but on the other hand I don't think we use more than 3 or 4
format codes (%s and several variants of %d) -- and we already have to
get rid of the platform-specific formats defined by APR if we want to
support localization by gettext, so we'll probably end up with %s, %d
and %u. That means marshaling strings (trivial) and sone integer type.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Gettext real issues
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-03-31 at 21:16, Branko Čibej wrote:
> This whole conversation is interesting, but beside the point. The
> accepted solution in situations like this is that the server sends a
> structured message in some common language (usually english), and the
> client is responsible for translating it, and if it cannot, it shows the
> original. The beauty of gettext is that you don't have to use obscure
> message codes.
I can understand the appeal to this to some extent, but I'm a little
tired of people using the word "structured" as if it actually means
something by itself. It's a little like saying, "we should cut taxes
and spending," without saying what spending cuts you want to make; it
sounds good on the face of it, but when you get into the details, maybe
not so many people would agree.
Our error messages (the specific ones, not the generic ones) are format
strings with some text substituted in for pathnames and rev numbers and
whatnot. Once the text is subbed in, gettext can no longer look up the
message, because it doesn't know what part is variant. How can we
remedy this without building a full-blown RPC marshalling system into
our error structures?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org