en as default language instead of en_us

[colomet]

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

[tobifjellner]

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.

[colomet]

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.

[tobifjellner]

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

[knutsp]

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 English​https://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 WordPress​https://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).

[SergeyBiryukov]

#50183 was marked as a duplicate.

[getsnoopy]

Replying to knutsp:

"en" could mean International English​https://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 WordPress​https://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.

[apedog]

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.

[getsnoopy]

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".

[garrett-eclipse]

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.

[getsnoopy]

@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.

[JeffPaul]

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.

[getsnoopy]

@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.

2. 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.

[JeffPaul]

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?

[getsnoopy]

Indeed, with priority given to the latter option.