config/6784: No default mapping for en-gb HTTP_ACCEPT_LANGUAGE - more generally language variants have no default mapping

["Kevin F.Quinn" <ma...@kevquinn.com>]

>Number:         6784
>Category:       config
>Synopsis:       No default mapping for en-gb HTTP_ACCEPT_LANGUAGE - more generally language variants have no default mapping
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Thu Nov 02 01:50:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     mail@kevquinn.com
>Release:        1.3.14
>Organization:
apache
>Environment:
uname -a: SunOS escac1 5.7 Generic_106541-04 sun4m sparc SUNW,SPARCstation-20
>Description:
The Apache configuration as shipped includes a language mapping for 'en', but not for 'en-gb'.  I don't know if en-gb is standard or not, but MSIE sends "en-gb" in HTTP_ACCEPT_LANGUAGE if the browser is configured for British English.  There are many other English variants which do not have mappings by default.  Similarly there are many other languages with variants that do not have default mappings.

I haven't checked use of 'en-gb', 'en-za' etc against the RFCs, but I would expect the RFCs to track this usage anyway.
>How-To-Repeat:
Use MSIE to go to the default Apache distribution home page, after configuring the languages to only "English (United Kingdom)" (i.e. do not include "English (en)") followed by "Italian (Italy)" (Tools->Intenet Options, 'General' tab, 'Languages' button).  Under the rules for matching language-specific variants against acceptable languages, Apache serves up the Italian index.html, as the English one index.html.en is not mapped for "en-gb", only for "en".
>Fix:
Several possibilities:
1) Add default mappings for the various language variants.  For example, add "AddLanguage en-gb .en".  This is what I've done on the servers I'm configuring.
2) Change Apache to map language variants by default to the primary language (e.g. serve .en against en-gb, .ar against ar-sa etc) unless explicit mappings are set for the variants.
3) Blame the browser, and get users to add (for example) "English (en)" after "English (United Kingdom)" but before the "Italian (Italy)" or whatever.
4) When writing mult-lingual web sites, copy the .en files to .en-gb etc.

Personally I prefer (1), certainly in the short term - so I've categorised the problem report as 'config'.  (1) is simple, it allows the site admin to serve up separate pages for different variants of the same language if they want to, or not if they don't, and it doesn't entail any change to Apache code.  (2) is appealing as it would cater for any variants that haven't yet been thought of (nations and language designations can and will change, e.g. Yugoslavia...), but it does mean a change to the Apache code.  I don't like (3) as it means changing user configurations, generally harder and always less reliable than changing admin configurations, and (4) is just a pain in the proverbial for site authors.
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]