Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#19480 closed New feature (duplicate)

Allow suport for custom i18n backends in Django

Reported by: rtnpro@… 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 rtnpro@…, 11 years ago

comment:2 by rtnpro@…, 11 years ago

Component: UncategorizedTranslations
Has patch: set

comment:3 by Ramiro Morales, 11 years ago

Component: TranslationsInternationalization
Resolution: duplicate
Status: newclosed

Duplicate of #14974

comment:4 by rtnpro, 11 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 Jannis Leidel, 11 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.

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