Hi,

I have some doubts about Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationContentEntity:

I enable the Content language negotiation mechanism in /admin/config/regional/language/detection by checking the "Customize Content language detection" box, and enabling the "Content language" negotiator.

When Content language negotiation is enabled I would expect to be able to change the interface language and the content language independently one from the other, but this does not always work.

I also tried to use the two separate blocks: "Language switcher (Interface text)" and "Language switcher (Content)", and I noticed some inconsistencies.

Outbound paths

For example on the front page, links to entities are not processed by LanguageNegotiationContentEntity::processOutbound() (i.e. the query string for the content translation does not get added, I'd assume the default would be to keep the current content language).

By looking at the code it looks like this can be solved by relaxing the assumptions made in LanguageNegotiationContentEntity::meetsContentEntityRoutesCondition(), right now the condition is:

  1. URL points to an entity;
  2. AND it refers to the current request.

Why can't we just check for the first condition to decide whether or not to process an outbound path?
See #2863465: LanguageNegotiationContentEntity: make links to entities only change the content language.

Language switcher links

Another doubt I have is about LanguageNegotiationContentEntity::getLanguageSwitchLinks(), it looks like this gets never called.
[...]

EDIT: I figured out that I am supposed to use the "Language switcher (Content)" block to switch the content, and not the other one, so I am dropping this part and the last paragraph below, but the other doubts still hold.

Inconsistencies of Language switcher (Interface text)

When "Content language" negotiation is enabled, the "Language switcher (Interface text)" block behaves like this:

  • on the front page it switches the interface language,
  • after visiting an entity path the first time (i.e. no query string in the URL) it only allows to switch the content language (maybe because of processOutbound()?).
  • it breaks completely after actually switching the content language of the entity.

See also [##2864055: LanguageNegotiationContentEntity: don't break interface language switcher links].

Maybe the Language Switcher should always and only deal with the Interface language, and other means should be used to switch the content language? Like a different Language switcher block or some field on the lines of Entity Translation Switcher.

Thanks,
Antonio

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ao2 created an issue. See original summary.

ao2’s picture

Issue summary: View changes
ao2’s picture

Issue summary: View changes
ao2’s picture

Issue summary: View changes
ao2’s picture

Issue summary: View changes

Add link to the child issue about LanguageNegotiationContentEntity::processOutbound().

ao2’s picture

Issue summary: View changes

Added links to another child issue.

ao2’s picture

@penyaskito I double checked and the issues from this report are not directly related to #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content, they happen also after applying the fix from the latter.

I guess this is because LanguageNegotiationContentEntity does not use getCurrentLanguage() directly and that's what #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content is about.

Thanks,
Antonio

Gábor Hojtsy’s picture

What are your respective interface and content language negotiation settings?

ao2’s picture

Here are the language negotiation settings, and the URL negotiator settings, it's a pretty basic setup.

language negotiation settings

URL negotiator settings

More images are in the child issues to illustrate the particular bugs, and the patches provided there do fix the problems, even though some of them are still pretty rough.

Thanks for taking a look.

Ciao ciao,
Antonio

sahuni’s picture

Hello,
I have also doubt about detection of language
in my case I have always administration in French and contents either in French or in German, depending of language selector.
How must I parameter the screen?
what I tried
Interface text language detection
Account administration page ON
User ON
Content language detection
Content language ON
Can you tell me if my configuration is OK for what I intend to do?

That configuration is not working and I think there is still bug. Selector language does work heratically.

I have red the other links https://www.drupal.org/node/2189267, but it seems to me it’s more for people working with the code than for people asking for support

I'm working with drupal 8.3.0 for theese tests

All the best

ao2’s picture

sahuni this report is about Content language negotiation when viewing the content, not about the language selector when editing it.

Try the patch in #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content and see if the situation improves for your case.

Ciao,
Antonio

plach’s picture

Version: 8.3.x-dev » 8.4.x-dev
Status: Active » Postponed (maintainer needs more info)
FileSize
211.76 KB
203.85 KB
240.81 KB
249.13 KB
416.02 KB
415.97 KB

Sorry for the late reply :(

For example on the front page, links to entities are not processed by LanguageNegotiationContentEntity::processOutbound() (i.e. the query string for the content translation does not get added, I'd assume the default would be to keep the current content language).

I was not able to replicate this particular problem on a fresh 8.4.x installation (only core modules enabled). With two separate language switchers, I'm able to switch both UI and Content language on the front page. However I also experienced the bug reported in #2864055: LanguageNegotiationContentEntity: don't break interface language switcher links (see the attached screenshots).

As a side note, would you mind explaining what actual behavior you are trying to implement. The content language negotiator was added in #1810394: Site configuration with domain based language negotiation results in redirecting authenticated users to a different domain when accessing a content entity route for translation language different from the interface language with a very specific use case in mind, depending on yours it might make sense to use the Session language negotiator for the UI (falling back to URL) and the URL language negotiator for content language:

Attached screenshots:

ao2’s picture

Thanks for getting back to me.

I've been suggested by alexpott to mark this issue as duplicate and concentrate only on the child issues.
I'll provide the requested info over there.

About the generic question about my use case, what I am trying to achieve is to have a user-visible and "stateless" way to control the content language independently from the interface language, thats why I didn't try with the session negotiator, but I can give it a try.

Probably I'll end up controlling the content language using the language of path aliases (with https://www.drupal.org/sandbox/ao2/2871754) along the lines of what I am doing on https://ao2.it but I wanted to understand the language negotiators in Drupal core before giving my own any "officiality".

Ciao,
Antonio

plach’s picture

Category: Support request » Bug report
Status: Postponed (maintainer needs more info) » Closed (duplicate)

About the generic question about my use case, what I am trying to achieve is to have a user-visible and "stateless" way to control the content language independently from the interface language, thats why I didn't try with the session negotiator, but I can give it a try.

Re stateless: If you're concerned about SEO and indexability, the Session negotiator will always append a query string parameter to URLs for anonymous users, thus acting as the content language negotiator. The main difference is that it is not affected by entity routes in any way.

Anyway, marking this as a duplicate per #15.