Make WordPress Core

Opened 5 years ago

Closed 12 months ago

Last modified 12 months ago

#48152 closed enhancement (wontfix)

en as default language instead of en_us

Reported by: colomet's profile colomet Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords: close
Focuses: Cc:

Description

The most of the sites require a to be read in english, but not all of the sites are located in the US.

So, as spanish, why we do not have an option of just english language? not locate to any region.

thanks

Change History (24)

#1 @tobifjellner
5 years ago

At https://make.wordpress.org/polyglots/teams/
you can find a detailed list of languages defined in the WordPress ecosystem and which of them are currently maintained by a locale team. As you can see, we don't have any locale that is only "es", just like for English, all different Spanish locales are tied to some geographic location. (It's a different story, though, how these locales are presented in wp-admin when you select the site language.)

With regards to translation of WordPress core, plugins and themes, we have chosen the source strings all over core, plugins and themes to be denoted as en_US. Whatever translatable strings are in your code, they'll be handled as en_US, even if they happen are actually in German or French, for instance.

This means:

  • If you have developed a plugin and used some other language in your plugin, then this plugin will most probably never have any translation, but will be used with the strings as they are. And, technically, they cannot be translated to en_US!
  • If you select en_US for your site, pages may load a millissecond quicker, since no translation will be used (for good or bad...)
  • There are quite a few differences between the various English locales (that's why we have several of them). They spell things differently; In some cases they use different words. The message to developers is that if you want to create a smooth experience for all your users, then en_US is the language version to choose for the strings in your code.

(If you start digging, then I'm sure that you'll be able to find plugins that are aimed at a target audience in the UK and where the strings in the code are just using British English. That's OK, too.)

Some 47% of the WordPress sites in the world are using en_US, i.e. the source strings as they are. This doesn't mean that they have to be located in, or aimed at a U.S. target audience, it just means that this language version fit their purpose.

The short version is this: Long time ago WordPress as an ecosystem chose en_US. Now too much is depending on this, so we can't just go and change it. And, really, we don't need to.

By the way: You're free to declare the language of your site as just "en". But even if you do that, in your settings you'd still need to choose en_US, en_GB, en_AU or en_CA as your underlying locale to be used.

#2 follow-up: @colomet
5 years ago

The short version is this: Long time ago WordPress as an ecosystem chose en_US. Now too much is depending on this, so we can't just go and change it. And, really, we don't need to.

I do no ask that. I do ask if is possible to create a new language. To duplicate en_us with en, so not localization would be if that option is selected.

I have a spain base multisite with english language amongh other different languages. So as many other users, we just need the en language in the code. But maybe nothing really happen if we are not base in the US.

#3 @tobifjellner
5 years ago

When you need just any "English", then you'd typically choose en_US. It doesn't matter where you are located.

#4 in reply to: ↑ 2 ; follow-up: @knutsp
5 years ago

Replying to colomet:

I do no ask that. I do ask if is possible to create a new language. To duplicate en_us with en, so not localization would be if that option is selected.

"en" could mean International Englishhttps://en.wikipedia.org/wiki/International_English and be a separate language. 99.9% of strings would probably be copied from "en_US" Or from the other flavours of English that is defined.

What would be the gain if the language code was "en" instead of "en_US"?

There is no localization coupled to "en_US". "US" indicates the flavour of the language, not he localization. It's just an internal identifier. It's only visible when admin is choosing a language, and could even removed from the dropdown.

Anyway, this not a core thing, but for the polyglots team on Make WordPresshttps://make.wordpress.org/polyglots/. Asking for a new language to be created is straight forward and happens regularly when someone who knows an unsupported language comes forward and are willing to do or manage the translation (AFIK).

#5 @knutsp
5 years ago

  • Keywords close added
  • Type changed from defect (bug) to enhancement
  • Version 5.2.3 deleted

#6 @SergeyBiryukov
5 years ago

#50183 was marked as a duplicate.

#7 in reply to: ↑ 4 @getsnoopy
5 years ago

Replying to knutsp:

"en" could mean International Englishhttps://en.wikipedia.org/wiki/International_English and be a separate language. 99.9% of strings would probably be copied from "en_US" Or from the other flavours of English that is defined.

What would be the gain if the language code was "en" instead of "en_US"?

There is no localization coupled to "en_US". "US" indicates the flavour of the language, not he localization. It's just an internal identifier. It's only visible when admin is choosing a language, and could even removed from the dropdown.

Anyway, this not a core thing, but for the polyglots team on Make WordPresshttps://make.wordpress.org/polyglots/. Asking for a new language to be created is straight forward and happens regularly when someone who knows an unsupported language comes forward and are willing to do or manage the translation (AFIK).

Following up from #50183, the idea is to change the default to en, not en-US. This would mean copying the default strings over into an en-US locale (that can be explicitly chosen in the Settings menu), and changing the default strings to international English (Oxford English), ISO 8601 (numeric date format), and RFC 2822 (full-text date format). The en-US locale doesn't make sense in almost every way as the default, as there are many people who just quickly set up a site without much regard (or knowledge) of other locales.

The gain would be that the lang attribute, for example, among other things would not be incorrectly tagged for websites which are not in that locale. There is localization that happens when en-US is used, such as the date formats for example.

#8 follow-up: @apedog
5 years ago

I think @getsnoopy 's proposal makes sense from a standards perspective. Especially the US non-standard and confusing date format. The default should not be _US.

I don't know if Oxford dictionary spelling would make sense from an I18N perspective tho. I like to spell 'behaviour' and 'neighbour' myself. But this is a personal quirk. In as much as English is the lingua franca of the web, I think the American spelling is, de facto, the standard.

#9 in reply to: ↑ 8 @getsnoopy
5 years ago

Replying to apedog:

I don't know if Oxford dictionary spelling would make sense from an I18N perspective tho. I like to spell 'behaviour' and 'neighbour' myself. But this is a personal quirk. In as much as English is the lingua franca of the web, I think the American spelling is, de facto, the standard.

Oxford spelling is the international standard (e.g., behaviour but organize). It's taught in practically every school in non-Anglophone (and even some Anglophone) countries, used by practically every international organization (such as the UN, ISO, IEC, BIPM, NATO, etc.), many academic journals and publications (e.g., Nature), and many people in general. If not Oxford, the next one is British/Commonwealth English: https://en.wikipedia.org/wiki/American_and_British_English_spelling_differences

But since we already have specific locales to cater to the regional ones (such as en-GB, en-CA, en-AU), I suggested Oxford because it's the only one that is considered to be "international".

#10 @garrett-eclipse
5 years ago

I guess another benefit from a polyglot perspective is en-GB, en-CA, en-AU, en-NZ, en-ZA are all more related to oxford english so the base strings if en(international) are more likely to be correct without translation, and during translation are more likely to just be a copy instead of needing to localize. I guess the con from polyglots is then en-US would need to be translated and maintained.

#11 @getsnoopy
5 years ago

@garrett-eclipse Precisely. It would greatly reduce the need to main 5 different translations which are all almost identical, as opposed to maintaining one translation which is quite different from the rest.

@casiepa Resuming from our previous conversation, I think I was merely referring to changing the name of the text "English (US)" in the Settings > General menu to "English (International)" or simply "English", since that's what the default locale would refer to once this change has been made.

This ticket was mentioned in Slack in #polyglots by getsnoopy. View the logs.


4 years ago

This ticket was mentioned in Slack in #core-i18n by getsnoopy. View the logs.


4 years ago

#14 @JeffPaul
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Given that there are differences between the various en_* locales and that if someone wanted a "generic English" they could select from any of those (defaulting to en_US as per Core) I'm going to close this as wontfix.

This ticket was mentioned in Slack in #core by getsnoopy. View the logs.


2 years ago

#16 @getsnoopy
2 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

@JeffPaul I think you misunderstood the premise of the ticket. The premise is not that if someone wants "any generic English", they could choose any one of the variants listed. It is more of a 2-pronged one:

  1. That the default variant (en-US) is an incorrect one for the majority of the world. As mentioned above and in the duplicate linked ticket as well, US English speakers only make up 4–5% of the world and 26–28% of the world's English-speaking population. For the rest, it would either be en-GB or en (being used here not as "generic English", but as "international English" or "Oxford English"). Having what is essentially an incorrect locale be the default for the majority of the world is a usability issue, and this one really is huge (and keeps growing with time).

    I can personally attest to having guided people to fix and/or personally having fixed over 600 (and counting) WordPress installations to change their locale, date format, and time format to other ones. Multiplied over the number of WP developers there are, the number is staggering. Ironically, there are multiple websites on wordpress.org's home page gallery that have this issue (where the website is owned by someone outside the US and/or the content is written in non-US English, but the locale is set to en-US).

    The problem with this is that it's pernicious. Of course, having Afrikaans, for example, be the default language would a clear indication that something is wrong (to most English speakers), so users would try to fix it as soon as possible, overlooking the fact of it being annoying to have to do for every installation (which is bad design per se). Here, however, many don't even realize that what they're getting is the US variant of English because at first glance, everything looks intelligible, so they just click through the installation. (Many don't even see the installation wizard because most hosting websites just install WP for them.) After that, they either never look at the settings, don't know where to find them, or in many cases, can't change the settings even if they wanted to because some web master has set it up and is the only one with the permissions to do so. I've encountered countless times where the owner of the website has told me that they "didn't realize that it was doing this" and "didn't know where to find it".

    As such, the default locale really needs to be changed.
  1. Of course, realizing that en-GB is just another localized variant that might be unsuitable for some others, I suggested creating a new locale, which would be international/Oxford English (as en), that would be the default for all installations. This locale would use all the internationally standard formats, such as RFC 2822 for full-text dates (DD Month YYYY), ISO 8601 for numeric dates (YYYY-MM-DD), and international/Oxford English for the text. This would truly be a good default because of said features (it would apply to the most people and is the most neutral), and anyone who wants to explicitly choose a more specific regional locale can do so if they wish (en-GB for people in the UK, en-US for people in the US, etc.).

    Because of said neutrality, another added benefit of creating such a locale (as mentioned by another commenter above) is that other English locales' translation files would not need to redefine the strings for most of the keys/messages because international English applies to most of the locales. For example, having the date format be DD Month YYYY applies to every English locale other than en-US; having the text Customize would apply to en-US, en-CA, and even en-GB and en-IN (unless those locales make the administrative decision to prefer -ise endings over -ize endings); and so on.

    So, there are numerous benefits to this. And this idea was even supported by many developers in this thread and the other ticket marked as duplicate.

While no. 2 is not essential (doing just no. 1 would solve the fundamental issue of bad defaults), doing it would be much more beneficial to WP as a whole. I understand that changing the default locale is not easy (though, frankly, it was a poor decision to default to US English to begin with), but at this point given WP's global reach, it's absolutely necessary. I'm even ready to help with this effort if others are unmotivated to do it. I was hoping this could've been synchronized with the 6.x major release (since it would be a breaking change), but that unfortunately didn't happen.

#17 @JeffPaul
2 years ago

A lot there to parse, but one thing that stood out is perhaps during the initial install there could be a clearer note that you are selecting English (US) perhaps, having other options similarly clearly described, and then maybe a different default if there's a more widely utilized locale?

#18 @getsnoopy
2 years ago

Indeed, with priority given to the latter option.

#19 @swissspidy
12 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Changing the default locale to International English and introducing English (US) as a new locale to translate to, is such a big lift that would affect the fundamentals of the i18n system in WordPress, probably in a backward incompatible way.

Such a proposal is best published in a more visible way, for example with a blog post.

To share my personal view, I would like to repeat what was said before:

The short version is this: Long time ago WordPress as an ecosystem chose en_US. Now too much is depending on this, so we can't just go and change it.

Now, an alternative approach is to suggest International English as a new locale, which is best done via a proposal on make/polyglots. With this proposal, one could still choose the locale that works best for them during installation or on the settings page.

This would be a more viable route as it doesn't require any technical changes.

Either way, the best course of action is not through a ticket like this, but a more visible proposal via a blog post.

#20 @getsnoopy
12 months ago

@swissspidy I'm not sure what you mean by a blog post; could you expand on this?

About it being "too much work", I'm not sure I agree. The default locale seems to not have a locale code in many places, so it would only require changing the default strings that are shipped with the code. In the places where it is hard-coded/assumed to be en_US, it would need to be changed to en.

The plan would be to create a new en_US locale where we would copy the current default strings, so any plugin or other code that depends on the en_US locale would work seamlessly, assuming the en_US locale is installed at that point. If they depend on the "default locale", that would translate to the new default locale seamlessly as well.

For backwards-incompatible changes, we can have a migration plan in place so that people who are currently using the default locale are migrated to explicitly use the en_US locale, and we can release it in a major version bump (which is meant for backwards-incompatible changes).

Regardless, I find the argument of "we made a decision a long time ago, so we have to keep it that way" entirely unsatisfactory and unacceptable, as this is seriously a huge issue. The more time that passes, the bigger and more important this issue becomes. Everyday, I notice this being an issue on more and more websites. It simply can't be ignored, and a resolution such as "the users/admins can pick another locale" or "we can create another locale" is clearly not a solution (if it was, this wouldn't be a ticket in the first place).

#21 follow-up: @tobifjellner
12 months ago

@getsnoopy
"we made a decision a long time ago..." should here rather be read as:
Originally, WordPress was developed as an application that was only using en_US. When localization was added, en_US was reserved as the source locale.
If we would change that value now, then there will be a lot of strange compatibility problems with many themes and plugins, especially with custom-developed code.

And since you main argument is that you want to be able to just declare "en" as your locale, then this would be easy accomplished by just adding International English as a new locale. We won't even need to add any translations to this locale, since WordPress by default uses the source string if there's no translation available.

My biggest concern about that route is rather that some developers will see this as an invitation to more prominently than today display other languages in their code, and then just translate their English|French|Spanish strings to "en", leaving en_US with the original strings, and making translations to other languages trickier, since you'll then not have our "common denominator" English as a source string.

#22 @tobifjellner
12 months ago

@getsnoopy

blog post; could you expand on this?
Your proposal is about introducing a big change to how WordPress handles internationalization.

If you really want to push your proposal forward, then you should invite more people to the discussion by making a post in https://make.wordpress.org/core/ in cooperation with the relevant component maintainers, and then crosspost a link to this post in https://make.wordpress.org/polyglots/ to try and build more awareness and support for your idea.

However, my vote in this case would rather be to just add "en" as a new locale.

#23 in reply to: ↑ 21 @getsnoopy
12 months ago

@tobifjellner

And since you main argument is that you want to be able to just declare "en" as your locale, then this would be easy accomplished by just adding International English as a new locale. We won't even need to add any translations to this locale, since WordPress by default uses the source string if there's no translation available.

That is not my main argument. My main argument is to change the default locale of WordPress to one that actually aligns with the default for the world, which is either en_GB or en (international English, which would have to be created).

I was only suggesting creating a new locale so as to make it a good compromise for it being a good default for the most number of people. In the absence of that, I would be fine with making en_GB the default, since that also closely aligns with that the reality is.

Originally, WordPress was developed as an application that was only using en_US. When localization was added, en_US was reserved as the source locale.
If we would change that value now, then there will be a lot of strange compatibility problems with many themes and plugins, especially with custom-developed code.

That is understandable, but that's why I was saying that we do this only at the juncture of the next major version release. That would give enough time to communicate to all plugin developers to update their default strings to use en or en_GB in mind. If they still don't by that time, it's "fine" in the sense that most of the English-word strings would remain the same between en_US and any of the other English locales, en_GB and en included; it's mostly only the formatting of dates and times that would be different, so it's not a "big deal".

(As an example—though it might not be a representative sample—this whole comment has no words which would be different among any of the variants of English, let alone between en_US and en or en_GB.)

And even in those cases of incompatibility, it would be no different to what you seem to be suggesting is already happening in the plugin ecosystem, where people may use Swahili, for example, in their default plugin strings without providing any translations despite the default strings being assumed to be in en_US. In this case, the laggard plugin developers would have plugins which still use strings that would be using en_US content (or whatever their strings happen to be in), though the default is assumed to be in en or en_GB.

It's essentially an "opt-in" or "do it at your own convenience" model that is not disruptive because the default is merely going from one kind of English to another (and not from English to an entirely different language).

My biggest concern about that route is rather that some developers will see this as an invitation to more prominently than today display other languages in their code, and then just translate their English|French|Spanish strings to "en", leaving en_US with the original strings, and making translations to other languages trickier, since you'll then not have our "common denominator" English as a source string.

I'm not sure I follow.

#24 @tobifjellner
12 months ago

at the juncture of the next major version

WordPress has only major and minor releases, where a new major release gets published around three times a year.
Huge efforts are put into minimizing the risk of problems with backwards compatibility. Nowadays, the default setting in new installations is to automatically install not only to new "minor" releases (in most other environments labelled "maintenance releases"), but also to new "major" releases, like 6.5, 6.6, etc.

My biggest concern about that route...

I'm not sure I follow.

It is technically possible to publish a plugin where the strings in the plugin aren't in English. Some examples of where this happens may be for a plugin that enables the Persian Calendar (and thus only relevant to sites that are configured to use Persian); or integration with payment systems or freight solutions that operate only in one single market.

We strive to give a clear message to the developers that they shouldn't expect the community to be able to translate (or verify translations) if the source strings are in some other language than English.

But the moment we make it possible to "translate to International English", these developers may feel much less pressure to publish their plugins in English.

---
My view is, though, that still, for technical reasons, if we want to create a lot of unnecessary work and risks, the untranslated version of WordPress will need to remain en_US.

Note: See TracTickets for help on using tickets.