How is language determined in RT?

Where within/underneath RT is the language to send to the client browser
determined? I don’t believe it is properly implementing the RFC.

Thanks,
Christian

Christian Gilmore
Technology Leader
GeT Support Application Development
IBM Software Group

Where within/underneath RT is the language to send to the client browser
determined? I don’t believe it is properly implementing the RFC.

It actually hands off that determination to Locale::Maketext, which
processes the browser’s Accpet-language: header. What behaviour are you
seeing that’s suspect?

Thanks,
Christian


Christian Gilmore
Technology Leader
GeT Support Application Development
IBM Software Group

http://www.bestpractical.com/rt – Trouble Ticketing. Free.

Jesse,

I’m sending in a header that looks like:

en-us, ja;q=0.8

Instead of getting en back (as matching the en-us tag prefix), I’m getting
ja. The specification isn’t written in clearly understandable way, but I
believe the key element is the following quoted sentence with my
interpretations in brackets from RFC 2616, section 14.4:

A language-range matches a language-tag if it exactly equals the tag [ie,
en-us = en-us or ja = ja], or if it exactly equals a prefix of the tag
[ie, en = en-us] such that the first tag character following the prefix is
"-".

FWIW, I put the I18N::AcceptLanguage module on CPAN a long while ago that
did this determination properly per my understanding of the RFC.

Thanks,
Christian

Christian Gilmore
Technology Leader
GeT Support Application Development
IBM Software Group

Jesse Vincent jesse@bestpractical.com
Sent by: rt-users-admin@lists.fsck.com
08/05/03 01:38 PMTo: Christian Gilmore/Austin/IBM@IBMUS
cc: rt-users@lists.fsck.com
Subject: Re: [rt-users] How is language determined in RT?

Where within/underneath RT is the language to send to the client browser

determined? I don’t believe it is properly implementing the RFC.

It actually hands off that determination to Locale::Maketext, which
processes the browser’s Accpet-language: header. What behaviour are you
seeing that’s suspect?

Thanks,
Christian


Christian Gilmore
Technology Leader
GeT Support Application Development
IBM Software Group

http://www.bestpractical.com/rt – Trouble Ticketing. Free.
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

I’m sending in a header that looks like:
en-us, ja;q=0.8
Instead of getting en back (as matching the en-us tag prefix), I’m getting
ja.

Locale::Maketext thinks superclass languages are not alternates, so
it tries them after all other language selections.

The patch below treats it like alternate language tags, and DWYM.

Thanks,
/Autrijus/

— Maketext.pm.orig Thu Aug 7 15:14:09 2003
+++ Maketext.pm Thu Aug 7 15:16:46 2003
@@ -283,7 +283,7 @@
# if it’s a locale ID, try converting to a lg tag (untainted),
# otherwise nix it.

  • push @languages, map I18N::LangTags::super_languages($_), @languages
  • @languages = map { $, I18N::LangTags::super_languages($) } @languages
    if $MATCH_SUPERS;

    @languages = map { $, I18N::LangTags::alternate_language_tags($) }