[PATCH] Disable i18n machinery, use correct locale

[Andrew Donnellan]

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>

-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd at linux.ibm.com             IBM Australia Limited