The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
In most aspects, views work great with content language (contents) vs. interface language (admin). This is for example important if you have contents on the page (e.g. chinese or russian) you can't read as administrator (e.g. English user)
For "More link" text (1), this is NOT the case. It always uses interface language (despite other views elements as it seems, which work just fine!)
I first thought the reason was a wrong configuration in (2) and tried other settings (and cleared cache), but still the same.
Expected result:
If using content language and having the "Rendering Language" setting (2) set to "Content language of view row" (or any other option which you'd expect to also work for the "More link text" (1)
Actual result
The "More link text" (1) is always output in interface language, regardless which content language is selected or which "Rendering language" setting is set in views.
Only switching the interface language shows the correct translation!
We've configured
- interface language to be defined from user setting or fallback to browser language
- content language to be defined from URL suffix or fallback to browser language or default language
Steps to reproduce
See above
Proposed resolution
Handle the "More link" text like all other elements in views and show it in content language, eventually based on the views "Rendering Language" setting (2) - I'm not experienced enough in the details here.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| views-read-more-link-interface-language.JPG | 56.85 KB | anybody |
Comments
Comment #2
anybodyComment #3
anybodyComment #4
anybodyComment #5
lendudeThe 'More' link is a View wide link, not a link per row, so it's an interface element and not a row element I think, so it using the interface language and not the row language makes sense I feel.
I do agree that the Title 'Language' is a bit deceptive, it should probably be 'Row rendering language' or something like that.
But to me, this works as designed (unless I misunderstood something in the issue)
Comment #6
anybodyThank you for your feedback @Lendude, well I don't think it works as designed or at least shouldn't be designed this way ;)
Have a look at all issues regarding interface language vs. content language. In 99% (or even more) of the issues people are using it the following way:
This is a very important concept for multilang projects (I'll take a website as example here) as the content lanugage (website content) may not be understood by the editing users, for example if the editors / admins speak English, but there are contents in Chinese or Russian.
While all page contents for the visitors must in the selected language (which also means read on links should be same language as views content - at least if not configured differently), the administration parts (admin menu, tabs, edit forms, ...) must be in interface language!
Currently, the views contents are in content language, but the "read more" link seems to be hardcoded to use interface language. That's definitely unexpected for visitors and admins.
The read more link / text definitely is a lot more "content" than "interface", but I agree we need a higher level of abstraction and setting here to let the administrator decide. And a good default for most of the cases, which would be content language here for views.
A case where you'd want to switch everything to "Interface language" in the view, might be admin views for example.
So maybe we require a further parent issue to better align settings to this concept! There's still a lot of work required in this whole topic to be consistent, see the related issues.
I still think the existing select marked above might be the one for the view to set which language (source) to use!
Comment #10
anybodySame issue seems to exist for "Global" Textarea and Textfield in header and footer. That should be a separate issue, but both are highly related.
In my opinion, these should follow the rendering language setting!