#28636: Allow customizing the fallback language from the locale middleware
-------------------------------------+-------------------------------------
Reporter: Denis Anuschewski | Owner: nobody
Type: New feature | Status: new
Component: | Version: master
Internationalization |
Severity: Normal | Resolution:
Keywords: translation, | Triage Stage: Accepted
internationalization, request |
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Denis Anuschewski):
There are 3 things about this that come to my mind:
1)
> I think we have a problem in Django i18n in that we generally assume
untranslated strings are in English (some problems you mentioned in
comment:13). We can see that for example in the `en` special-casing in
`DjangoTranslation._add_fallback`.
I agree that having an exception for English in `add_fallback` just
because of how Django's English translation files are or might be
maintained seems awkward. But I would say that it doesn't really address
the core of my problem – that is adding a specific fallback language – so
it would be out of the scope of this ticket (maybe add a new ticket?).
2)
> We may miss a `LANGUAGE_SOURCE` setting (even if we know that non-
English original strings are problematic with gettext when the language
has more than 2 plurals).
I don't think this would work out because a `LANGUAGE_SOURCE` (assuming
that the language of original strings is meant) can be totally different
in your project and for Django's core translations. So in #24413 you would
have Polish as `LANGUAGE_SOURCE` I assume but it still wouldn't work for
this particular issue which was solved with the English exception patch in
`add_fallback`, because the language of original strings in Django's core
is always English. In my case it is German for my project so it would also
be in conflict with Django's language of original strings (so it either
works for your custom translations or for Django's built-in translations).
I would say if you explicitly use a specific language or add a specific
fallback you just have to make sure that translations for your language
are provided! After all you have the possibility to add missing
translations to your own .po files. Or for Django's English core
translation the solution could really be just to make sure all
translations in the .po files are provided, even if it's hellishly
redundant (because msgid and msgstr are always the same).
> I'm still not completely satisfied by my proposal. It only partially
solves the issue, as shown by the hack you are forced to do in the
`process_request` middleware method.
I wouldn't necessarily call it a 'hack' because `process_request` is not
plainly overwritten, it calls `process_request` of the super class and
adds additional stuff so it's nearly as maintainable as setting a flag. A
custom middleware has to be used either way.
But it might be that I have found an even better way to accomplish what we
want. I will test it tomorrow and then make a commit.
--
Ticket URL: <https://code.djangoproject.com/ticket/28636#comment:19>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.edbaeda92a075ab466ebd81f61c7ac1a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
