Entity formatters should (maybe?) render UI/Config text that is part of the display using the entity language, not the current interface language

Makes sense I guess.

There's also the field definition label, which I guess has the same issue, or not? And we have no API to get that in the content language...

This problem came up because I was testing #2342045: Standard views base fields need to use same rendering as Field UI fields, for formatting, access checking, and translation consistency, which is changing some Views Booleans to use Field formatters.

The Views display has a setting for the "Display language" for the entity within the row. The question is what that should do.

I guess my expectation is that all the stuff in that row of the view would be displayed in whatever the language is that is determined for that row. But maybe that expectation is flawed...

The information displayed would include:
- Which data is loaded (which translation is used to decide if a Boolean field's value is a 0 or 1, or a text field's value is "Test" in English or "Prueba" in Spanish, etc.).
- The field labels specified in the View. [But maybe these should be displayed in the UI language for the page?]
- For Boolean fields, once you've found the value, there's a formatter setting that says "1 is yes, 0 is no", or whatever. My expectation would be that these would be displayed as Si/No if the row is displaying in Spanish.
[But maybe these should be displayed in the UI language of the page? Presumably they're either config (if custom) or UI text (if a built-in alternative is chosen).]

Hm... I'm not sure really what should happen. So let's say you have a node with English and Spanish versions. The English one is Published and the Spanish one isn't. And for whatever reason, you have a view that displays the node title and the Published field (in Yes/No format).

So the question is, should it look like:

a)
My title
Published: Yes [if viewing the page in English]
Publicado: Si [if viewing the page in Spanish]

Mi titulo
Publicado: No

b)
My Title
Published: Yes

Mi Titulo
Published: No [if viewing the page in English]
Publicado: No [if viewing the page in Spanish]

And here I mean by "viewing the page in X" that you go to example.com/es/[URL] vs. just example.com/[URL] to switch the UI language.

I think that outside of Views, on most sites, this isn't a problem, because normally the Content language is the same as the UI language on a given page (same negotiated/selected language criteria), so normally the content and the field titles and the formatter config is all being displayed in the same language. But in the case of Views, you can have multiple translations being displayed in the same view, so we have to think about what should happen in this case.

I'm not sure what the right answer is... and probably didn't need to add this overly verbose comment to describe what you undoubtedly had already thought through. ;)

Yeah, formatters that transform field values based on some properties held in config are problematic.

The underlying field values (0/1 for a boolean, a timestamp for a date) are the correct values for the "content language", but they are then transformed (to "Yes/no" strings, to date formats) using configuration that is the one for the "interface language". Depending on what the transformation does, this ends up looking slightly off or frankly broken.

Same issue for the field labels that get prepended to the displayed values.

No real suggestion atm, just trying to get a clear view of the issue. We're at the problematic intersection of content and config :-/

Slight correction...

problematic intersection of content and config *and interface* *translation*

And no, that doesn't make it easier ;)

Yes, that is true. Adjusting title, and rewriting summary.

So I am becoming less sure whether (a) changing how this works would be a good idea and (b) if it is even practical if we decide it's a good idea. I guess it seems like kind of an edge case, but at best it would be a very complicated rewrite of the Interface, Config, and Content translation system to say "Well, in spite of the overall page language, this bit of config and this bit of UI text is part of an entity display on this page that's in a different language, so translate it to something different after all".

I think we should just close this as a Works as Designed and decide that I was being silly to bring it up on the other issue that dawehner spun this off from.

So... should we just close this?

Going to close this as works as designed, seven years after that was proposed as the solution.