Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
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 of RFC 2616 as well: A language-range matches a language-tag if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the prefix is "-".

    By my understanding, "language-range" is what's sent in the Accept-Language: header of an HTTP request, and "language-tag" is the tag associated with a resource.

    Then a language-range of "en" would match a tag of "en-US", but one of "en-US" would not match a tag of "en" (since "en-US" is neither equal to "en" nor is "en-US" a prefix of "en").

    RFC2616 even warns about this: we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior.
    --

    -- 
    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 exigenc

      • 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.