In Drupal, we aim to provide a generic language list, but in effect, people use languages for all kinds of things, and which languages from the general list are applicable to which operation are not possible to define.

Some examples:

1. Site wants to track English (US) and English (British) content separately. They don't want to have user interface translation for them (even if they have other languages, they want to have UI translations for). This means their list of languages for UI and content are largely overlapping but not equal.

2. Web application wants to offer its interface in various languages (think google search), but help pages and documentation on the web app will be available in a limited set of languages, and no intention to offer more. Language switchers in the documentation area (for content) would show less languages compared to the language switcher on the web app. Content language assignment should not show irrelevant languages.

3. A web site wants to expand into more languages, and while the new language pages are built out, they obviously don't want their language switcher links to show the soon to be added languages, so users are not confused that the content is not there yet, since its unpublished or permissions to be only seen by QA stuff at least.

To support these use cases, we'd basically need to refactor the "enabled" bit on languages to be a set of feature specific bits. Whether this language is enabled for UI translation (also very useful for #1266318: Make English a first class language where we are attempting a stop-gap solution for now), whether this language is exposed in language switchers, content language assignment, etc.

Related Issues

Comments

Bojhan’s picture

What is the 80% usecase? I dont really get the question.

Jose Reyero’s picture

I think:

- Get rid of 'enabled' property
- Provide a way to configure different language lists (interface, content, field_xx ....)

Then, a language will be 'enabled' if it belongs to any of the existing language lists. And we just need to make that difference on the languages configuration pages so you know when you are editing a language that is currently being used for anything.

Gábor Hojtsy’s picture

@Bojhan: the 80% use case is probably:

Language Enabled for UI translation Enabled for content translation
Danish Yes Yes
English (UK) Yes Yes
English (US) No Yes
German Yes Yes

For site 1 above (tracking different versions of English content):

Language Enabled for UI translation Enabled for content translation
English (UK) No Yes
English (US) No Yes

For site 2 above (content in English, UI in various languages):

Language Enabled for UI translation Enabled for content translation
Danish Yes No
English (UK) No No
English (US) No Yes
German Yes No

For site 3 above (German content being phased in, note even more type of language list):

Language Enabled for UI translation Enabled for content translation Shown in language switcher
Danish Yes Yes Yes
English (UK) Yes Yes Yes
English (US) No Yes Yes
German Yes Yes No

Now we only have one set of checkboxes so we cannot do this separation. In #1266318: Make English a first class language we arrived that we do need to expose a special checkbox to cover the "Enabled for UI translation" case separately for English. It would be ideal to generalize this eventually. Did this help?

plach’s picture

- Get rid of 'enabled' property
- Provide a way to configure different language lists (interface, content, field_xx ....)

I agree with Jose that this could be the right way to address the issue, but I have no idea of how the UI could look like. Marking #533924: Allow different language types to be enabled separately as duplicate of this one since the discussion here is more active.

Gábor Hojtsy’s picture

Yes, technically it does not sound too advanced, the UI is in question, that is why I looped in Bojhan right away :) Sorry I did not find/remember the other issue...

Gábor Hojtsy’s picture

Also count in that (IMHO) we want to provide a way for people to disable the "Language neutral" option for things. It can be pretty useful and pretty distracting at the same time. So we need a place to put enabled checkboxes for types of language use vs. the Language neutral language as well. @Bojhan: any opinions?

Gábor Hojtsy’s picture

Issue tags: +language-base

Tagging for base language system.

Gábor Hojtsy’s picture

There are many people at #198355: how to disable 'language neutral' option for creating new pages? who want the functionality to disable language neutral for nodes.

Gábor Hojtsy’s picture

Title: Refactor "enabled" bit on languages to be a set of bits » Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc)

Retitle for the user problem, regardless of how we solve it internally.

andypost’s picture

This related #1539072: Support for disabled languages broken, drop it
If we drop support for disabled languages so this issue makes no sense

I think we should have 2 options/flags:
- enabled (should be dropped according #1539072: Support for disabled languages broken, drop it)
- published (language could be visible to visitors)

Gábor Hojtsy’s picture

I think this definitely makes sense as a usability tweak, some people don't want to see "Language neutral" in their node assignments (for certain node types) for example, because it does not make sense in their setup. It might end up as a contrib feature though.

andypost’s picture

So let's continue with this issue as #258785: Provide more flexible settings for initial language on content types

For each entity we need to implement a special settings a-la node does

Gábor Hojtsy’s picture

Issue tags: +Needs usability review

Tagging for usability, since this came up when reviewing #258785: Provide more flexible settings for initial language on content types.

Gábor Hojtsy’s picture

Issue tags: +Usability
Gábor Hojtsy’s picture

andypost’s picture

We could proceed with following
1) use enabled bits for each of language types
2) use settings per entity type like nodes does after commited #258785: Provide more flexible settings for initial language on content types

Gábor Hojtsy’s picture

@andypost, we did #258785: Provide more flexible settings for initial language on content types with generalization in mind for more entity types, such as taxonomy terms too. Now we need to generalize the setting, but questions like how do we store the value regardless of entity/bundle were gaps that made us think about nodes first, because that in itself was hard. The "which language is applicable" can in fact deal with the same problem. If you have feeds feed entities, those would likely be saved as "language unspecified" if the feed is multilingual and you don't have a tool that identifies language on the fly for text. So other entity types need bundle level support as well possibly. Which means ideally we'd implement a system that can store these settings generally and apply them generally let along provide a sane UI.

andypost’s picture

@Gábor Hojtsy: You talk about entity languages but whats about UI?
I'd like talk from CMI perspective about storage for this settings.

We have language_types_info() that cares about language definition and we could extend this by providing some kind of #access key.

OTOH #258785 stores data in variable, in CMI conversion this part is curious because it should be a kind of state inside a node-type definition but lives orphaned
variable_get('node_type_language_default_' . $type->type, 'site_default')

Also we could implement a db-table with fixed fields for your example in #3

Gábor Hojtsy’s picture

Yes, the CMI conversion should take care of figuring out where do node related settings not necessarily directly provided by node module go (such as the translation setting). We did move the code on language assignment to node module but not the setting to the content type table, since CMI conversion is going on anyway.

Bojhan’s picture

Issue tags: -Needs usability review

No idea what to review.

Gábor Hojtsy’s picture

Note that this might be able to integrate into the UI framework set up in #1810386: Create workflow to setup multilingual for entity types, bundles and fields, where we have one screen to configure per entity type/bundle configuration for languages. The set of allowed languages for each can be part of the config, although admittedly under some kind of advanced settings container I think.

YesCT’s picture

any new thoughts on approach here, based on what's been done so far in other issues?

Hanno’s picture

Bump from #1993928: Language of parts: Introduce a language toolbar button
Another usecase: accessibility demands language tagging in content (paragraph and sentence level), we should be able to provide a short list of languages (for example for a university: Dutch, English, French, German, Latin).
CKeditor will in the next release provide a language button for this. For this we need to integrate a configurable list of languages.

Mark_L6n’s picture

Re: #23, WCAG 2.0 'Language of Parts' seems to present a slightly different issue than discussed here.

As I understand it, the issue here is to determine (in advance) which set of languages is enabled for which Drupal parts (admin, nodes, menus, taxonomy, etc. ?).

The issue for WCAG 2.0 'Language of Parts' seems to be mainly for a content author (at time of writing) to use and mark any language in a piece of content. Citing their example:
In the sentence, "He maintained that the DDR (German Democratic Republic) was just a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German.
This phrase should be able to be marked as German whether or not Drupal nodes are enabled for German, and tags for all languages should be available for authors. (Although a short list of languages commonly used on the site could help speed this up.)

Gábor Hojtsy’s picture

Well, Drupal already lets you configure a set of languages, so you'll not get all languages on earth when you enter content. This issue is about filtering that further down as appropriate. It would be all site configuration level, not enforced by Drupal installation in general, so I don't consider that related to language of parts in general.

mgifford’s picture

Issue tags: +language of parts

Although the content author definitely needs to have access to selecting languages for the Language of Parts criterion and it's great that CKEditor is going to help facilitate this. However, the output from #3 should be tagged properly such that they include the lang="zh-Hans" or what have you that is related to the chosen language for each UI, nodes, files, etc..

The W3C defines it reasonably clearly, but are based on a simpler example.

Pancho’s picture

Component: locale.module » language system

Just some considerations regarding the Language of Parts functionality:

I agree that for this functionality we need all languages be available to every user, no matter what languages exist on the system and no matter what an admin decided to enable or disable.
This should basically be independent even from the Language module, though not even our current standard languages list would be complete enough. We'd need to support all languages that have a language code. Latin was a good example.

So we'd need the standard languages list to be vastly extended. For installation we'd probably want to filter just the languages that have an interface translation. But at a later point, it should be possible to choose from all languages with language codes, be it Latin or Ancient Greek or Aramaeic. Be it just so the can be added to a custom shortlist of the most important citation languages.
Actually this aspect applies just as well to the translation of whole entities. It should be slightly easier and fool-proof to add any language on admin/config/regional/language.

We might also want to revisit the decision to have a Language module separate from the core library in core/lib/Drupal/Core/Language. Not much would be left in the module, if we move large parts of the language administration to the core library.
However, IMHO we should do that anyway. At least in the UI, it currently seems impossible to define a default language other than English without having Language module enabled. And the negotiation part is anyway only necessary with Content translation and/or Interface translation being enabled, so shouldn't be exposed by Language module either, if I'm getting this right.
If you could point me to an existing discussion, that would be awesome. Otherwise I might open a new issue for that.

Hanno’s picture

If we want to have a language list with all languags, we could use the list available in the Intl component of Symfony (http://symfony.com/doc/current/components/intl.html). It uses the language list of ICU (used in Android, iOS etc). These are the languages you will get:
http://source.icu-project.org/repos/icu/icu/tags/release-50-1-2/source/d...
That include almost any language (including Aramaic, Ancient Greek and Latin).

Gábor Hojtsy’s picture

How is this related to this issue?

Hanno’s picture

Well @Pancho considered to include all languages in Drupal to facilitate content tagging. But extending the language list and having a generic language picker should be another issue as this issue is about filtering the language list for specific uses.
It will mean that adding a language at admin/config/regional/language/add will give that complete list instead of the drop down we have now.

EDIT: added as an issue #2041115: Extend list of languages with all languages of ICU

Pancho’s picture

Well, it is actually more closely related because the "language of parts" shortlist would be just another core use of the filter/configure/order functionality this issue here is about. With some special requirements, though, so I'm giving details.

Gábor Hojtsy’s picture

That direction sounds possible in Drupal 9, if you'd like to target that, feel free to bump the version.

YesCT’s picture

Issue summary: View changes

added related issues list.

Gábor Hojtsy’s picture

This came up at Drupalaton 2014. Solving the whole issue is way too big which is why this never went anywhere. The block is an easy sub-problem though, and got @Janoka going on that at #2318429: Language condition / block language visibility includes useless options. Probably the rest is Drupal 9 or for later point releases.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.