Separate language and locale. Proper languages for content translation.

How do you think this relates to separation of content vs. interface language in Drupal 7, that is already supported? Sounds like your case can be made so that your site would have different languages set up, and some of them maybe would not be used for content but interface only. I'm trying to figure out how this relates or is different to that.

If I understand you correctly, you want to remove the territory/country part from language codes pertaining to content language?

In a concrete {node} data example:

nid    title                             language
123    Foo in Portuguese, Portugal       pt-pt
124    Foo in Portuguese, Brazil         pt-br
125    Bar in Chinese, Simplified        zh-hans
126    Bar in Chinese, Traditional       zh-hant
127    Baz in English                    en
128    Baz in British English            en-gb

The above would no longer be possible. Possible would be only:

nid    title                             language
123    Foo in Portuguese                 pt
125    Bar in Chinese                    zh
127    Baz in English                    en

Not sure I understand the problem, or what the benefit is of doing that. Sounds like a step backwards to me.

Also note that there are only a few language codes in iso.inc that actually contain an extension.

Clarifying the issue summary would be helpful. (it's editable now)

sorry, cross-post.

Well, in terms of locale, all the UI translations and possibly some of the configuration translation should support all locales, right? British English will have a different translation for the UI compared to US English, right? They might need different labels for form fields just as much, no? It does not sound to be only about number formats or date formats. We do have separate translations for British and variants of Portuguese as @Sun pointed out, so those would map to locales too, right?

It doesn't make too much sense when someone posts an article, selecting between 'British English' and 'American English'.

Well, that's where we disagree. It does make sense for me. And this is only possible if you actually install both of these languages in the first place. Otherwise, you have one or the other either way only.

So basically what we need is a 'content languages' configuration separated from 'Site languages' (locales actually but we can call it languages for usability sake) which anyway is already a feature request. This would be a feature on top of that that would allow independent lists and names for 'content languages' and 'interface languages'.

I'm sorry, but I still don't get the point of further splitting language configuration. We already have content language separated from interface language (and developers are killing us for that already...) Drupal core configures both language types at the same time when configuring through Locale module's UI. Entity Translation module in contrib changes that UI to allow to configure them separately. (This was deemed to be too advanced for Drupal 7 core.)

I really think we need a better issue summary here, because it's very hard to understand and follow what the actual point of the proposed change is. I.e., what is the actual problem? Any steps to reproduce? What's exactly proposed to be changed? And how does that improve the situation?

@Jose:

If I'm not mistaken you are suggesting that different locales might share the same content when they (more or less) share the same language. I'd argue that since the two languages albeit very similar might actually differ in some forms (I'm not taking into consideration the scenario in which different content has to be provided for different locales), this is a degnerated case of fall back: if I understand italian perfectly and I understand (british, american, whatever) english reasonably well, I might want to read content in english if not available in italian. With the same scenario in mind, an editor not wishing to provide a "british english" version of an "american english" content (for obvious reasons) might want both locales to access it: an american user would see it "natively", while an english user would see it because some smart fallback rule decided that was the right content to display.

So, what about addressing this use-case with some advanced fallback rule?

I think this suggestion from sun in #1216094: We call too many things 'language', clean that up solves the problem I think Jose is raising:

$language->language = 'en'; // Pure convenience, not used anywhere.
$language->locale = 'en-us'; // Default language/locale.
$language->optionalLocales = array('en-gb'); // Alternative locales.

The optional locales allow us to bind one language to multiple locales and thus "to show the interface and content in English (en), but everything that can be localized in the appropriate locale (en-us or en-gb)."

Tagging for base language system.

Added link to language tag article

I'm actually working on a site that will have both British and United States English, but I'll admit it's more about having two different Marketing teams (who want different copy) than language translation. My plan is to use "en" for US and "en-GB" for UK.

If we support "en-GB" as a language which installs in Drupal core, then shouldn't the default "en" language actually be "en-US"? I've been looking at things as though each Drupal "language" is actually a language + locale combination. If I understand the RFC correctly, this is a reasonable way to organize.

a prefix MAY be replaced by one of its own prefixes. For example, the prefix "en-US" could be replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". If one of those prefixes were needed, a new Prefix SHOULD be registered.

So "en", if available, could be a fall-back if a requested combination isn't available.

I'll admit I don't see much value in adding another dimension to the data. Folks can organize "languages" as they see it with the current system (as in my example above). But we should still change "en" to "en-US". ;)

@colan: I'm not sure that it would be correct to say that the Drupal interface text is using US English (or any other particular English for that matter).

Going to close as outdated since this has been in PNMI for 11 years.

If you feel this is still an issue please reopen. After searching for any duplicates