Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • So they'd say they'd want "en-US, ja" documents, and they'd get the Japanese document where an English one was available. With the upgrade, users now correctly get the English version.

    Correctly? I thought that the opposite was the case (if I list "en", I'll be happy with "en-GB" or "en-US" as well), but that if I only list "en-US, ja" then that means "US English, or any kind of Japanese", but not plain "en" nor any other "en-*".

    *digs around a little* That's what I gather from my reading of section 14.4 o

    Esli epei eto cumprenan, shris soa Sfaha.
    Aettot ibrec epesecoth, spakhea scrifeteis.

    • The RFC expresses what it wants the language tags to mean. However, experience shows that users mean other things by it. They assume that by selecting "en-gb", they will be served any kind of English document if British English is not available -- and user-agents do not provide any guidance otherwise. What's more, many/most user-agents start out with a very specific accept-language (like "en-US", sans "en") based on the user's locale, and never even mention this to the user.

      Given these nouveaux exigences, I consider my implementation to be optimal.

      • Ah, I see.

        I presume this only happens if the user does not specify the exact tag as well?

        For example, if someone says they want "en-gb, fr, en" and you have a French and a US English version, which will they get? (I'd assume the French, since "en" comes after "fr" even if "en-gb" is earlier.) What about if you have a French and a "generic" English version?

        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.