Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#19480 closed New feature (duplicate)

Allow suport for custom i18n backends in Django

Reported by: rtnpro@… Owned by: nobody
Component: Internationalization Version: master
Severity: Normal Keywords: i18n, backend
Cc: jezdez Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no



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 (A live website localisation tool from Mozilla) and (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:

Please review it.


Change History (5)

comment:1 Changed 3 years ago by rtnpro@…

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 3 years ago by rtnpro@…

  • Component changed from Uncategorized to Translations
  • Has patch set

comment:3 Changed 3 years ago by ramiro

  • Component changed from Translations to Internationalization
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #14974

comment:4 Changed 3 years ago by rtnpro

Hey @ramiro

I see that my request is a part of the request at #14974. Could you please review my work at and see if it can be applied to #14974?


comment:5 Changed 3 years ago by jezdez

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