On 8/11/19 1:01 am, Daniel Axtens wrote:
Stephen Finucane <[email protected]> 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
[email protected] IBM Australia Limited
_______________________________________________
Patchwork mailing list
[email protected]
https://lists.ozlabs.org/listinfo/patchwork
