Fixed #34455 -- Restored i18n_patterns() respect of prefix_default_language argument when fallback language is used. #16735
Conversation
|
@oussjarrousse Does it work for you? |
| @@ -351,7 +351,8 @@ def regex(self): | |||
| @property | |||
| def language_prefix(self): | |||
| language_code = get_language() or settings.LANGUAGE_CODE | |||
| if language_code == settings.LANGUAGE_CODE and not self.prefix_default_language: | |||
| default_language = get_supported_language_variant(settings.LANGUAGE_CODE) | |||
| if language_code == default_language and not self.prefix_default_language: | |||
There was a problem hiding this comment.
This change is due to the fact that we're currently activating a fallback language not settings.LANGUAGE_CODE:
django/django/middleware/locale.py
Lines 40 to 41 in 5b8a043
@claudep What do you think?
There was a problem hiding this comment.
I wanted to emphasize that currently we're activating a fallback language e.g. en. In older versions, we activated settings.LANGUAGE_CODE, e.g. en-us. It is a side-effect of 94e7f47, not an intended change (as far as I'm aware). Now the question 😄 Do you think it's fine? or maybe we should try to avoid this side-effect instead of changing the language_prefix() 🤔 .
There was a problem hiding this comment.
The test would also pass by adding en-us to the global LANGUAGES setting. en-us is the default for LANGUAGE_CODE but it doesn't appear to be in any of the lists of supported languages (and it falls back to en)
There was a problem hiding this comment.
I have the feeling that activating a language which is not in LANGUAGES is a bit weird, even if it's the historic behavior, so would be in favor of keeping the new behavior. However I'm not sure if it has other consequences that could be considered as backwards incompatible. If we keep that, we should also probably change the default LANGUAGE_CODE to en in global settings. Does that make sense?
There was a problem hiding this comment.
I think updating the default for LANGUAGE_CODE to en makes sense.
I guess previously we didn't validate that the LANGUAGE_CODE setting was within LANGUAGES, that en-us is the default is unfortunate but I guess people could also have used other things. 🤔
Some options could be:
- Go with this current change and anyone who has this invalid value for
LANGUAGE_CODEwould not need to make an update. - We could treat
en-usas a alias foren(so similar to this change but a bit stricter to only handle theen-uscase). - Tell people to update the setting.
I'm really not familiar with depreciating things, maybe we should add a warning when your LANGUAGE_CODE is not within LANGUAGES?
There was a problem hiding this comment.
Thanks both, let's have it 👍
If we keep that, we should also probably change the default LANGUAGE_CODE to en in global settings. Does that make sense?
Yes, but we can do this separately as a cleanup in Django 5.0.
felixxm
changed the title
…nguage argument when fallback language is used. Regression in 94e7f47. Thanks Oussama Jarrousse for the report.
felixxm
force-pushed
the
ticket_34455_i18n
branch
from
27f63fb
to
3b47283
Compare
|
@sarahboyce Thanks 👍 I added a release note. |
Ticket: https://code.djangoproject.com/ticket/34455