Henrik Nordstrom wrote:
Why are we even having all these aliases? In most cases it should be sufficient with the base language alone.
Eventually partial-code negotiation can be added to do that. It's not present yet.
Language tags may contain all sorts of subtags, with the subtags changing relatively frequently. Having each and every possible combination listed isn't very realistic.
True. And we are not aiming at that. Only the ISO 639 languages and their commonly used sub-codes are being listed.
Right now it's to improve the performance of the negotiation, each detected but failed language requires disk IO. The more commonly occurring aliases we can reduce work on the better. This is the quickest and easiest way while waiting for reliable sub-tag matching.
When sub-tag negotiation is reliably doable we can reduce the aliases to just the weird exceptions.
See http://tools.ietf.org/html/draft-ietf-ltru-4646bis and http://www.iana.org/assignments/language-subtag-registry
I know. And when browsers really start using this widely we will _need_ the sub-tag negotiation. For now its not appearing to be that common. Worse are the browsers sending "chrome://<uri>" where uri is a file needing to be downloaded from an arbitrary server somewhere in order to find out the visitors language preferences.
An convoluted example (copy-pasted) en-Latn-GB-boont-r-extended-sequence-x-private English language in Latin script As used in the United Kingdom region With Boontling jargon With extension "r" "extended" & "sequence" properties With a application-defined private property "private" which for most purposes is equal to en-GB which for most purposes is satisfied by en Regards Henrik
Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13
