Re: [fwd] Re: [rt-devel] Language detection bug (from: [email protected])

At 2/7/2003 01:13 PM -0500, Jesse Vincent wrote:
>So, some folks are having issues with RT's automatic language detection, 
>which uses Locale::Maketext's infrastructure to do the right thing to 
>guess what the right translation to serve up is. Anyone have comments on 
>what Andrew's seeing?

OK, two things:

1) I just remembered that someone reported a bug where Locale::Maketext 
occasionally mishandled some MIME headers -- I think it was something like 
some Mozilla emitting "Accept-Language: foo;q=.123, bar" and not seeing the 
"foo".  Since you doing are using Locale::Maketext for REAL WORK, I'll try 
to fix this ASAP and get out a new version.

2) Short story:
If you have a lexicon for a language form whose tag is "xx-yy", of course 
you're calling it xx_yy.pm.  But if there's not already a xx.pm, you should 
make there be one, even if it consists of just "package Whatever::xx; use 
base qw(Whatever::xx_yy); 1;".
(Or of course you could just mv xx_yy.pm xx.pm.)

Caveat to short story:
I'm assuming that your xx-yy isn't a weird form of xx that would befuddle 
people who say "I understand xx".  In theory, this is an iffy 
assumption.  In practice, it's a pretty solid assumption.


Long story:
I don't have Locale::Maketext try to implement the thing where if you ask 
for XX, and it doesn't see an xx.pm, it will dish out 
xx-[anything].pm.  The main reason I don't do that it that it's nontrivial 
to have Perl ask "What Foo::Bar::xx_* classes are available?".  A 
mitigating reason is that if I DO ask that, and I get back 
qw(Foo::Bar::xx_yy Foo::Bar::xx_zz), I'm a bit unhappy having to decide 
which to use.  I mean, if someone accepts "en", and I have "en-us" and 
"en-jm" (Jamaican English), /I/ can presume that en-us is probably safer to 
give them; but I don't know of a simple algorithm to do that.  So instead, 
I make the programmer go to the bother of making an en.pm and making it 
synonymous with en_us.pm, etc.

Incidentally, one that that Locale::Maketext does do, is the reverse: if a 
user accepts en-ca, Locale::Maketext will say "OK, I can also just give 
then en.pm".  That is, this accept list:
Accept-Language: en-CA, es-MX
is treated as if it were really:
Accept-Language: en-CA, es-MX, en, es

I suppose I could have easly made it instead work so it would instead read 
it as:
Accept-Language: en-CA, en, es-MX, es
I'm not particularly attached to either way; I bet there's theoretical and 
practical arguments both ways.  Does anyone have a preference?  It's all 
negotiable.


--
Sean M. Burke  [email protected]  http://search.cpan.org/~sburke/