Feedback (and workaround): Removing `USE_L10N` like this wasn't the best idea

Django Internals Internationalization
1

(To start off, for those googling and trying to fix the issue: What seems to work currently in Django 5.2 is to set LANGUAGE_CODE to a non-empty string that isn’t an actual language code, and defining the formats in the settings. But that’s a hacky workaround.)

Hi. I’m a first time poster, but have been working on Django projects since 2011, and contributed a bug report or two.

And I’m sorry that my first post here is probably going to be a bit controversial. I love Django as a whole, and am immensely grateful for its existence.

However: I’m astonished that not only did USE_L10N get removed, but also, there was no pushback against this, and the docs were left in a somewhat misleading state?

Some of us (surely I’m not the only one?) want to just always use ISO formats because we care more about precision and interoperability than things looking nice. Maybe we want things to look nice eventually, but don’t want to deal with that /now/. We’re perfectionists with deadlines, after all, right? Also, maybe we wanna render numbers in our templates without worrying that they might be formatted?

I understand that this change was motivated by a desire to clean up the codebase. I just don’t see how there was no alternative to completely removing this feature (or rather, ability to opt out of a feature). And I also don’t see how having magic that we as technical users can’t (easily) opt out of is a good idea.

I assume the ship on the overall change has sailed, but I’d like to point out a few pain points and potential fixes. Some of them are overlapping, some might make others redundant.

  • The format settings don’t provide enough of a warning as to how useless they are, or link to what to use instead. It would help a lot if instead of just the sentence “Note that the locale-dictated format has higher precedence and will be applied instead.” we got
    • A list of places where this setting is even applied ({% localize off %}, as a last-resort fallback, etc)
    • A link to FORMAT_MODULE_PATH with the advice to use that instead
  • The settings docs for FORMAT_MODULE_PATH don’t actually specify what format those formats.py files are expected to be in.
  • We really should be able to opt out of autolocalization in templates globally. The localize block tag isn’t enough. Yes, you can pop it into your base.html if you use one. But that doesn’t help when rendering partial content, for example while using HTMX.
  • We should be able to provide overrides/fallbacks. For example, a format module for “language” "all" could be used before any other language format module. And a “language” of "fallback" could be loaded if nothing else matches.
  • We should be able to opt out of loading Django’s provided formats. That way, if we add support for a language, we get our default/fallback that’s known to work if we forget to define something, or get an error instead of, say, silently formatting integers in data- attributes in templates.
  • Maybe instead of having format modules need to be modules, we could specify a callable instead that returns a dict containing our formats? Then we’d gain the control we need to implement our own defaults/fallbacks/overrides/whatever.

Thanks for reading!