#19480 closed New feature (duplicate)
Allow suport for custom i18n backends in Django
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | i18n, backend |
Cc: | Jannis Leidel | Triage Stage: | Unreviewed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hi,
It will be great for Django to allow developers customise the i18n backends if needed. This will allow developers to tweak with the Django's i18n functions as needed.
This is needed for projects like github.com/mathjazz/pontoon (A live website localisation tool from Mozilla) and https://github.com/rtnpro/django-pontoon-hook (Django hook for Pontoon). Currently, I am monkey patching some of Django's i18n methods to customise their functionality as needed by Pontoon. However, it's not conventional to use monkey patching in production, is it?
I have already worked on adding support for custom i18n backends here: https://github.com/rtnpro/django/commit/35dfea49c83f990780e181c59c10f9702e72f2e1
Please review it.
Regards,
rtnpro
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Component: | Uncategorized → Translations |
---|---|
Has patch: | set |
comment:3 by , 12 years ago
Component: | Translations → Internationalization |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
Duplicate of #14974
comment:4 by , 12 years ago
Hey @ramiro
I see that my request is a part of the request at #14974. Could you please review my work at https://github.com/django/django/pull/590 and see if it can be applied to #14974?
Regards,
rtnpro
comment:5 by , 12 years ago
I'm not a fan of that implementation as it makes a private API (real/null) public. Instead there should simply be a I18N_BACKEND
setting that if set would enable the system and if left unset disable it. The USE_I18N
setting would be deprecated in that case. The scope of this ticket is also too limited compared to #14974, so closing it as duplicate is correct, while it's also not a complete fix for #14974.
Pull request submitted at https://github.com/django/django/pull/590