Content and interface translation don't clearly separate

Fixed typos, added tags and related issues.

More related issues.

Why would you "need" to enable "Content language detection" in order to have the backend in another language than the frontend?
I assume that enabling the "Account administration pages" Language Negotiation plugin should suffice.

Note that there are still some bugs in LanguageNegotiationUserAdmin: see https://www.drupal.org/project/drupal/issues/2189267.

We need the content vs interface language separation because our pages are a mix of administration menus and local tasks (for example, the node "edit" tab) which are desirable to be in English and strings from our custom theme which are desirable to be in the content language (for example {{ 'Log In'|t }}). I have written a module called Translate to content language which changes the meaning of the t filter in the default theme to translate to the content language and added a few more relevant things like a [content] langcode. If anyone is interested in taking it over, please email me at chx1975@gmail.com and I will hand it over promptly.

I am not following this issue.

From the IS:

IMHO the purpose to have this distinction [between interface language and content language] is to have a backend in one language and the actual content/frontend in an other.

This is right for "content", but wrong for "frontend". In fact the idea is that you can view a russion node (content language) with a french navigation (interface language). It looks to me that this issue's idea this backend/frontend misunderstanding so please clarify.

tl;dr: if the interface and content languages differ then t() translates to the interface language and I am unaware of any way to translate to the content language.

I have attached a language.types change we did -- one that broke our foreign language sites (in QA, we didn't roll it). Most importantly, it removes the URL negotiation from the interface language and forces it to be the user chosen one.

After doing this change, this is the Smartsheet German homepage:

This is the Smartsheet German homepage in production:

Post tranc, when I log in:

The relevant call outs are printed in theme like: {{ 'Try Smartsheet for Free'|t }} and {{ 'Log In'|t }} and the more dropdown is {{ "MORE"|t }}. These all display in English because t translates to the interface language and the interface language is hardcoded to English for anonymous after the language.types change. As you can see on the larger image, the entire page is in German otherwise.

The post tranc screenshot show what is desirable -- at least for us: the interface for admins is still English, the translation is outsourced, we have eight languages, I am not aware of any polyglot admins who speaks all eight. Nonetheless, they need to do changes on foreign language sites (for example, unpublish something) and that's why we embarked on this journey.

We have a block which says "This content is only available in English". This is the simplest block imaginable, it just prints a message in certain conditions, but the only way to translate that message -- at least that I am aware of but my knowledge might be spotty, without a doubt -- is to call down t on it but then, again, it will translate to the interface language and it is, by all means, part of the content.

It is also entirely possible I have no idea what I am talking about and the entire tranc module is in error. But if not, then the tc function and corresponding new filters (tc,transc) from tranc should be in core so that ongoing people have ways to translate to content language. The block I mentioned is now doing tc('This content is only available in English'). Possibly a new transc Twig tag should be added too, this would require factoring out the $compiler->write('echo ' . (empty($plural) ? 't' in TwigNodeTrans::compile so that tc can be written for the relevant tag. (The tranc module also automates changing t etc in the default theme to tc but I doubt that's core material.)

I hope all this rant will help someone update the IS.

@Charlie: Thanks for elaborating this. This gives me an idea.

Did you think it the other way round:
* Only switch the interface language
* Make sure that content is shown in interface language (i have not at hand how)
* Make sure that admin pages show in english (maybe with a higher prio language negotiator)

Just a gut feeling of how i'd approach this given my humble understanding of language system inner workings.
HTH.

The page above with the mixed languages is the front page. It's not an admin page. The content -- which visitors see -- is in German, the admin menu and tabs are in English. Also, if the only thing that actually works is having a separate language for admin pages and visitor facing pages then why do we even have interface and content language? It feels this is a great feature which needs just a little love to be finished, a feature to make it possible to print strings in the content language from the module and theme. I implemented this by adding a [content] langcode, a helper tc function and two simple Twig filters. It's not a lot of code.

The other issues mentioned in the summary are a bit annoying but easily fixed: you need to search-replace '***LANGUAGE_language_interface***': '***LANGUAGE_language_interface***' to '***LANGUAGE_language_content***': '***LANGUAGE_language_content***' in views.view.*.yml and language_block:language_interface to language_block:language_content in block.block.*.yml. If you are using the lang_dropdown module then similarly, just the plugin id is language_dropdown_block. as well. This part of the issue could be fixed by writing it up on a documentation page and linking to it from the language types edit screen.

Sorry if this is out of context; but closest thing i have found to the confusion of separating content/interface language. Perhaps my confusion is solely based on my perception of what Interface and content refers to? My setup for a FR/EN site is basically what is shown in the original post:
Interface: defined by User preference
Content: defined by URL

I am making the assumption that Interface refers to the interface a content editor/admin/traqnslator would use to navigate the site. For this reason; the editor would want to define their own language preference for the "interface". This interface would define the language used to translate things like Edit/Delete tab and Content would be basically everything anonymous or standard user would see. These assumptions must be wrong then as a vanilla D9 site gives this:

The editor has defined EN has preferred language and as a result sees Edit tab in EN.. yay!! But on this FR version of a node i see:
- body in FR: correct
- tag term in FR: correct
- title in FR: correct
but everything else is in EN (field labels, submitted by, comment labels, date formats).

I was thinking this is due to my field labels not being translated but that is not the case. Are these things not considered content? Surely the date field is content? Why does it not translate?

Sure enough, switching my editor's lang preference to FR and all these pieces translate correctly to FR - but why are all of these considered interface?

why thier is a need of seperate content translation if interface is translated let the content be translated as per it

@VIGHNESH SADAGOPAL: An example: A QA person might be testing that parts of content are translated in russian but they don't need the admin menu translated in russian and actually need the admin menu to be in english for their own navigation. So you need parts of the page as interface and the others as content, to essentially segment backend and customer concerns.

@liquidcms (#23)

Interface: defined by User preference
Content: defined by URL

Correct, same for us! This is what makes sense. Reason is perfectly described in several posts here, like #25:

An example: A QA person might be testing that parts of content are translated in russian but they don't need the admin menu translated in russian and actually need the admin menu to be in english for their own navigation. So you need parts of the page as interface and the others as content, to essentially segment backend and customer concerns.

@all: Is there any meta issue for this topic? As long as I can't find one, I'll add a further related issue.

An anonymous bird sent me this patch, he/she/they/other wishes to stay anonymous.

I expect test failures with this patch as it's changing the behavior of core in a way that makes sense to many but is different to the current behavior of core.

**EDIT**
There's some minor issues with the patch to resolve.

Feel free to run with this
**EDIT**

Hi All,

For some times now playing around and scratching my boys on how to separate Drupal interface vs content translation. In my case interface is everything what is static (labels, buttons, etc) and content is everything entered by user.
Let's say social network where content/posts can be entered in any language (text, not langcode), while users would prefer to navigate/see interface in his preferred language.
Ideally nodes/posts would be not translatable, while interface language driven by user setting or session for anonymous.
After exhaustive playing around I see only viable option is to create auto-translations to every language (without actually translating text). But that seems bit overkill. Any ideas how to achieve this in Dupal 10 or higher?

Thanks,
Monk

On a related note, some block titles and menu items are translatable, and some are not (Views block title, custom menu items) and it's not clear why ... I created #3549927: Streamline translation of Views block titles, custom menu titles, etc.: Allow Interface Translation.