Malcolm Rowe writes:
> On Tue, Apr 03, 2007 at 07:02:35PM +0200, Peter Lundblad wrote:
> > Malcolm Rowe writes:
> > > For some reason, gettext() on my Linux machine has decided that it would
> > > like to translate some of Subversion's output to UK English.
> > > Specifically, 'Authorization failed' now has the UK variant spelling
> > > 'Authorisation failed'.
> > >
> > Ha, so even English-speaking people get hit by this. That's wonderful!
> > :-) In general, I'm not surprised by this, because libc for example might
> > have different translations, but isn't this message coming from our own
> > library?
> Subversion doesn't have an en_GB translation, but clearly someone
> else does. I think in this case the translation might be coming from
> glibc's message catalogue. Or something similar - in any case, we're
> asking gettext() to translate 'Authorization failed' and it's obliging
> (my locale is en_GB.UTF-8).
We're asking gettext, via dgettext, to give us he string from the Subversion
domain, that's what makes me suspicious. But anyway, this is a side issue.
> > LANG=C is what I've been using. The "C" locale is guaranteed to exist.
> > I've just typed LANG=C on the make check command line because I've never
> > been able to figure out the exact interaction between LC_*, LANG
> > and LANGUAGE and how to deal with this portably, but that's probalby
> > just a matter of experimentation. Remember that you need to make sure
> > svnserve starts in the "C" locale as well when testing that
> > protocol.
> 'LANGUAGE= LANG=C' should work everywhere. Since our test suite depends
ON Windows, gettext does more than query envars, but I don't know in which
order. Anyway, it wouldn't worsen the situation.
> upon translated message text, though, shouldn't we set it automatically?
> That was really what I was asking - whether we will break anything by
> making either the test framework or 'make check' set the correct LANG
> environment variables).
I don't think it would break something, but I'm not sure. I think setting
the locale when running the client programs is the best, so that manual test
runs also work out of the box.
> (I was thinking we'd need a UTF-8 locale set to do some of our translation
> tests, but I think I was just getting confused; the C locale should
> be fine).
The only test in utf_tests.py is Skipped because we can't depend on
a specific locale to be available (and if we could, an UTF8 locale would
be the worst choice since then the translations are noops;).
So, yes, +1 for your suggestion.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Apr 4 11:48:53 2007