[PATCH] Disable i18n machinery, use correct locale

[Stephen Finucane]

On Mon, 2019-12-02 at 10:23 +1100, Andrew Donnellan wrote:
> On 8/11/19 1:01 am, Daniel Axtens wrote:
> > Stephen Finucane <stephen at that.guru> writes:
> > 
> > > Two issues here. Firstly, the use of the 'USE_I18N'. The Django docs
> > > describe this as such:
> > > 
> > >    A boolean that specifies whether Django’s translation system should
> > >    be enabled. This provides an easy way to turn it off, for performance.
> > >    If this is set to False, Django will make some optimizations so as not
> > >    to load the translation machinery.
> > > 
> > > We don't do translations and won't until such a time as someone comes
> > > asking for them. Optimize things accordingly by setting 'USE_I18N' to
> > > False and removing the now-unnecessary 'LANGUAGE_CODE' setting.
> > > 
> > > Secondly, the use of en-AU is a bit of a lie since our UI is actually
> > > written in US English (or should be). The primary reason for a lang tag
> > > to be present is to assist screenreaders and other accessibility tools,
> > > so make their lives easier by reflecting the truth.
> > 
> > I am not sold on the primacy of US English, and from a historical point
> > of view the UI was absolutely written in Australian English, but before
> > I go down that rabbit-hole, what are the actual implications of setting
> > en-AU vs en-US for anything that might parse the web page? If there's
> > actually a case where the difference would matter, I'd be much happer to
> > consider changing it.
> > 
> > I don't suppose there's a plain "en" language code?
> 
> There is a plain en language code, and I strongly ACK its use over the 
> incorrect so-called English, en_US.
> 
> </australian>

Agreed :)

https://github.com/getpatchwork/patchwork/commit/683b9aa0edbc77e7782576316e0317bd51bcd110

(I spotted Daniel's reply _after_ I'd merged the patch and submitted
this follow up to correct my mistake)

Stephen