Beta phase evaluation
Issue category | Bug because entity and field language settings are hidden at different places and even shown when does not make sense (fields setting shown even on views where entities are not translatable) |
---|---|
Issue priority | Major because it makes very hard to create language based views while we modified many pages and blocks to be views and promote better multilingual features. |
Prioritized changes | The main goal of this issue is usability improvements. Further usability improvements are planned in #2394883: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage. |
Disruption | Changes where entity view language rendering settings are stored which may be modified again in #2394883: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage (or may be merged with field language settings, in which case those would change) but this separation of issues makes it easier to review / digest. |
Problem/Motivation
As per #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language" we need to move and unify the language settings for different types of views. Now entity views have a row setting and field views have a display level setting. We need to unify those two. As a first step we should move the row setting to the display level and then move on to rework the two settings to apply to language handling regardless of whether on an entity or fields based view.
Proposed resolution
Move entity row based language settings to the display level. Ensure tests still work.
Remaining tasks
Patch. Review. Commit.
User interface changes
Entity views will have a display level setting for language instead of row level. Two language settings moved together to one place.
(Opened #2394883: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage to unify them).
API changes
Language settings for an entity based view will now be on the display not the row plugin.
Comment | File | Size | Author |
---|---|---|---|
#6 | interdiff.txt | 1.51 KB | Gábor Hojtsy |
#6 | 2394041-display-language-setting-6.patch | 18.31 KB | Gábor Hojtsy |
#4 | interdiff.txt | 3.64 KB | Gábor Hojtsy |
#4 | 2394041-display-language-setting-4.patch | 18 KB | Gábor Hojtsy |
#3 | interdiff.txt | 3.28 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor HojtsyComment #3
Gábor HojtsyThe field langcode edit test was assuming that the option will display if the site is not multilingual which is silly and not anymore the case in the test. Fixing that assumption.
Comment #4
Gábor HojtsyUnify the entity base table translatability checking which applies the same way to the rendering language setting. This makes it sure that these will not appear either for non-entity based views, where they don't make sense.
Comment #6
Gábor HojtsyOf course the test view is not entity based so the field language selector should not show up.
Comment #7
Gábor HojtsyComment #8
Gábor HojtsyGot this feedback, will take a short look:
Comment #9
jhodgdonThis patch looks very straightforward. Not sure about dawehner's feedback, but I do not see any problems with the patch in #6, and it passes the test, so I would be +1 for RTBC at this point...
Because it looks to me as though the patch here does exactly what the issue summary proposes: Moves the Row-based language setting for Entity views to the Display, and puts that and the Field language setting into a new Language area on the view. Nothing more. Nothing less. I am not sure what #8 means but... is it a separate issue?
Comment #10
dawehnerWell, this feedback was regarding solving the problem that field rendering still works entirely different.
Comment #11
Gábor HojtsySubmitted #2394883: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage, postponed on this issue to unify them. Let's see if a separation of steps like this works well with committers. It means more manageable change but also two consecutive API changes at least in terms of where the plugins source their data from in the views structure.
Comment #12
jhodgdonWe will need both a Beta Evaluation and a Change Record before this can be committed.
Comment #13
Gábor HojtsyComment #14
Gábor HojtsyAdded beta evaluation, please update if you don't agree.
Comment #15
Gábor HojtsyComment #16
Gábor HojtsyDraft change notice at https://www.drupal.org/node/2394917
Comment #17
jhodgdonBeta and change notice look good to me, this should be ready to commit I hope!
Comment #18
alexpottshouldn't we be setting #access on these elements depending on
Drupal::languageManager()->isMultilingual() && $this->isBaseTableTranslatable()
instead of making them conditional.Comment #19
Gábor Hojtsy@alexpott: if you look at the existing code in that optionsSummary() method, there are no use of #access on ANY of the items, however there are dozens of conditionally added items like:
It is true that these option summaries seem to be ending up in a render array later on, so theoretically #access could work but it would be *very* different from how the rest of this method is written.
Comment #20
alexpott#19 okay - fine by me. Committed 145b53c and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation for to the issue summary.
Comment #22
Gábor HojtsyThanks, published change notice. Onwards to #2394883: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage.