On Mon, 2019-12-02 at 10:23 +1100, Andrew Donnellan wrote: > 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>
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 _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
