Problem/motivation
The "multiple" special language was added to core earlier in Drupal 8 with the thinking of completeness (see #965300: Change LANGUAGE_NONE to LANGUAGE_NOT_SPECIFIED; add LANGUAGE_NOT_APPLICABLE and LANGUAGE_MULTIPLE), so you can express if something is in a certain language, no language, an unknown language or in multiple languages. The later is however confused by people who we tested with unrelated things. For example, a possible capability to have entities with fields that have different language codes or even that this language code would designate a translatable/translated entity and then individual translations would use specific languages. See http://groups.drupal.org/node/271918 for more details.
@webchick was also confused with the "multiple" language when she committed the original patch and we agreed user testing would figure out if people get it or not. They don't :)
Proposal
This special language was added only for completeness and has no special significance in the language system. It is very easy to remove and is equally easy for contrib to add it back if need be. The Drupal 8 language system allows contribs to add any number of special languages like this which would then behave like other human-created languages.
In short removing this from core does not actually remove functionality that was present in Drupal 7 (core or contrib) or that is not easily possible to add back in Drupal 8 contrib.
Related issues
The usability testing also showed that showing the special languages at all in this table is confusing. The removal of them is discussed in #1869328: Restore simplicity of language list.
Comment | File | Size | Author |
---|---|---|---|
#6 | remove-multiple-w-tests.patch | 3.19 KB | Gábor Hojtsy |
OneLess.png | 43.5 KB | Gábor Hojtsy | |
remove-multiple.patch | 1.87 KB | Gábor Hojtsy | |
Comments
Comment #1
miro_dietikerWe all know, multilingual systems are very complex.
I don't feel like "mul" should be a user added language. Instead it has a technical meaning and this concept is what we introduce or not.
If you want to simplify the UI, there's always the option to hide things that are actually there. Why not hide the three common records in the UI in regular mode and add a checkbox to show advanced configuration?
Comment #1.0
miro_dietikerAdd reference to original issue where this was added.
Comment #2
Gábor Hojtsy@miro_dietiker: well, our user testing showed people did not understand what "multiple" was for. In fact they hugely misunderstood it. Contribs can add "mul" as well as any other languages as needed, if/once languages become config entities, all it would take is to ship a .yml file with a couple lines of config with your module.
As for removing the special languages from the admin UI, see #1869328: Restore simplicity of language list.
As for establishing an entities to sets of languages related to limit what shows up on the UI: #1314250: Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc) (where I did not have any success to (a) make people enthusiastic about the idea (b) entice anybody to work on it - you are more than welcome :).
Comment #3
Bojhan CreditAttribution: Bojhan commentedThis sounds like a solid choice, if we do not feel core needs this and it causes confusion than its much better if contrib adds it as it sees fit.
Comment #4
sunThis looks RTBC to me. And if this is really not covered by any tests, then it's even better to remove it. ;)
So let's do this, if the bot comes back green. Otherwise, we'll have to remove corresponding test coverage, too, I guess. (or move the definition into language_test.module - as an actual proof that contrib is able to re-introduce it?)
Comment #6
Gábor HojtsySo it did have test coverage :) Also the same test coverage already tests adding other locked languages, so we are covered there. This passes tests for me.
Comment #7
Gábor HojtsyShould be back to RTBC as per above.
Comment #8
Dries CreditAttribution: Dries commentedI agree that this is a UX improvement. Committed to 8.x. Thanks!
Comment #9
Gábor HojtsySuperb, thanks!
Comment #11
YesCT CreditAttribution: YesCT commentedrelated: #1471444: Review use of LANGUAGE_NOT_SPECIFIED vs. LANGUAGE_NOT_APPLICABLE vs. LANGUAGE_MULTIPLE
Comment #12
YesCT CreditAttribution: YesCT commentedtagging
Comment #12.0
YesCT CreditAttribution: YesCT commentedAdd special language removal issue link.