| Message ID | 20191106065347.8518-1-stephen@that.guru |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Disable i18n machinery, use correct locale | expand |
Stephen Finucane <stephen@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? Daniel > > Signed-off-by: Stephen Finucane <stephen@that.guru> > Cc: Andrew Donnellan <ajd@linux.ibm.com> > Cc: Daniel Axtens <dja@axtens.net> > --- > patchwork/settings/base.py | 4 +--- > templates/base.html | 2 +- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git patchwork/settings/base.py patchwork/settings/base.py > index b86cdc27..86612d7a 100644 > --- patchwork/settings/base.py > +++ patchwork/settings/base.py > @@ -36,9 +36,7 @@ MIDDLEWARE = [ > > TIME_ZONE = 'Australia/Canberra' > > -LANGUAGE_CODE = 'en-au' > - > -USE_I18N = True > +USE_I18N = False > > TEST_RUNNER = 'django.test.runner.DiscoverRunner' > > diff --git templates/base.html templates/base.html > index 40b6cda6..27db7f52 100644 > --- templates/base.html > +++ templates/base.html > @@ -1,6 +1,6 @@ > {% load static %} > <!DOCTYPE html> > -<html xmlns="http://www.w3.org/1999/xhtml" lang="en-AU"> > +<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US"> > <head> > <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> > <title>{% block title %}Patchwork{% endblock %} - Patchwork</title> > -- > 2.21.0
On Wed, 2019-11-06 at 14:53 +0800, Stephen Finucane wrote: > 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. > > Signed-off-by: Stephen Finucane <stephen@that.guru> > Cc: Andrew Donnellan <ajd@linux.ibm.com> > Cc: Daniel Axtens <dja@axtens.net> Applied.
On 8/11/19 1:01 am, Daniel Axtens wrote: > Stephen Finucane <stephen@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>
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@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
diff --git patchwork/settings/base.py patchwork/settings/base.py index b86cdc27..86612d7a 100644 --- patchwork/settings/base.py +++ patchwork/settings/base.py @@ -36,9 +36,7 @@ MIDDLEWARE = [ TIME_ZONE = 'Australia/Canberra' -LANGUAGE_CODE = 'en-au' - -USE_I18N = True +USE_I18N = False TEST_RUNNER = 'django.test.runner.DiscoverRunner' diff --git templates/base.html templates/base.html index 40b6cda6..27db7f52 100644 --- templates/base.html +++ templates/base.html @@ -1,6 +1,6 @@ {% load static %} <!DOCTYPE html> -<html xmlns="http://www.w3.org/1999/xhtml" lang="en-AU"> +<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> <title>{% block title %}Patchwork{% endblock %} - Patchwork</title>
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. Signed-off-by: Stephen Finucane <stephen@that.guru> Cc: Andrew Donnellan <ajd@linux.ibm.com> Cc: Daniel Axtens <dja@axtens.net> --- patchwork/settings/base.py | 4 +--- templates/base.html | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-)