Language detection bug

RT Developers
1

Hi,

I confirm something is broken in RT concerning language detection.
I use IE6 on windows 2000.
My language settings are [EN] and [FR], French being usually first.
When connecting, RT seems to ignore the preference order I set. I get the
french language whenever French is present in the list.
When I want to compare my translations with the original, I have to remove
“French” form the list and leave only English. I guess changing the order
should be enough.

Blaise

-----Message d’origine-----De : Andrew Snare [mailto:ASnare@allshare.nl]
Envoye : jeudi 6 fevrier 2003 12:13
A : Harald Wagener; rt-devel@lists.fsck.com
Objet : Re: [rt-devel] fsck.com RT instance Upgraded to 2.1.68

At 10:39 AM 6/02/2003 +0100, Harald Wagener wrote:

if you go to fsck.com/rt2/ where the instance used to live,
you’ll be redirected to rt3.fsck.com, its new home.

When I do that with a web browser identified by the following string:

“Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/51
(like Gecko) Safari/51”

I get some asian looking login screen. The web pages are not german at all
as well, being a mix of misrendered utf8 characters (not Your fault) and
english.

I guess the /de-de/ is not standards compliant.

The de-de in the version string should be irrelevant since for language
purposes it should be using the HTTP-Accept-Language header your browser
sends. I think this is broken in RT, however. I noticed this problem in an
early release of the 2.1 but didn’t have time to investigate.

At any rate, my HTTP-Accept-Language header is:
HTTP_ACCEPT_LANGUAGE=en-au, en;q=0.66, nl;q=0.33

When I aim this at http://rt3.fsck.com/ I get a Dutch page, despite the
fact that English is listed as preferable. If I yank Dutch from the end of
the list, I get an English page (as expected). Hence I think there’s a
problem with the auto-language detection in RT3.

It’s commendable that RT is trying to do the right thing here. One of my
pet hates is web i18n that ignores what your browser says about your
language preferences.

Cheers,

  • Andrew

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

2

I confirm something is broken in RT concerning language detection.
I use IE6 on windows 2000.
My language settings are [EN] and [FR], French being usually first.
When connecting, RT seems to ignore the preference order I set. I get the
french language whenever French is present in the list.

This is because ‘en-us’ is provided, instead of ‘en’. This is arguably wrong,
since there’s no US-specific things in that lexicon – maybe just mv
rt/lib/RT/I18N/en_us.po to en.po?

/Autrijus/

3

At 08:48 PM 6/02/2003 +0800, Autrijus Tang wrote:

This is because ‘en-us’ is provided, instead of ‘en’. This is arguably wrong,
since there’s no US-specific things in that lexicon – maybe just mv
rt/lib/RT/I18N/en_us.po to en.po?

While this fix may work, I think there’s still a bug in the
language-matching. According to my reading of RFC2616, Section 14.4, if
‘en’ is in my list, RT should be matching that against the ‘en-us’ that it
can supply.

  • Andrew
4

At 08:48 PM 6/02/2003 +0800, Autrijus Tang wrote:

This is because ‘en-us’ is provided, instead of ‘en’. This is arguably
wrong,
since there’s no US-specific things in that lexicon – maybe just mv
rt/lib/RT/I18N/en_us.po to en.po?

While this fix may work, I think there’s still a bug in the
language-matching. According to my reading of RFC2616, Section 14.4, if
‘en’ is in my list, RT should be matching that against the ‘en-us’ that it
can supply.

Which part of the language in that section? I’m not seeing it.
FWIW, RT is using Locale::Maketext to do the parsing of the language
tags. Switching from en-us to en seems to be at least one of the right
things to do. If we can make a case for anything else, I’m sure Sean
would be happy to let us try to sell him on it.

-j
  • Andrew

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

5

At 01:28 PM 6/02/2003 -0500, Jesse Vincent wrote:>On Thu, Feb 06, 2003 at 04:44:40PM +0100, Andrew Snare wrote:

At 08:48 PM 6/02/2003 +0800, Autrijus Tang wrote:

This is because ‘en-us’ is provided, instead of ‘en’. This is arguably
wrong,
since there’s no US-specific things in that lexicon – maybe just mv
rt/lib/RT/I18N/en_us.po to en.po?

While this fix may work, I think there’s still a bug in the
language-matching. According to my reading of RFC2616, Section 14.4, if
‘en’ is in my list, RT should be matching that against the ‘en-us’ that it
can supply.

Which part of the language in that section? I’m not seeing it.
FWIW, RT is using Locale::Maketext to do the parsing of the language
tags. Switching from en-us to en seems to be at least one of the right
things to do. If we can make a case for anything else, I’m sure Sean
would be happy to let us try to sell him on it.

I’m reading it again; it’s a little ambiguous. The text we’re discussing,
reformatted, is:
A language-range matches a language-tag if:
1) it exactly equals the tag; or if
2) it exactly equals a prefix of the tag such that the
first tag character following the prefix is “-”.
The special range “*”, if present in the Accept-Language field,
matches every tag not matched by any other range present in the
Accept-Language field.

Definitions, restated to give context and also highlight any bad
assumptions[1] I’m making, are:
language-range:
One of the languages tags in the client-supplied
Accept-Languages
header. Eg: ‘en’ or ‘en-au’
language-tag:
The language tag of the available content on the server.
Eg: ‘en-us’
(NOTE: This is not explicitly defined, unfortunately, and I
may be making an error in assuming this.)

The situation that has occurred, is that people have ‘en’ in their
Accept-Languages header, and the server has ‘en-us’ content available. It
seems to me that these should match since ‘en’ is a prefix of ‘en-us’.

As you mention, switching from en-us to en is one of several possible
solutions. I’d argue against this switch however, for the following reasons:
1) If a user has ‘en-us’ on the list, but not ‘en’, they won’t get
the content. (The prefix rule is one-way). This is apparently quite common.
2) Although there might not be much specifically American in
the translation, it will be American in subtle ways[2].

I hope this helps, one way or the other. Cheers,