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
User interface changes
Taxonomy before/after:
before:
after:
default config (english)
new config (created on a site without english)
API changes
No.
Related Issues
- #1945226: Add language selector on menus
- #2067435: Configuration language selectors should have translated language names mentioned in #22 and #11
- #2099541: ConfigEntities should not load the Entity translated on Edit Forms not the problem of this issue, but noticed while testing
Comment | File | Size | Author |
---|---|---|---|
#47 | defaultlanguageonokpage.png | 146.07 KB | YesCT |
#45 | no_patch-vocab_es.png | 128.76 KB | YesCT |
#45 | patch-vocab_es.png | 133.64 KB | YesCT |
#45 | patch-es_vocab.png | 131.98 KB | YesCT |
#42 | drupal-1936216-Fixed-language-selectors-42.patch | 3.84 KB | Schnitzel |
Comments
Comment #1
larowlanFwiw 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 tolanguage(LANGUAGE_TYPE_CONTENT)->langcode
Comment #3
larowlanRemoved a comment (wrong issue)
Comment #4
YesCT CreditAttribution: YesCT commentedran into this while thinking about #1945226: Add language selector on menus
Comment #5
Gábor HojtsyThis is a sizable problem for all the shipped configuration that you cannot modify them in any way and keep them in English.
Comment #6
kfritscheComment #7
kfritscheWorking on this.
Comment #8
kfritscheFirst 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.
Comment #10
kfritscheFixed the notices which came up in the test.
Comment #11
webflo CreditAttribution: webflo commentedLoosk good to me. I removed the @todo. Displaying the translated language names is not part of this issue. It should be a follow-up.
Comment #13
webflo CreditAttribution: webflo commented#11: drupal-1936216-Fixed-language-selectors-11.patch queued for re-testing.
Comment #14
Kristen PolWhat's the best way to test this?
Comment #15
Gábor Hojtsy@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.
Comment #16
Kristen PolI 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:
b) The options for menu links did not include English (I guess that makes sense):
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):
Comment #17
Kristen PolOops... meant to crop the second image... attaching here so I can update the previous comment.
Comment #18
kfritscheSounds 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).
Comment #19
Kristen PolThanks @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.
Comment #20
Gábor Hojtsy#11: drupal-1936216-Fixed-language-selectors-11.patch queued for re-testing.
Comment #21
stkrzysiak CreditAttribution: stkrzysiak commentedI 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:
Menu before/after:
Comment #21.0
stkrzysiak CreditAttribution: stkrzysiak commentedAdded before/after screens and filled out rest of issue summary template.
Comment #22
stkrzysiak CreditAttribution: stkrzysiak commentedI 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.
Comment #23
stkrzysiak CreditAttribution: stkrzysiak commentedBad interdiff, sorry about that!
Comment #24
stkrzysiak CreditAttribution: stkrzysiak commentedIt 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!
Comment #25
rteijeiro CreditAttribution: rteijeiro commentedI'm going to review this one :)
Comment #26
Sutharsan CreditAttribution: Sutharsan commentedWhile 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?
Comment #27
Gábor Hojtsy@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.
Comment #28
Sutharsan CreditAttribution: Sutharsan commentedOk, I just proved I don't understand config translation yet :(
Comment #29
Gábor HojtsyYeah, 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).
Comment #30
Sutharsan CreditAttribution: Sutharsan commentedOk, let me summarize what I've learned:
Comment #31
Schnitzel CreditAttribution: Schnitzel commentedI 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.
Comment #33
Schnitzel CreditAttribution: Schnitzel commented#31: drupal-1936216-Fixed-language-selectors-31.patch queued for re-testing.
Comment #35
kfritscheFixed the tests again, as drupalPost method was renamed to drupalPostForm.
I'm in favor of naming it "Built-in English". (+1 #31)
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 ;)
Comment #36
grisendo CreditAttribution: grisendo commentedActually 'menu-' prefix is not appended anymore
Comment #37
Schnitzel CreditAttribution: Schnitzel commentedthanks for fixxing tests :)
giving to Gabor for Review
Comment #38
Gábor HojtsyEnglish (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.
Let's give Czech the honors and take them for this test :)
Comment #39
Schnitzel CreditAttribution: Schnitzel commented1) agree, long, but a good point to explain why we need this.
2) removed aa and added cs love.
Comment #40
Schnitzel CreditAttribution: Schnitzel commentedComment #40.0
Schnitzel CreditAttribution: Schnitzel commentedUpdated issue summary.
Comment #41
Gábor HojtsyIssue summary *text* updated. Images need to be updated still. Will not have time for that now, so marking it with a tag.
Comment #42
Schnitzel CreditAttribution: Schnitzel commentedoutch, need to initialize the language as well :)
Comment #43
Gábor HojtsyIMHO 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.
Comment #44
YesCT CreditAttribution: YesCT commentedI'll do the screenshots for the issue summary.
Comment #44.0
YesCT CreditAttribution: YesCT commentedUpdated issue summary.
Comment #44.1
YesCT CreditAttribution: YesCT commentedadded one related issue
Comment #45
YesCT CreditAttribution: YesCT commentedI'll put these in the issue summary.
Comment #45.0
YesCT CreditAttribution: YesCT commentedadded related, noticed while testing.
Comment #46
Gábor HojtsyLooks 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.
Comment #46.0
Gábor Hojtsyupdated screenshots.
Comment #46.1
YesCT CreditAttribution: YesCT commentedorganizing related issues/follow ups
Comment #47
YesCT CreditAttribution: YesCT commentedI checked and the issue mentioned in #19 is fixed in head. I will remove that remaining task from the issue summary.
Comment #47.0
YesCT CreditAttribution: YesCT commentedoops wrong place
Comment #48
wusel CreditAttribution: wusel commentedThoughts 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
Comment #49
Gábor Hojtsy@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.
Comment #50
wusel CreditAttribution: wusel commented@Gábor Hojtsy:
Thank you very much for your very good information. Sorry for my wrong thoughts.
Comment #51
catchPatch looks great. Thanks for the extended comment. Committed/pushed to 8.x, thanks!
Comment #52
Gábor HojtsyAmazing, thanks!
Comment #53.0
(not verified) CreditAttribution: commentedno longer remaining task.