Updated: Comment #21

Original report by @Gábor Hojtsy

Problem/motivation

For any configuration that is shipped with Drupal core, they will be shipped in English. It is possible that a foreign language site will not use English at all (it is not added in the installer if installing in a foreign language). However, when editing configuration (such as a vocabulary or view), the language selector on the object will only included configured languages. Since eg. shipped views people will not likely want to edit with all text values manually to be in their own language, we need to support keeping English as an option on the language selector. If we don't, then editing a shipped vocabulary for example would flip it to a different language and translations would not be well aligned anymore.

We want to support updating core with the views config changes, field settings updates, etc. We also want to support the translation teams doing their work after your Drupal site is installed, so we want to keep the Views, content types, etc. in their original form as shipped with Drupal core and translate it with the locale override system. So we want users to be able to make edits on those things, but keep them as English even though English does not show up on the site for things that are not already English.

Proposal

If the entity being edited is originally in English, make it possible to keep it (Built-in English) even if there is no English configured. For config that was created in non-English, we should not allow to be moved to English.

Remaining tasks

  • (done) manual testing #21 and #45
  • (done) code review

User interface changes

Taxonomy before/after:

before:

no_patch-vocab_es.png

after:

default config (english)
patch-vocab_es.png

new config (created on a site without english)
patch-es_vocab.png

API changes

No.

CommentFileSizeAuthor
#47 defaultlanguageonokpage.png146.07 KBYesCT
#45 no_patch-vocab_es.png128.76 KBYesCT
#45 patch-vocab_es.png133.64 KBYesCT
#45 patch-es_vocab.png131.98 KBYesCT
#42 drupal-1936216-Fixed-language-selectors-42.patch3.84 KBSchnitzel
#39 drupal-1936216-Fixed-language-selectors-39.patch3.49 KBSchnitzel
#36 drupal-1936216-Fixed-language-selectors-35-36-interdiff.txt669 bytesgrisendo
#36 drupal-1936216-Fixed-language-selectors-36.patch2.93 KBgrisendo
#35 drupal-1936216-Fixed-language-selectors-35.interdiff.txt1.76 KBkfritsche
#35 drupal-1936216-Fixed-language-selectors-35.patch3.02 KBkfritsche
#31 drupal-1936216-Fixed-language-selectors-31.patch3.36 KBSchnitzel
#31 interdiff-25-31.txt1.46 KBSchnitzel
#24 drupal-1936216-Fixed-language-selectors-24.patch3.55 KBstkrzysiak
#24 interdiff-1936216-22-24.txt807 bytesstkrzysiak
#23 interdiff-1936216-11-22.txt1.29 KBstkrzysiak
#22 interdiff-1936216-11-22.txt563 bytesstkrzysiak
#22 drupal-1936216-Fixed-language-selectors-22.patch3.54 KBstkrzysiak
#21 vocab_language_after.png16.95 KBstkrzysiak
#21 taxonomy_language_before.png16.33 KBstkrzysiak
#21 menu_language_after.png19.32 KBstkrzysiak
#21 menu_language_before.png15.92 KBstkrzysiak
#16 drupal-d8mi-menu-language-has-English.png48.49 KBKristen Pol
#16 drupal-d8mi-menu-links-language-does-not-have-English.png427.22 KBKristen Pol
#16 drupal-d8mi-menu-link-language.png59.41 KBKristen Pol
#17 drupal-d8mi-menu-links-language-does-not-have-English.png53.83 KBKristen Pol
#11 drupal-1936216-Fixed-language-selectors-11.patch3.16 KBwebflo
#10 drupal-1936216-Fixed-language-selectors-10.patch3.2 KBkfritsche
#10 interdiff-8-10.txt787 byteskfritsche
#8 drupal-1936216-Fixed-language-selectors-8-test-only.patch2.16 KBkfritsche
#8 drupal-1936216-Fixed-language-selectors-8.patch3.2 KBkfritsche
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

larowlan’s picture

Fwiw this was something we grappled with in #1921188: Implement Tour UI module, the patch there has some logic to check if the $entity->isNew() and then wires the default value to language(LANGUAGE_TYPE_CONTENT)->langcode

larowlan’s picture

Removed a comment (wrong issue)

YesCT’s picture

ran into this while thinking about #1945226: Add language selector on menus

Gábor Hojtsy’s picture

Priority: Normal » Major

This is a sizable problem for all the shipped configuration that you cannot modify them in any way and keep them in English.

kfritsche’s picture

Priority: Major » Normal
Issue tags: +sprint
kfritsche’s picture

Assigned: Unassigned » kfritsche
Priority: Normal » Major

Working on this.

kfritsche’s picture

Assigned: kfritsche » Unassigned
Status: Active » Needs review
FileSize
3.2 KB
2.16 KB

First test + patch for it.

It always adds the default value of the language selector to the list of possible languages, except the language doesn't exists at all. With this English will be added even when English is deleted.

Patch as separate test-only as proof that the patch fixes it.

Status: Needs review » Needs work

The last submitted patch, drupal-1936216-Fixed-language-selectors-8.patch, failed testing.

kfritsche’s picture

Status: Needs work » Needs review
FileSize
787 bytes
3.2 KB

Fixed the notices which came up in the test.

webflo’s picture

Loosk good to me. I removed the @todo. Displaying the translated language names is not part of this issue. It should be a follow-up.

Status: Needs review » Needs work
Issue tags: -D8MI, -sprint, -language-config

The last submitted patch, drupal-1936216-Fixed-language-selectors-11.patch, failed testing.

webflo’s picture

Status: Needs work » Needs review
Issue tags: +D8MI, +sprint, +language-config
Kristen Pol’s picture

What's the best way to test this?

Gábor Hojtsy’s picture

@Kristen: Install in a foreign language or add a foreign language and then remove English. Then go to edit any of the config that was shipped with Drupal core (that you did not create). A menu, a vocabulary, etc. If it does have an English option, the patch works. Otherwise it does not. :) The idea is those things are English even if you don't want English to be on your site otherwise. So we need to let you keep them English and not accidentally change the language because English is not an option anymore.

Kristen Pol’s picture

I tested the patch:

1) I couldn't figure out to delete English when I installed the site in English. I changed the order of the languages so English was second. I changed the selected language to not be English. How can you change the default language? I know it's not recommended but I couldn't delete English otherwise, right?

2) I did an install with a different language and went to the main menu and found the following:

a) English was indeed the selected language for the menu:

drupal-d8mi-menu-language-has-English.png

b) The options for menu links did not include English (I guess that makes sense):

drupal-d8mi-menu-links-language-does-not-have-English.png

c) If I chose to show the language drop-down on the menu links, it did not show English for the Home menu link (not sure if this is correct or not):

drupal-d8mi-menu-link-language.png

Kristen Pol’s picture

Oops... meant to crop the second image... attaching here so I can update the previous comment.

kfritsche’s picture

Sounds good and it seems to work. :)

To the first point you can change the default language under region settings (admin/config/regional/settings). First point there is default language. If you change it to something other than English then you can delete English under language (admin/config/regional/language).

Kristen Pol’s picture

Thanks @kfritsche! Then I found a bug because there is a link to change your default settings on the negotiation page and it goes back to the admin/config/regional/language page which led me to believe that I could do it there (like in D7). Not sure that one has been reported or not... I'll try to look tonight.

Gábor Hojtsy’s picture

stkrzysiak’s picture

I reviewed this as well, and confirm the results @Kristen Pol saw. I also looked at the taxonomy section as well, just to make sure this was happening elsewhere, not just menu admin pages. Uploading a few screens I grabbed so I can add them to the summary.

Taxonomy before/after:

taxonomy_language_before.png

vocab_language_after.png

Menu before/after:

menu_language_before.png

menu_language_after.png

stkrzysiak’s picture

Issue summary: View changes

Added before/after screens and filled out rest of issue summary template.

stkrzysiak’s picture

I created a separate issue for the translation of the drop down menu. I decided it would be a good idea to put the @todo back, with a link to the issue. I also move it to the function docs, since I feel the translation needs to happen for the value we prepend('English'), and whatever else is already there: ('Afrikaans' or 'Polish').

I also reworded one of the comments that I struggled with initially.

stkrzysiak’s picture

FileSize
1.29 KB

Bad interdiff, sorry about that!

stkrzysiak’s picture

It was pointed out to me by the wise and patient @YesCt that my comments needed some fixing. See rerolled patch and interdiff. Sorry, trying to get a hang of this whole process!

rteijeiro’s picture

I'm going to review this one :)

Sutharsan’s picture

While evaluating this patch I've been playing around with the config translation for a while now. I think to understand that we need an English configuration in the background, even when English is deleted as a site language. The disabled view is one example, but any configuration default that comes with a module in code is in English. But it is not logical to a (site builder) user to present English in the configuration interface. In the case that the site has only one non-English language, as a site builder expect a configuration form to show the configuration in my site language. i.e. the default configuration translated where applicable. As long as a configuration is not save previously, the configuration is my site language can be the translated version of the English. If we can achieve this, there is no need to present the English configuration.

Actually, when I change the language selector in a config form I expect the content of the form to change to this language. Or am I going wild now?

Gábor Hojtsy’s picture

@Sutharsan: I'm not sure that is feasible at this point anymore. All the default configs like content types, fields, views, user roles, input formats, etc. are in English. You are advocating all these would be overwritten with translated versions in their original versions in translation if I get it right. The truth is you may remove English later on from your system, you may want to update core and get updates to your input format descriptions, views, etc. If we fork your local copy with overwriting as a translation, it would not be connected to translations anymore.

Sutharsan’s picture

when I change the language selector in a config form I expect the content of the form to change to this language

Ok, I just proved I don't understand config translation yet :(

Gábor Hojtsy’s picture

Yeah, so the language of the config entity is what language that entity is in. Eg. in Views, you can create a Dutch view and a French view. They would *know* that they were Dutch and French originally respectively. Then when the translations need to be done, you can translate from those languages to others. If your site only has Dutch and French and no English, then these two will have their original language and you use the translation form to translate (not change the language of the original thing). As for shipped Views, thsoe would be in English, so you would be able to go and translate them to *both* Dutch and French as you want (and the original View would be kept in English as shipped).

Sutharsan’s picture

Ok, let me summarize what I've learned:

  • A translatable config item (e.g. menu, view) can have one language. If you need for example a Dutch and a French menu, you create two menu's and assign each a language to each of them. By default the config language is English.
  • English configurations will be translated using the interface translation strings.
  • Config translation is complex. I 've tried, but currently I don't have an opinion on this issue. Perhaps later, but this is all I can contribute now.
Schnitzel’s picture

I totally support this change. It is really confusing that when you are on the translate tab of a Vocabulary (there you see the "Built-in English"), you click on edit and in there is an Language Dropdown which does not contain an English to select.

But: I would suggest to actually show "Built-in English" and not "English", as this is better for UX (of course if English is enabled, it will show "English").
Also I would do the check only for English missing in the options list, as it could happen, that the default value is set to some other language which does not exist and then we inject this language even something is broken.

Status: Needs review » Needs work
Issue tags: -D8MI, -sprint, -language-config

The last submitted patch, drupal-1936216-Fixed-language-selectors-31.patch, failed testing.

Schnitzel’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +D8MI, +sprint, +language-config

The last submitted patch, drupal-1936216-Fixed-language-selectors-31.patch, failed testing.

kfritsche’s picture

Fixed the tests again, as drupalPost method was renamed to drupalPostForm.

I'm in favor of naming it "Built-in English". (+1 #31)

Also I would do the check only for English missing in the options list, as it could happen, that the default value is set to some other language which does not exist and then we inject this language even something is broken.

But when the default value is already set to a non-existing language there, something else is already broken and the config file is probably already written in this way. Also there was a check if this is at least a standard language, so it wouldn't be possible to change this to any value in a form alteration.
When I initial created that patch I thought about deleted languages. For example you have a config in french, then delete french, but the config is still in french. Not sure if this is a real use-case or if we don't support this at all. But I didn't wanted to add a special case for English ;)

grisendo’s picture

Actually 'menu-' prefix is not appended anymore

Schnitzel’s picture

thanks for fixxing tests :)

giving to Gabor for Review

Gábor Hojtsy’s picture

Status: Needs review » Needs work
  1. +++ b/core/modules/language/language.module
    @@ -223,6 +223,12 @@ function language_process_language_select($element) {
    +  // Add "Built-in English" language to the select when the default value is
    +  // set to english but it does not exist in the options list.
    

    English (on second line)

    Also I'd explain this a great deal more here. It is confusing right? :) Something like (additionally to what you already have):

    "Drupal core includes configuration shipped in English, including default views, content types, user roles, filter formats, etc. To keep the Drupal software update-able, as well as translations update-able, we keep these configuration files in English even when installed in a foreign language. However, administrators can remove English, in which case editing such a configuration would lead to the language settings being changed on it. We avoid that by including this option and letting administrators keep it in English."

    May be too long but IMHO needed for people to get why we do this.

  2. +++ b/core/modules/menu/lib/Drupal/menu/Tests/MenuLanguageTest.php
    @@ -157,4 +158,36 @@ function testMenuLanguage() {
    +    // Remove English language. To do that another language has to be set as
    +    // default.
    +    $language = language_load('aa');
    

    Let's give Czech the honors and take them for this test :)

Schnitzel’s picture

1) agree, long, but a good point to explain why we need this.

2) removed aa and added cs love.

Schnitzel’s picture

Status: Needs work » Needs review
Schnitzel’s picture

Issue summary: View changes

Updated issue summary.

Gábor Hojtsy’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Issue summary *text* updated. Images need to be updated still. Will not have time for that now, so marking it with a tag.

Schnitzel’s picture

Status: Needs work » Needs review
FileSize
3.84 KB

outch, need to initialize the language as well :)

Gábor Hojtsy’s picture

IMHO this looks good to RTBC, but the issue summary images are not yet updated. I updated the issue summary text last weekend, which is still accurate.

YesCT’s picture

I'll do the screenshots for the issue summary.

YesCT’s picture

Issue summary: View changes

Updated issue summary.

YesCT’s picture

Issue summary: View changes

added one related issue

YesCT’s picture

I'll put these in the issue summary.

YesCT’s picture

Issue summary: View changes

added related, noticed while testing.

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Looks like it does what it intends to do. The config showing up in Spanish even though it is English is a bug handled in #2099541: ConfigEntities should not load the Entity translated on Edit Forms.

Gábor Hojtsy’s picture

Issue summary: View changes

updated screenshots.

YesCT’s picture

Issue summary: View changes

organizing related issues/follow ups

YesCT’s picture

FileSize
146.07 KB

I checked and the issue mentioned in #19 is fixed in head. I will remove that remaining task from the issue summary.

YesCT’s picture

Issue summary: View changes

oops wrong place

wusel’s picture

Thoughts on "build-in English" versus "build-in language":

If a user has build an own module and he has used not-English text (e.g. all text in his native language) in this module, which language we will find in the configuration of his module?

Wusel

Gábor Hojtsy’s picture

@wusel: Each config file/entity knows their language. If your site is in German, and the config file is in German, the German language will correctly show up in this selector (and English will not, unless you have that configured too). This issue is for only those cases, when the module was built in English with shipped configuration in English and you removed English from your site.

wusel’s picture

@Gábor Hojtsy:

Thank you very much for your very good information. Sorry for my wrong thoughts.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Patch looks great. Thanks for the extended comment. Committed/pushed to 8.x, thanks!

Gábor Hojtsy’s picture

Issue tags: -sprint

Amazing, thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

no longer remaining task.