Opened 6 years ago

Closed 2 years ago

Last modified 2 years ago

#11915 closed Bug (fixed)

language range request should return sublanguage

Reported by: galund Owned by: ambv
Component: Internationalization Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by ramiro)

If a user's browser includes a request for a language range including a parent language, sub-languages which match should be returned.

For example, if a user's browser sends a header

Accept-Language: pt

And my site has

LANGUAGES = (
#...
  ('pt-br', 'Português (Brazil)'),
#...
)

Then the pt_BR locale files I have should be used. (RFC 2616: '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 "-".')

Right now the only way to get the Portugese returned is for me to relabel my local to just "pt" (which works except that the language will now be mislabelled in the Content-Language header).

Change History (8)

comment:1 Changed 6 years ago by ramiro

  • Description modified (diff)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed
  • Version changed from 1.0 to SVN

This takes us to the following possible scenario: What if the LANGUAGES setting has, in addition to 'pt-br', 'pt-cv' (Portuguese as spoken in Cape Verde)? How and why should Django choose 'pt-br' in preference to 'pt-cv' (or vice versa) if a translation to 'pt' is missing?

(The fact I'm using pt, pt-br and pt-cv in this example is just incidental, the real issue is what matters)

comment:2 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:3 Changed 4 years ago by aaugustin

  • Easy pickings unset
  • Triage Stage changed from Design decision needed to Accepted
  • Type changed from New feature to Bug
  • UI/UX unset

ramiro: I propose to select whichever language comes first in settings.LANGUAGES.

comment:4 Changed 2 years ago by aerkalov

Just a small comment from my side, not sure at this moment how to solve this.

As it is implemented at the moment function all_locale_paths (django/utils/translation/trans_real.py) always returns "django/conf/locale" (with addition of user added locale path directories). That directory already contains translation files for most of the languages with sublanguages (ar, pt, es, en, ...). In example above where user has defined "Accept-Language: pt" Django will accept this as valid choice (because it does have translation for that language) even though user has only defined "pt_BR" for his own applications. Not really sure how one could decide and make a switch to pt_BR language code.

comment:5 Changed 2 years ago by ambv

  • Owner changed from nobody to ambv
  • Status changed from new to assigned

comment:6 Changed 2 years ago by ambv

  • Has patch set

comment:7 Changed 2 years ago by Łukasz Langa <lukasz@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 26e3e7ecb5e4c9af4cd5aa178f65ce1585d3ae07:

Fixed #11915: generic Accept-Language matches country-specific variants

comment:8 Changed 2 years ago by Aymeric Augustin <aymeric.augustin@…>

In 3129d190714216cd83d2494a88f537699a42375f:

Merge pull request #1152 from ambv/issue11915

Fixed #11915: generic Accept-Language matches country-specific variants

Note: See TracTickets for help on using tickets.
Back to Top