WordPress.org

Make WordPress Core

Opened 12 months ago

Last modified 4 months ago

#48152 new enhancement

en as default language instead of en_us

Reported by: colomet Owned by:
Milestone: Awaiting Review 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 (11)

#1 @tobifjellner
12 months 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
12 months 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
12 months 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
12 months 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
12 months ago

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

#6 @SergeyBiryukov
4 months ago

#50183 was marked as a duplicate.

#7 in reply to: ↑ 4 @getsnoopy
4 months 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
4 months 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
4 months 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
4 months 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
4 months 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.

Note: See TracTickets for help on using tickets.