Disable i18n machinery, use correct locale
diff mbox series

Message ID 20191106065347.8518-1-stephen@that.guru
State Accepted
Headers show
Series
  • Disable i18n machinery, use correct locale
Related show

Commit Message

Stephen Finucane Nov. 6, 2019, 6:53 a.m. UTC
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(-)

Comments

Daniel Axtens Nov. 7, 2019, 2:01 p.m. UTC | #1
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
Stephen Finucane Nov. 30, 2019, 3:23 p.m. UTC | #2
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.
Andrew Donnellan Dec. 1, 2019, 11:23 p.m. UTC | #3
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>
Stephen Finucane Dec. 2, 2019, 10:09 a.m. UTC | #4
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

Patch
diff mbox series

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>