Background:
1. \Drupal\Core\Language\LanguageInterface::TYPE_URL is not configurable and cannot be made configurable without editing the configuration by hand. Thus, \Drupal\language\Plugin\Derivative\LanguageBlock::getDerivativeDefinitions() will never generate a language switcher block for the URL language type.
2. Given you have a language-specific path alias and visit that URL given by the alias, \Drupal\Core\PathProcessor\PathProcessorAlias::processInbound() will delegate to \Drupal\Core\Path\AliasManager::getPathByAlias() determine the system path of the current URL. The latter (rightly) uses LanguageInterface::TYPE_URL to determine the current language for the alias.
Problem:
Using the language switcher block will generate the switch links using type Language\LanguageInterface::TYPE_INTERFACE (see 1.). Unless this happens to match the negotiation rules of LanguageInterface::TYPE_URL it will thus produce links which when clicked will result in a "Page not found" error, because the system path cannot be determined (see 2.).
This problem is mitigated by the fact that in the default configuration, that Drupal ships with, Language\LanguageInterface::TYPE_INTERFACE and Language\LanguageInterface::TYPE_URL have matching negotiation rules, so that this problem does not surface. However, because the URL negotiation cannot be configured (see 1.), as soon as the interface negotiation is changed, this breaks.
Note that this is further mitigated by #2666634: Session and content entity switch links do not set the URL language, because at the moment language switch link generation does not work with language-aware aliases when using session negotiation. That does not change the fact that the aliases cannot be resolved properly, it just means that the language switcher block does not properly link to the aliases in the first place.
???
First step: Find a solution.
???
???
???
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2666628-3-test.patch | 3.69 KB | tstoeckler |
Comments
Comment #2
tstoecklerUpdating issue summary.
Comment #3
tstoecklerOK, here's a test proving that this is broken.
I wasn't aware that #2666634: Session and content entity switch links do not set the URL language actually changes the behavior here slightly, so noting that in the issue summary.
Comment #4
tstoecklerI've been working on this and #2666634: Session and content entity switch links do not set the URL language in parallel, that's why the patch is what it is and it is in fact valid, but I wanted to point out that since this is actually not necessarily related to the switch links, but to the alias resolving which is broken under these circumstances, the test should be somewhere other than
LanguageSwitchingTestin the end.Comment #11
manuel.adanI ran into this. Trying to access a content entity with:
I got "page not found". (Default language is 'en').
As mentioned in the issue description (2 years ago), the URL language negotiation rule is disabled in my configuration. I spent a few hours to determine what was wrong.
I did not heard about URL language type before, there is no configuration entry in config UI and it is not covered by the documentation. What's the point of having an URL language negotiation type?
I managed to solve it by manually editing the "language.types" configuration, making a copy of the "language_interface:" values into the "language_url:" section. But after saving the language negotiation preferences, it returns to the defaults. As a test, I tried to manually add the language URL type in the list of configurable types as follows (language.types.yml):
That makes the language URL type negotiation configuration appear in the preferences form ( admin/config/regional/language/detection ), it works despite of a bunch of PHP notices.
Precisely to expose this configuration options in the same way that the content language detection could be a solution to this.
Comment #12
manuel.adanI found that it is actually another bug: #2824086: URL language detection has missing title and description
Comment #16
david.qdoscc commentedComment #24
acbramley commentedThis came up as part of the daily bug smash triage.
Is this still reproducible on the latest version of Drupal core? If so, can we update the IS with the steps?
Comment #26
smustgrave commentedWanted to follow up one more time if steps can be provided.
Comment #27
smustgrave commentedSince there's been no follow up and was followed up twice going to close out. If still an issue in D11 lets re-open
Thanks.