Views now have language settings per row on entity based views. This is great. We are proposing to add similar settings to field views in #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language" (as opposed to the current global display based setting). However, the existing content row settings are confusing. Is default language the site default? No, its the original language of the entity, which we call "Original language" elsewhere. Is current language the one found for the entity? No. Its the content language negotiated for the page. We call that "Language selected for Content" elsewhere, eg. in field filters. The translation language may be the least ambiguous.
@jhodgdon also suggested we add other types of dynamic options here, eg. "Site default language" and concrete languages. We may or may not want to pursue that here.
Rename the options to be sensible. This will need some wordsmithing. Current suggestions:
These may be too verbose. Also suggested to rename "Rendering language" (which sounds too technical) to "Display in language" or "Display language" which is more friendly.
Discuss. Fix. Review. Commit.
Options will be cleaner.
BEFORE (closed):
BEFORE (open):
AFTER (closed):
AFTER (open):
None.
Comments
Comment #1
gábor hojtsyComment #2
gábor hojtsyComment #3
jhodgdonI think we should aim to be consistent with labels of the fields/filters and of the language negotiation/detection settings UI? How about this:
a) Options labels:
- Detected/selected language for Content on the page
- Original language of content
- Translated language of content
b) Description text below select field:
Each row contains one translation of the content. You can display each row using the language of that row ("Translated language of content"), or you can choose a different language.
Comment #4
gábor hojtsyYeah here the question of row vs. page comes up and needs to be explained somehow which is how it is different from the negotiation / views field text. And part of the reason I did not pick the uppercase "Content" for example that would otherwise be similar to the language on the views field setup. Otherwise looks good. Any other opinions?
Comment #5
bwinett commentedI'm at the PNW Drupal summit sprint. I'll look at this now.
Comment #6
bwinett commentedThe only way I could understand the differences between these 3 options was to do a test and create a table.
I created a node, in English, titled "1st node - English", and created a translation, titled "1st node - Spanish".
I created another node, in Spanish, titled "2nd node - Spanish", and created a translation, titled "2nd node - English".
I created another node, in Spanish, titled "3rd node - Spanish". Note that I didn't translate this node.
I created a view.
After testing, here's my table:
node 1 - English
node 1 - Spanish
node 2 - Spanish
node 2 - English
node 3 - Spanish
Below is all I could come up with, though I have to keep looking back at the table to truly understand the differences.
current -> detected & selected content language
default -> original language version
translation -> translated version
Description text below select field:
If you have translated content, this setting allows you to control the language used to display the content.
Comment #7
plachSince I wrote the code that originally introduced this, I really cannot think of better names. I can only say that the proposals above, albeit more verbose, do not really seem to convey more information, at least to my eyes. Maybe we could add a description below the select widget explaining the various options?
Anyway, we may want to postpone this on #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language": once we come up with a sensible UX over there, it might be easier to fix this.
Comment #8
gábor hojtsy@plach: I think it actually makes easier to get #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language" committed if the options are easier to understand. If we use the same labels there someone will look at that issue and get confused. If we use different labels there then we'll need to do this discussion there, and that has enough to cover. So that is basically why I opened this issue separately.
Clearly we are not at a point yet to agree on any improvements :)
Comment #9
jhodgdonYeah, so let's maybe make this issue "Decide on some sensible UI text" and then actually implement it on the other issue?
Comment #10
gábor hojtsyYeah we can figure out whether to implement it here or there when we agree :)
Comment #11
jhodgdonComment #12
gábor hojtsyBased on the lack of interest, looks like this is good as it is? Not confusing anyone I guess...
Comment #13
plachI think it's just lack of time, not interest. I definitely wanted to start helping with all the Views issues that you guys were not able to fix meanwhile (great job, btw!). What about just leaving this open and off sprint?
Comment #14
gábor hojtsyI don't think that is much better than closing it :D
Comment #15
plachWell, it prevents it from being forgot ;)
Comment #16
dawehnerSo @Gábor Hojtsy was talking about an issue which unifies the field language settings and the row language settings mentioned here.
Does it even make sense to work on the row level one, in case we want to have just one unified anyway?
Comment #17
gábor hojtsy@dawehner: yeah the idea was that we can clean up that UI and use the other issue to move the UI as-is then to the display level, instead of the row level (#2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language"). We can use that issue to rework the UI *and* move it to a different place all at once, which both you and @jhodgdon seem to prefer instead of using this one to rework the UI and that one to move. I am concerned doing too much in that issue will be harder to agree, but it may not be too much after all.
Please close this if you believe that assessment is right.
Comment #18
dawehnerSo yeah I totally agree it belongs onto the display level.
Comment #19
gábor hojtsy@dawehner: right, I hoped to use this issue to clean up the UX and that one to move it, so we don't need to argue both things over and over in the same issue :) Any feedback on the UX changes?
Comment #20
jhodgdonI don't really know that we need to have this issue open. If we ever fix the field issues and unify the settings, we will have a longer list of options and they will be so confusing we will have to fix it there. I personally think we should just close this and wait for the other issue.
Close this as a duplicate of #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language" I mean.
Because it's not such a huge issue at the moment for the row settings for entities, but it will be a huge problem in that other issue.
Comment #21
gábor hojtsy@jhodgdon: so what we can do *anytime* is to move the existing row level setting for language on the display level and fix the UX. The entity view can work off of a display level setting, it does not need to be a row setting. Or anyway, the field refactoring would not help with that. So do you want to use #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language" to move the setting and rework / discuss the UX there?
Comment #22
jhodgdonOh dang. I just wrote up a nice summary here and lost it :((((
So. We really have a bunch of issues, and I am not sure how to split them up best.
a) This issue: The UI for settings for entity row display language -- the labels are confusing. Sure, we can fix that here and now on this issue.
b) Field views and entity views should have unified language settings. Fixing that involves two pieces:
1) Unify: Make them actually have the same options. Right now Fields have options for definite languages (English, Spanish, Site Default Language, etc.), and Entities have options for negotiated language of the page, entity base language, and language of the row (that is what the settings mean independent of the current UI). Combining them is not trivial because the Fields will need some new code to translate into those languages, but it is doable.
2) Move: Moving the setting to the Display (and not in Advanced as it currently is for Field views) for both. That also is not exactly trivial, but is doable.
We could do this unfiy-and-move on this issue, on #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language" as it is currently planned, or on a new 3rd issue dedicated only to that.
c) Base fields vs. Field UI fields - base fields like Title on entities are not currently working as entity fields and so they cannot be translated at all, no matter where the settings are or what their options are. That is #2342045: Standard views base fields need to use same rendering as Field UI fields, for formatting, access checking, and translation consistency.
So... Due to (c) the other issue is postponed, but sure we could work on the rest now. But it will be really hard to write tests that pass or make test views for Field-based views until that is fixed.
Comment #23
gábor hojtsyI don't think its fun continuing discussing what we cannot do. Not very productive. Opened #2394041: Row language settings from entity views should be on display level for all views.
Comment #24
jhodgdonGreat! Yes let's move forward piece by piece. Sensible.
Comment #25
gábor hojtsyLet's do this discussion all over again in #2394883-6: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage where it will actually need to be made work as a merged list of options so there are some stakes, that may make it more interesting to get feedback.