You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nicolás Lichtmaier <ni...@reloco.com.ar> on 2004/03/30 18:49:52 UTC
Gettext real issues
The real unresolved issue with gettext is handling server side stuff.
In the client we just use the process environment variables (through
setlocale). In client libraries we use the process environment
variables, the including program decision of calling setlocale or not,
but we change the "domain".
In server side libraries (or libraries which are both server and client
side) we are ok with the domain thing but, where do we take the language
settings from? Different connected users will have different locale
needs, there's a need to address that. The problem is that the current
gettext runtime depends on setlocale, and this function does not allow
for a thread to have different settings than the rest of the process.
This will mean that in a threaded Apache we would disturb other threads
if we call setlocale.
We need to have a...
"char *dlgettext(char *domain, char *language, char *msgid)"
Solutions:
1) Modify gettext runtime and include it in a directory.
2) Modify gettext runtime and get the modified version included upstream.
2) Write our own code for accessing the .mo files.
The SVN protocol should be modified so that the client send the locale
preferences to the server. In the DAV version the solution is to use
HTTP's "Accept-Language". Doing this will provide the added benefit of
serving localized content to web browsers wandering through the
repository, as every browser nowadays sends the "Accept-Language" header.
What do you think about these issues?
Bye, Nico.
---------------------------------------------------------------------
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
Re: Gettext real issues
Posted by Branko Čibej <br...@xbc.nu>.
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 <le...@mi.madritel.es>.
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).
/L/e/k/t/u
---------------------------------------------------------------------
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>.
>>You have the power. You can just set LC_MESSAGES to whatever you feel like.
>>
>>
>Well, I'm not sure how GNU gettext is going to work in Windows
>environments. Certainly I'm not going to switch my Windows language
>environment from Spanish. But I don't want Subversion in Spanish just
>because my lang is set to it.
>
>
This is not the time for discussing this, it's too early, but of course
there could be a setting to disable sending this Accept-Language.
---------------------------------------------------------------------
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 <le...@mi.madritel.es>.
On Wed, 31 Mar 2004 11:11:09 -0300, Nicolás Lichtmaier <ni...@reloco.com.ar> wrote:
> You have the power. You can just set LC_MESSAGES to whatever you feel like.
Well, I'm not sure how GNU gettext is going to work in Windows
environments. Certainly I'm not going to switch my Windows language
environment from Spanish. But I don't want Subversion in Spanish just
because my lang is set to it.
And I even less understand how do you propose for my browser to say to a
subversion repository server that I don't want to browse the repository in
Spanish, but still navigate the web with "Accept-Language: es"...
As far as I can see (correct me if I'm wrong, I plainly admit I don't
understand some of the issues because I have no gettext experience at
all), you seem to be forcing me to have Subversion in my environment's
language... Am I wrong?
If I'm right, a client-based answer seems better: I can just delete
es.po or overwrite it with en.po and get happily along. But server-based
answers are plainly *bad* if I don't have the opportunity to say to the
server that I don't want Spanish *for Subversion* only.
> The
> need for translations is not in discussion.
Of course not, as long as users can easily disable it.
/L/e/k/t/u
---------------------------------------------------------------------
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>.
>Hmm.
>
>1) I'm a Spaniard, but I don't want to see Subversion messages in
> Spanish (I usually *hate* the translations, and they are often
> outdated or plainly wrong^1). So I hope the client can be "convinced"
> to send "Accept-Language: en" (or no Accept-Language at all).
>
>2) My webbrowser sends "Accept-Language: es" (I visit Spanish pages in
> the web), but I'd hate to browse a remote repository and get Spanish
> translation on the HTML or XML view... How would that be posible?
>
>
>
You have the power. You can just set LC_MESSAGES to whatever you feel like.
>Note ^1: Even if they're correct, there's an issue of Spanish being
>spoken by 350+ Mp in a few dozen countries, each one of them with
>localities. Call me snob, but I prefer to read "type" than "tipee",
>"schedule" than "agendado" (and don't get me started on "comando", which
>is a military person, according to the RAE :) I'm not saying the
>translation is incorrect, I'm pretty sure they're the right word for you,
>but they're positively weird for me.
>
>
This is off-topic. I have co-workers who can't read English here. The
need for translations is not in discussion.
---------------------------------------------------------------------
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 Tue, 30 Mar 2004 23:55:39 -0300
Nicolás Lichtmaier <ni...@reloco.com.ar> wrote:
> I think it's simpler than that. The client would send "Accept-Language:
> es", then the server would check for a
> "/usr/share/locale/es/LC_MESSAGES/subversion.mo" file. If this file is
> there, then it would be used to provide the messages.
Hmm.
1) I'm a Spaniard, but I don't want to see Subversion messages in
Spanish (I usually *hate* the translations, and they are often
outdated or plainly wrong^1). So I hope the client can be "convinced"
to send "Accept-Language: en" (or no Accept-Language at all).
2) My webbrowser sends "Accept-Language: es" (I visit Spanish pages in
the web), but I'd hate to browse a remote repository and get Spanish
translation on the HTML or XML view... How would that be posible?
Note ^1: Even if they're correct, there's an issue of Spanish being
spoken by 350+ Mp in a few dozen countries, each one of them with
localities. Call me snob, but I prefer to read "type" than "tipee",
"schedule" than "agendado" (and don't get me started on "comando", which
is a military person, according to the RAE :) I'm not saying the
translation is incorrect, I'm pretty sure they're the right word for you,
but they're positively weird for me.
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 Nicolás Lichtmaier <ni...@reloco.com.ar>.
>>The SVN protocol should be modified so that the client send the locale
>>preferences to the server. In the DAV version the solution is to use
>>HTTP's "Accept-Language". Doing this will provide the added benefit of
>>serving localized content to web browsers wandering through the
>>repository, as every browser nowadays sends the "Accept-Language" header.
>>
>>
>
>Right. However, to properly support that, a query function will also be
>required to find out which language bundles are available. Code within
>Apache or mod_dav_svn or wherever will match up the Accept-Language header
>against what is available, and pop out an answer.
>
>The alternative to a query is some kind of configuration setting that says
>"these are available". That moves from a dynamic/automatic environment to
>a manual config system (which is not as handy, obviously).
>
>
I think it's simpler than that. The client would send "Accept-Language:
es", then the server would check for a
"/usr/share/locale/es/LC_MESSAGES/subversion.mo" file. If this file is
there, then it would be used to provide the messages.
---------------------------------------------------------------------
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>.
Justin Erenkrantz wrote:
> --On Wednesday, March 31, 2004 1:01 AM -0500 Greg Hudson
> <gh...@MIT.EDU> wrote:
>
>> Hm. It seems like Nico's suggested approach is a much simpler change
>> than what you're suggesting, and they both have weaknesses of roughly
>> equal magnitude. (Nico's fails when the server doesn't have a language
>> file for your language; yours fails when the client doesn't know about
>> the particular error generated by the server.)
>
>
> Yes, but whom do we think is going to be more likely to upgrade? If
> it matters to you as a user to have the 'latest' translations, then I
> think it's reasonable to place that burden solely on the client. If
> we place the burden on the server, then we'd force them to upgrade to
> deliver new translations to their users. To me, that seems harsh -
> especially when we're going to all this effort to maintain
> client/server compatibility between versions.
"newer translations" are not that important. What it's important is
translations for new messages. New messages will always be introduced
with new server releases. If a server upgrades it will probably get some
new or modified messages, and clients will see them right away.
> Of course, if you don't recognize the error code, you just display the
> 'raw' message. But, if you get back a bogus translation, that doesn't
> help you at all as you can't fall back onto something better. So, I
> think the failure mode with client-translated errors is easier to
> recover than being fed poor/out-of-date translations over the wire.
> -- justin
But gettext will not ever deliver an out-of-date message. Never. Why?
Because the lookup search is done using the original message as the key.
When the original message changes, obsolete translations are no longer
found in the .mo, and the English message is shown. That's a very nice
handling of the issue on the part of gettext.
---------------------------------------------------------------------
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 Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 31, 2004 1:01 AM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> Hm. It seems like Nico's suggested approach is a much simpler change
> than what you're suggesting, and they both have weaknesses of roughly
> equal magnitude. (Nico's fails when the server doesn't have a language
> file for your language; yours fails when the client doesn't know about
> the particular error generated by the server.)
Yes, but whom do we think is going to be more likely to upgrade? If it
matters to you as a user to have the 'latest' translations, then I think it's
reasonable to place that burden solely on the client. If we place the burden
on the server, then we'd force them to upgrade to deliver new translations to
their users. To me, that seems harsh - especially when we're going to all
this effort to maintain client/server compatibility between versions.
Of course, if you don't recognize the error code, you just display the 'raw'
message. But, if you get back a bogus translation, that doesn't help you at
all as you can't fall back onto something better. So, I think the failure
mode with client-translated errors is easier to recover than being fed
poor/out-of-date translations over the wire. -- justin
---------------------------------------------------------------------
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 00:49, Justin Erenkrantz wrote:
> No. Since a lot of people don't have GNU gettext or choose to disable NLS, I
> wouldn't expect every server to be able to perform server-side localizations.
> I think it'd be a shame if we had to rely upon the server for translation.
> This isn't like web pages where the translated content would be unknown. The
> presence of an error code should be enough to allow standardized client-side
> localization, I think.
Hm. It seems like Nico's suggested approach is a much simpler change
than what you're suggesting, and they both have weaknesses of roughly
equal magnitude. (Nico's fails when the server doesn't have a language
file for your language; yours fails when the client doesn't know about
the particular error generated by the server.)
---------------------------------------------------------------------
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 Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 31, 2004 12:15 AM -0300 Nicolás Lichtmaier
<ni...@reloco.com.ar> wrote:
> Packages always unconditionally install every language, as .mo files aren
> small. (Check your own /usr/share/locale directory.) I don't see why
> subversion would do a different thing.
No. Since a lot of people don't have GNU gettext or choose to disable NLS, I
wouldn't expect every server to be able to perform server-side localizations.
I think it'd be a shame if we had to rely upon the server for translation.
This isn't like web pages where the translated content would be unknown. The
presence of an error code should be enough to allow standardized client-side
localization, I think. -- justin
---------------------------------------------------------------------
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 Wed, Mar 31, 2004 at 12:15:06AM -0300, Nicol?s_Lichtmaier wrote:
> Packages always unconditionally install every language, as .mo files
> aren small. (Check your own /usr/share/locale directory.) I don't see
> why subversion would do a different thing.
This is simply not true, for instance on Mandrake (an RPM based distro):
$ cat /etc/rpm/macros
%_install_langs en_US:en
Which means only en_US or en will be installed. In places where all
languages are desired all can be used instead.
This is usually not done because it increases your install size for no
benefit for most people.
I don't think we should worry about localizing error messages from the
server. As far as I can tell Apache doesn't.
But if we decide we really want to do this, it's something that can wait
until 2.0.0 when we have an opportunity to modify the protocols in
radical ways.
--
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 Nicolás Lichtmaier <ni...@reloco.com.ar>.
>>I don't think that's a good idea. It will not work well with different
>>versions in the client and server. Subversion will be widely used, as is
>>CVS now, you can't expect everybody to upgrade. And there are
>>distributions, who will provide somewhat older versions. With your
>>proposal a new version server won't be able to report a properly
>>localized error if this error condition is new.
>>
>>
>
>It seems to me that localization is, well, a local thing. If a person
>speaks Esperanto, it would be a shame for them to require every server
>administrator on the planet to upgrade.
>
>
Packages always unconditionally install every language, as .mo files
aren small. (Check your own /usr/share/locale directory.) I don't see
why subversion would do a different thing.
---------------------------------------------------------------------
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 Mark Benedetto King <mb...@lowlatency.com>.
On Tue, Mar 30, 2004 at 11:51:40PM -0300, Nicol?s Lichtmaier wrote:
>
> >What about just having the messages go onto the wire in a structured
> >way (instead of preformatted), and let the client side deal with the
> >localization?
> >
> >
>
> I don't think that's a good idea. It will not work well with different
> versions in the client and server. Subversion will be widely used, as is
> CVS now, you can't expect everybody to upgrade. And there are
> distributions, who will provide somewhat older versions. With your
> proposal a new version server won't be able to report a properly
> localized error if this error condition is new.
It seems to me that localization is, well, a local thing. If a person
speaks Esperanto, it would be a shame for them to require every server
administrator on the planet to upgrade.
--ben
---------------------------------------------------------------------
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>.
>What about just having the messages go onto the wire in a structured
>way (instead of preformatted), and let the client side deal with the
>localization?
>
>
I don't think that's a good idea. It will not work well with different
versions in the client and server. Subversion will be widely used, as is
CVS now, you can't expect everybody to upgrade. And there are
distributions, who will provide somewhat older versions. With your
proposal a new version server won't be able to report a properly
localized error if this error condition is new.
---------------------------------------------------------------------
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 Mark Benedetto King <mb...@lowlatency.com>.
On Tue, Mar 30, 2004 at 03:04:33PM -0800, Greg Stein wrote:
> > The SVN protocol should be modified so that the client send the locale
> > preferences to the server. In the DAV version the solution is to use
> > HTTP's "Accept-Language". Doing this will provide the added benefit of
> > serving localized content to web browsers wandering through the
> > repository, as every browser nowadays sends the "Accept-Language" header.
>
> Right. However, to properly support that, a query function will also be
> required to find out which language bundles are available. Code within
> Apache or mod_dav_svn or wherever will match up the Accept-Language header
> against what is available, and pop out an answer.
>
> The alternative to a query is some kind of configuration setting that says
> "these are available". That moves from a dynamic/automatic environment to
> a manual config system (which is not as handy, obviously).
>
What about just having the messages go onto the wire in a structured
way (instead of preformatted), and let the client side deal with the
localization?
--ben
---------------------------------------------------------------------
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 Stein <gs...@lyra.org>.
On Tue, Mar 30, 2004 at 03:49:52PM -0300, Nicolás Lichtmaier wrote:
>...
> We need to have a...
>
> "char *dlgettext(char *domain, char *language, char *msgid)"
>
> Solutions:
> 1) Modify gettext runtime and include it in a directory.
> 2) Modify gettext runtime and get the modified version included upstream.
> 2) Write our own code for accessing the .mo files.
I'll defer on this...
> The SVN protocol should be modified so that the client send the locale
> preferences to the server. In the DAV version the solution is to use
> HTTP's "Accept-Language". Doing this will provide the added benefit of
> serving localized content to web browsers wandering through the
> repository, as every browser nowadays sends the "Accept-Language" header.
Right. However, to properly support that, a query function will also be
required to find out which language bundles are available. Code within
Apache or mod_dav_svn or wherever will match up the Accept-Language header
against what is available, and pop out an answer.
The alternative to a query is some kind of configuration setting that says
"these are available". That moves from a dynamic/automatic environment to
a manual config system (which is not as handy, obviously).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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 Tue, 2004-03-30 at 12:49, Nicolás Lichtmaier wrote:
> What do you think about these issues?
I think you're getting a step ahead of the rest of us. :-)
Seriously, we're still busy trying to figure out which gettext to use,
and how to get it fully integrated into our build system. This is "step
1" in my proposed l10n plan. You're discussing a bunch of "step 2" code
refactoring problems. Can you postpone the discussion just a little
longer?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org