We have Simplified Chinese language pages that we wish to serve only to our mainland Chinese customers, and have all other variants of Chinese language (example: zh-TW or zh-sg) tags default to English. Or put differently, I want zh* language-tags (from: http://www.iana.org/assignments/language-tags) to receive English pages and only zh-CN to receive our Simplified Chinese pages. I did try the fallback as well, but the plain "zh" tag among others would still default to Chinese pages for some reason -- even with the: "ForceLanguagePriority Prefer Fallback" option. If I try the 'zh-sg' tag it defaults to the zh-CH page. My theory fell along the same lines as the other problem, where it falls back to the shortest letter code, zh and then picks the first alphabetical choice zh-CH and it never gets to the last step in the apache content negotiation where language priority would take effect. I am unsure if there is a workaround, but this seems like it might have a simple fix similar to what you suggested. I have been unable to figure it out thus far and would appreciate any additional help. Thank you, Alex Sink -----Original Message----- From: jslive@xxxxxxxxx [mailto:jslive@xxxxxxxxx]On Behalf Of Joshua Slive Sent: Monday, August 07, 2006 4:06 PM To: users@xxxxxxxxxxxxxxxx Subject: Re: [users@httpd] Content Negotiation - English zh-TW and Chinese zh-CN On 8/7/06, Alex Sink <Alex.Sink@xxxxxxxxxx> wrote: > Hi, > > Our website correctly handles several languages with content negotiation, > but we wish to direct only our Chinese customers to our simplified Chinese > pages, and have all other Chinese language-tags return English pages. Does > anyone know how to make our Chinese pages only show up for zh-CN browsers? > > After reading the Apache manual and the relevant articles, I became > convinced that modifying the following lines would produce the intended > effect: > > AddLanguage zh-CN .zh-CN > AddLanguage zh-TW .en (was: AddLanguage zh-TW .zh-TW -- pages that are in > development) > > AddLanguage zh .en (was added) > > This does work for the Chinese language tag variants, but it completely > breaks our standard English content-negotiation, so we now get German (.de) > pages where we should be getting English pages.(And English is higher in the > language preferences, so I can only guess it reaches rule 8 of content > negotiation, and picks alphabetically) > > I got the same results on versions 1.3.24 and 2.0.52 of apache(1.3.24 being > our live machine), and would appreciate any help on getting our Simplified > Chinese pages to the appropriate audience and English pages to other Chinese > viewers. Your problem report is not all that clear. My understanding is that you want browsers who send zh-CN in their Accept-Language to get pages with the .zh-CN extension, but you want browsers who send zh-TW to get pages with the .en extension. This could be accomplished by marking the .en pages with two different languages, but I don't believe apache supports that. I see two ways to handle this: 1. create a duplicate copy (or even better, a symlink of) the .en page with the .zh-TW extension and use the standard AddLanguage zh-TW .zh-TW config. You'd be lying to the clients about the language, but that shouldn't be a big deal. 2. Eliminate all references to zh-TW in your config and use LanguagePriority Prefer Fallback (available only in 2.x) (and make sure en is high up in your LanguagePriority) Joshua. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|