- Status changed to Needs work
over 1 year ago 4:33pm 10 January 2024 - πΊπΈUnited States smustgrave
11.x is the current development branch.
It's recommended to use MRs as patches are being phased out and don't automatically run anymore. Will manually trigger but see that new functions should have a return typehint, didn't do a full review though.
- last update
over 1 year ago CI error - Merge request !6108Issue #3101747: Allow to use interface language for menu items. β (Open) created by lobsterr
- Status changed to Needs review
over 1 year ago 5:02pm 10 January 2024 - πΊπΈUnited States smustgrave
Hiding patches for clarity.
Left some comments but also appears to have a test failure.
- Status changed to Needs work
over 1 year ago 5:22pm 10 January 2024 - First commit to issue fork.
Hi,
Here is the reroll of patch #36 for drupal 10.3.x.
Regards- π«π·France erwangel
Sorry for the long post that follows but I found this is the most mature issue resolution and I hope my test and comments may contribute to further clarify the problem and improve its solution.
It seems that menus are displayed in their original or interface language or content language according to their provenance (how where they generated). In some cases this can lead to mixture of translated and untranslated menus. But the problem is not only in menus, displaying of block titles, field labels can also create a language confusion.
I am of the opinion that switching content language should not affect the interface (menus, blocks titles and content, any links, etc.) and only change the main content (node or views listing), not event the entire page content (related blocks and other extra content), i.e. only change what is called the "Main page content" in block layout. This opinion because users may be able to read an article in various languages but have a preferred language for the user interface and the rest of the content. They just occasionally prefer read an article in a language different of their usual language. An American-spanish-speaken citizen may want its site in English but if an article is published in both English and Spanish he may prefer read the article in Spanish without seen the entire site switched in Spanish. I think that is the main reason for separating interface and content translation.
Now here my observations on a D10.4 installation before applying the patch.
Configuration: fr (french default), en (English), de (Deutsch - German)
Interface detection: from url (path prefix)
Content detection: content language (request parameter 'language_content_entity')In order to avoid fastidious repetitions, I defined tree types of menus:
- TYPE 1: menu links provided by the Standard module (ex. "Home" link) or by Views or by Taxonomy Menu module (you can not edit nor translate them in "admin/structure/menu")
- TYPE 2: menu links provided by nodes ("Provide a menu link" option in node's edit page and you can also edit/translate in "admin/structure/menu") or empty links ( to display link text only)
- TYPE 3: any other menus manually created and translated in "admin/structure/menu" either with internal path or a node link theyCases:
* Interface FR (default), no request param
- url: /page-fr-url (aliased on node's title) => content, content field labels, menus, blocks in FR as expected* Interface FR (default), language_content_entity=FR
- url: /page-fr-url?language_content_entity=fr => same as above as expected* Interface FR, language_content_entity=EN (or DE)
- url: /page-fr-url?language_content_entity=en
- Content is displayed in content language (EN), field labels too, block title and content are in interface language (FR)
- Menus TYPE 1 titles: respect the interface language (fr)
- Menus TYPE 2 titles: they follow the content language (en).
- Menus TYPE 3 titles: they follow the content language (en)
- All Menu urls are build according to the interface language (fr is default so no prefix in url)
- Local task tabs respect the Interface language (fr)
As Result: A confusing mixture of menus translated in one or other language!* Interface language EN, no request param
- url: /en/page-en-url (aliased on node's title)
- Content shows in default FR (content lang) but field labels in EN! (interface lang), block titles in interface language EN
- Menus TYPE 1 respect the interface language (EN)
- Menus TYPE 2 and 3 are in... default FR! even when both the menu text the linked page have a translation in the current interface language
- All Menu urls are build according to the interface language (/en/___)
- Local tasks respect interface (EN)
--- Note 1: In untranslatable and in untranslated nodes, same behavior as above (mixed translations)
--- Note 2: In Views pages, all menu types are displayed as expected in the interface language
Conclusion: it is like the lack of language_content_entity parameter has a fallback to the default content language.There may be some logic here too but ths leads to unexpected result: having make no choice about content language one could expect that the entire page would be in the interface chosen language.* Interface language EN, language_content_entity=FR (default)
- url: /en/page-en-url?language_content_entity=fr => Same as with no request parameter* Interface language EN, language_content_entity=EN
- url: /en/page-en-url?language_content_entity=en => everything is in English* Interface language EN, language_content_entity=DE (default FR language is not implied in interface nor in content)
- url: /en/page-de-url?language_content_entity=de
- Content displays in the content language (DE), block titles are in interface language EN even those placed inside content with layour builder (I think they should be consistent with the rest of node's content, i.e. have the content language DE)
- Menus TYPE 1 respect the interface language (EN)
- Menus TYPE 2 and 3 follow the content language (DE)
- All Menu urls are build according to the interface language (/en/___)
- Local tasks respect interface (EN)Conclusion
There is no validation of language_content_entity's value at least from user's point of view. You can set manually whatever you want, numbers, letters, special characters, you never get an error message.
In views content (pages and blocks): In views you have different choices for the Rendering Language, but titles will display according to the interface language.
Content blocks:
Added on a page with block layout (/admin/structure/block): title in interface language, content in content language.
Added in a node with layout builder (/node/nid/layout): no way to translate the title, content in content languageIn node's full mode: title and content they display in the content language but field labels and views blocks inserted with layout builder are in the interface language. If I a am able to understand the content in one language I am able to understand the fields labels and the block titles too no? Are Field labels and block titles part of the interface or do they belong to the content ? (I am for the second option)
Menus: titles obey to the interface language if links were generated by a module, but they obey to the content language if they were generated by a node or "by hand". In any case, the underlying url is build according to the interface language. So you can have a link whose text is in German but the url is the English one. Once you click it the interface will switch to English. Not necessarily what is desired.
What can we do ?
I know there have been long discussions about content and interface translation. Looking to the current situation and the several patches here and there that try to resolve one or an other problem, It doesn't seem like it clarified anything. I think we have to radically simplify and consider that
1) Only menus, action links and buttons are part of the interface and they should behave according to the interfae language regardless their provenance.
2) Block title and Field label's function is to announce what follows, i.e. content. So they should be considered as content and display according to the content language
3) Have the option to apply content translation only to what is called the "Main page content" in block layout or to the entire page
4) Menu link titles and underlying urls should be language complaints
4) Verify that language_content_entity value validates against the available language, otherwise throw an error