search

plone / plone.i18n

Text normalization logic and language, country, cctld data.
8 stars 11 forks source link

Fixed does not correctly handle client HTTP_ACCEPT_LANGUAGE is language/country combination issue. #5

Closed jianaijun closed 11 years ago

jianaijun commented 11 years ago

Refer: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.10 http://www.gnu.org/software/gettext/manual/gettext.html#Locale-Names

davisagli commented 11 years ago

I think it would be best to split on both - and _ so that we don't break backwards compatibility for anyone who was assuming they could pass POSIX-style locale identifiers. Adding support for IETF-style language codes does seem like a good idea though.

jianaijun commented 11 years ago

zope/publisher/browser.py always return '-',

refer: https://dev.plone.org/ticket/13309 https://github.com/plone/plone.i18n/blob/master/plone/i18n/normalizer/adapters.py#L30 http://svn.zope.org/zope.publisher/tags/3.4.2/src/zope/publisher/browser.py?rev=82183&view=markup

davisagli commented 11 years ago

I know Plone uses IETF-style codes when it calls this normalizer, but this is a plone.* package which may be used as a library outside Plone, so we can't draw conclusions based only on studying how it is used within Plone. I'm going to make it also split on _ so we don't lose support for dealing with POSIX-style locale identifiers.

jianaijun commented 11 years ago

Thank you for your reply. zope.i18n uses IETF-style codes.