Score:0

Is it possible to render a View based on the Content language?

us flag

Drupal supports the concept of Interface Language and Content Language. I (and every client I have ever asked) seem to have a different opinion of what is "content" and what is "interface" than Drupal does (in most cases). I consider Interface as the items an administrator or editor would use to do their job (admin menu, edit tab, help details on forms, etc) and Content is what non-admins (often this is Anon but not always) would see.

A view that I create to present "content" on the site, I naturally think of as content - but Drupal has an inconsistent and often incorrect idea of what this is.

To start with, I have the site set up so that Interface language is defined by the User's preferred language (as a site admin/editor would set) and Content language is defined by the URL langcode prefix.

An example test view looks like this in FR (url is /fr/test) - Interface language is set to EN:

content = FR, interface = EN

This is clearly incorrect as can be seen with the proper display when I set the Interface language to FR:

content = FR, interface = FR

Views has numerous options to set how "content" render language is determined. For my example above it is set to render based on the page's "content language" (and therefore the url). This works for most field data (title, taxonomy terms, translated text fields); but sadly does not work for Datetime fields - they seem to be hard coded to incorrectly translate using Interface. But you can also see the config portions of the view (view title, field labels, etc) are also translated as Interface.

Is there any way to tell a view to translate using the content language?

I have used the following code:

  $languageManager = \Drupal::languageManager();
  $langcode = $languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();
  $language = $languageManager->getLanguage($langcode);
  $languageManager->setConfigOverrideLanguage($language);

within a block preprocess function to allow some of the block pieces which are incorrectly using Interface language to translate with the content language. Is there some similar way to override the interface language that a view uses for translation? I am hoping it is something like the code above but that I am simply not inserting in the right place (I have unsuccessfully tried hooks for pre-build, pre-render, query_alter).

If this is possible to do, I would love to write up a contrib module to use the existing ui in a View to set the render language and have it render everything rather than just certain fields.

Jaypan avatar
de flag
"This is clearly incorrect as can be seen" <- How so? What are you expecting to happen that isn't?
liquidcms avatar
us flag
ok, perhaps not that clear? The content language is set (url prefix) to French - so i would like the table to be in French. All of it. The only parts that are set to FR as set by the view render language is the data in column (1). The other parts: column headings, data in col 2 and 3 (dates) and the view title are still displaying in EN. The correct output can be seen by 2nd image when i set the interface language to FR.
Jaypan avatar
de flag
Dates are interface, which is why I believer they are showing according to the language of the interface, rather than the current content language. I unfortunately don't have a solution to this though.
liquidcms avatar
us flag
Can't think of the reasoning that dates would be considered whatever Drupal's definition of interface is, but yes, they are incorrectly translated as interface. I'm sure that's a bug; but not what I'm asking about. Rather than submit a patch to just fix the Datetime module, I want to figure out how to do a complete render of the view with a defined language.
ru flag
Dates aren't translated, they are localized (just like the decimal point symbol), and the localization is based on the interface language. E.g. `07/12` is the `12th of July` in the US, while every european would read this as `7th of December`. Without context `1.000` would be `one (comma zero)` in the US, and is `one thousand` in german speaking countries. Drupal's localization is excellent, and perfectly fine as it is.
Jaypan avatar
de flag
Dates can be translated - they are configuration, and translation is able to be enabled for them.
liquidcms avatar
us flag
@Hudri, i understand how dates work. Actually 2 pieces: localized strings like month and day of week as well as translated formats as Jaypan mentions. The problem is "based on interface language" - yes, that's true - and wrong. Why would you ever want a Views table with every column in the correct language except the date column? I would guess you have always run with the Drupal default which is to have interface/content translation tied together. Note: my OP is about controlling how Views renders - not about dates. I think Jaypan understands what i am trying to do. :)
ru flag
*The problem is "based on interface language" - yes, that's true - and wrong.* - I strongly disagree here :-) Our company is focussing on tourism clients, _all_ our projects are multi-lingual. E.g. they offer holiday packages, and it is essential to get the date format in the guest's common date format (even if the node is not translated, they still do get localized dates from interface language). This saves a ton of questions and problems in our business. On topic: Sorry I don't know the answer.
liquidcms avatar
us flag
Yes, our use cases are different. Mine is for a Canadian federal government site. There are no such thing as untranslated pages. My goal is to create a site where the content (which includes dates) is defined by the content language of the site (url); but the site editors can work in their preferred language (interface). But more to the point; Drupal almost allows for these different use cases. Even for Views, they have an option on how to decide language to render the view - it just doesn't work correctly. My guess would be your site has content/interface detection set the same, correct?
Score:0
us flag

Ughh.. apparently my question had the answer all along. When I add the code snippet:

  $languageManager = \Drupal::languageManager();
  $langcode = $languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();
  $language = $languageManager->getLanguage($langcode);
  $languageManager->setConfigOverrideLanguage($language);

to a _views_pre_render hook it does what I want and uses the config override language to override the language used for the configurable parts of the view (title, column headings and more). The only thing it doesn't handle is the dates - as these are just done wrong in the Datetime module. Not sure why I didn't see this working when I tried it earlier.

And I can override the DateFormatter core service to use the Content language instead of the default (which is interface) and this fixes dates everywhere on the site. This should likely be submitted as a patch to core as I am sure this is a bug - why would dates be considered interface differently than all other content?

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.