Language-specific aliases only work with url-based language negotiation

So I'm guessing that you're browsing the site in a non-English language when this is happening? Also please confirm the correct version of Pathauto you are using - 6.x-1.2 is fairly old.

Maybe the locale module is not completely uninstalled.Happened with me (on a module i dont remember) i forgot to uncheck it from the list of modules and deleted it

I am having a similar issue, it seems that when Locale is enabled, but a node type is not enabled for translation, then i get this error. If i enable it for translation and set the nodes for neutral the error seems to go away, I have not tested it with a set language as of yet.

Okay setting a node to anything but Language Neutral causes issues.

I am also experiencing this in D7.

It seems only for content types I created after enabling locale.

Here is a proposed solution #1534600: URL Alias leading to Page Not Found on multilingual site

#1534600: URL Alias leading to Page Not Found on multilingual site is not a solution. That's a workaround you'd have to repeat each time after creating new content. The issue still remains. Alias that has language set to something different than "any" or site default does not work and leads to "page not found".

This is not related to pathauto module. If you create alias manually the behaviour is the same.

I think that this happens because drupal_lookup_path from path.inc uses global $language_url variable to get current language. But the problem is that $language_url is set to default language if language was not set via url. This is wrong because language could be selected through user preferences or browser language.

The real problem is that url alias should work always regardless of selected language!

Workaround for this is to alter drupal_lookup_path queries to search url_alias table for entries that match provided alias but not necessarily match language that is provided by $language_url variable. The goal is to always return alias source if it exists regardless of selected language.

@SiliconMind would you be able to provide either steps to reproduce from a clean core install or even better an extension to the existing path alias tests which demonstrates this?

Steps to reproduce:

1. Add second language (for example ES): /admin/config/regional/language
2. Disable language selection by URL and enable selection by Session (you can enable Browser and User options to. It doesn't matter.): admin/config/regional/language/configure
3. Create a node and:
   • set it's language to English
   • create an alias "aliased-node"
4. Switch language to ES using "request switch": /?language=es
5. Go to aliased path - you will get 404.

http://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.

The summary may need to be updated with information from comments.

Problem/Motivation

Elaborating on the steps to reproduce in D7 and D8 (based on the thread above):
o D7: enable the core Locale and Content Translation modules; D8: enable the core Language and Content Translation modules

o D7/D8: visit admin/config/regional/language, press "Add language" and select "Spanish" from the drop-down

o D7/D8: press the "Detection and Selection" tab aka as admin/config/regional/language/configure

o D7/D8 In the column of tick boxes make sure that Detection Method URL is UNticked while Detection Method Session is TICKED; leave the remaining tickboxes set to what they are

o D7: on the content type settings page for Article admin/structure/types/manage/article tick the Publishing options tab and then the Enabled radio button under "Multilingual support"; D8: visit /admin/config/regional/content-language and tick the Content box (Custom Language Settings) as well as the Article box in the Translatable column.

o D7/D8 add content: node/add/article, specify an alias under "URL path settings" and in the Language drop-down select "English". Save

o D7/D8: Verify that you can View the page via the URL alias

o D7/D8 Edit the page, changing the language selector to Spanish. Save.

You can now no longer View the page via its URL alias, although node/... still works.

Is this the problem or a feature??

Proposed resolution

(Description of the proposed solution, the rationale behind it, and workarounds for people who cannot use the patch.)

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

API changes

(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate.)

Related Issues

(A list of related issues.)

Original report by [username]

(Text of the original report, for legacy issues whose initial post was not the issue summary. Use rarely.)

Using the steps in #13 in a clean install of D8, after publishing the initial English article:

Stay logged in and go to the article, you get a Translations tab
Within the Translations panel you get a listing of translations
English is shown as having the translation {title of article} and the status "Published"
Spanish is shown as having the translation "n/a" and status "Not translated"

The path of the original article is /path-set-by-author

After changing the language to Spanish:

English is shown as having the translation {title of article} and the status "Not published"
Spanish is shown as having the translation {title of article} and the status "Published"

The path of the article republished in Spanish is /es/path-set-by-author
The original path of the original article /path-set-by-author is now 404.

Screen shots attached.

@ge, #14: "The original path of the original article /path-set-by-author is now 404."

Sorry am new to I18n and stuff.... so is the above observation indeed the bug? Or is this how we want it to operate?
If it is a bug, then it is a bug in both D7 and D8 and we should update the title to something more descriptive.

Agreed, I am likewise unsure whether the problem lies in the path getting changed or the content author not being notified of the change. The effect is that the original article at the original path appears to the content author to get silently de-published so it goes 404. Added this info to the issue summary so someone with more knowledge on this point can evaluate the appropriate direction to go.

Add detail and (success criteria for) proposed resolution

Starting work on an issue summary.

Merging comments into Issue Summary.

Testing links

Saving a version.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated links.

This is just an implementation to correct the URL looking-up.

/**
 * Implements hook_url_inbound_alter().
 */
function mymodule_url_inbound_alter(&$path, $original_path, $path_language) {
  global $language, $language_url;
  /**
   * This is a hacked.
   * @see: https://drupal.org/node/1125428
   */
  if (empty($path_language)
    && $original_path == $path
    && $language->language != $language_url->language
    && $language->provider != $language_url->provider) {

    $path = db_select('url_alias', 'u')
      ->fields('u', array('source'))
      ->condition('alias', $original_path)
      ->condition('language', array($language->language, LANGUAGE_NONE))
      ->orderBy('language', 'ASC')
      ->orderBy('pid', 'DESC')
      ->execute()
      ->fetchField();
  }
}

drupal_lookup_path() was removed, and the underlying logic substantially refactored in #1269742: Make path lookup code into a pluggable class. Is this an issue in 8.x anymore at all? If not, it should be bumped back to 7.x.

Notes from triage with @metzlerd

• Updated title to be core version-agnostic
• Bug is still present: Reproduced the issue on a local environment in Drupal 8.
• Related issues found and linked in summary
• Added beta evaluation

Related issues links moved to sidebar.

(Saving proposed issue credit for discussion and triage participants at LA.)

Working on this as part of #FLDC17

Confirming that the bug still exists on Drupal 8.4.x-dev clean install, and can be reproduced by following the steps that are written in the summary.
Needs an initial patch to fix this bug.

Hi @shaal

I can't reproduce in 8.2.6. Do you what is the change? Can you explain steps to reproduce it?

Thanks

We're seeing a variation of this behavior on Drupal 8.2.6 that I'm pretty sure is caused by this bug.

Basically, on a site with multiple translations, repeatedly editing and saving a translated node with path aliases defined causes the aliases to be sporadically lost.

* Set path aliases to be translatable
* Create a translation for a node
* Add a path alias if it doesn't exist and save the page
* Note that node translation is correctly aliased in the URL
* Edit node again and save without making any changes
* Path alias has mysteriously vanished

Setting the path aliases to not be translated results in an even worse bug, the path doesn't take effect at all in that case. Possibly due to #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations

I discussed this issue with @xjm, @cottser, @catch, @alexpott and @lauriii. We agreed this should be increased to critical priority because data is disappearing.

(edited)

Sorry, we agreed this is actually critical.

I just read the steps in the issue summary, and they looked like a duplicate of #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations at first, but they're not:

The result after I followed the steps was I had a Danish node, and a record in the URL alias table like this:

3 | /node/2 | /hello | da    

That looks fine to me, exactly as expected.

The URL alias is rendered correctly on admin/content, but I get a 404 when trying to visit it. The alias table is fine, so this could be an issue with the incoming path processor or session language negotiation, but it's not data loss.

I wasn't able to reproduce the issue with the steps in #27 at all. That means I'm pretty sure this is closer to #2802403: Combination of language negotiation and path aliasing can cause a corrupted route cache, 404s than a data issue/form/translation issue.

What if we detect the language in the path alias processor?
See the patch.

ofcourse tests failed, because the constructor is now different. I can fix tests, but please verify the approach first.

The tests fail because the constructor is wrong, not just different. You need to type hint on the interface, not on the actual class. I'd suggest try that and then we'll see how much test fails are remaining.

Fixed the interface type hint.

@a.milkovsky: I don't think your change makes a difference. \Drupal\Core\Path\AliasManager::getPathByAlias() already falls back to the current language() if none is explicitly provided.

I've been debugging this as well, and the fix that is working for me is adding the language to the RouteProvider cache.

The easiest way to reproduce this is a site with per-language domains, given example.de and example.fr, where only the de site has a working alias/page on "/path".

When you visit example.fr/path first you get a 404, when you then visit example.de/path you also get a 404 even though it exists, because we have a cache hit on \Drupal\Core\Routing\RouteProvider::getRouteCollectionForRequest() as the path and query arguments are identical.

In a way even more interesting is that if you do example.de/path first (which works) and then visit example.fr/path then that resolves too. So if those were supposed to be different pages, then you might end up with a completely weird page ;)

Also, there have been tons of different problems been mixed up here already, whatever was the inital report in D6/D7 has nothing to do with this specific problem that I'm seeing.

Will try to add some tests, while not possible for multi-domain (at least not as web test), maybe we can do this with user/session negotiation.

This should fix those fails.

Ok, so here is a test, but I actually had to kind of add a workaround for the poblem described here to be able to test my bugfix, so I think my issues is related but not really the same.

I tried to write a test that uses session negotiation to reproduce my problem, but it didn't happen by default. Turns out that was because the language_url negotiation is fixed to language-url. Only by manually setting that to also use session negotiation I was able to reproduce my specific problem of it being cached incorrectly.

I now also see the difference between #37 and HEAD, the patch there uses the language_interface type and by-passes the fallback in AliasStorage. But if that's the conclusion then we should IMHO just change the AliasManager to do that too, which leads to:

The big question here is what exactly is the use case/reason for the language_url to even exist. Right now it simply doesn't make sense if the negotiation doesn't match between content/url, because the user is creating aliases for *content* and expects those to match the URL alias language.

Anyway, for now, here is a test that is failing/passing with my fix.

I suspect my fix is more related to #2802403: Combination of language negotiation and path aliasing can cause a corrupted route cache, 404s (the two issues are closed related anyway)

I think this a good change, and we really understand that this is needed. There was some other issue talking about adding generic cache context support, but I think for now this is the right minimal change.

+++ b/core/lib/Drupal/Core/Routing/RouteProvider.php
@@ -147,7 +159,8 @@ public function __construct(Connection $connection, StateInterface $state, Curre
+    $langcode = $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_URL)->getId();
+    $cid = 'route:' . $langcode . ':' . $request->getPathInfo() . ':' . $request->getQueryString();

Should we add a comment, why we need to have the language vary by langcode?

Ok, I moved my patch over to #2802403: Combination of language negotiation and path aliasing can cause a corrupted route cache, 404s. So back to the drawing board here.

As far as I see, the only "problem" here is that url language type is by default hardcoded to URL negotiation (path or domain) and does not consider session, which is kind of implied by its name.

The bigger question is what exactly the point of the url language type is and I'm honestly unsure. Discussed a bit with @plach and he said "IIRC the idea is that you may want to have a language for UI or content different from the one carried by the current URL". But I don't understand what a real-world use case for that would be to be honest. And @plach could also not come up with a specific scenario but it was also pretty late in the night for both of us :)

The reality IMHO is that the url language *is* the content language. While that is not the case with the default fallback, it is in a lot of places where we explicitly specify the language of a URL. For example on /admin/content, that will always use the translation language of the node for the link. And in this scenario, with only session negotiation, that will lead to a 404.

*But* there is no data loss, the aliases are there. The explanation about changing language on the node is I think only related to the fact that the this then results in an alias that is not in the default language. It doesn't matter if it's set initially or changed later. There are aliases, they're simply not considered because the url language is never $non-default-langcode.

Considering that, I think the current issue title is misleading, my suggestion would be "Language-specific aliases only work with url-based language negotiation".

This issue existed in some form since 2011, that's IMHO another indication that it simply can't be *that* critical ;)

Therefore I would suggest that this is changed back to major issue.

That all said, thinking about a possible solution...

a) We add language-content as a fallback negotiation to the language_url type. So that if url is not enabled at all, it falls back to the content language. We discussed that a bit last night. *But*, any link that explicitly uses the content/entity language when generating a URL (and I think toUrl() on an entity should actually do that by default) will still result in a broken URL because it will result in a link that uses the alias but does *not* have a prefix.

b) If we completely deprecate language_url and stop using it then we still have a problem. The alias will now work, but admin/content shows me the original (in my currently active language) as just /original-alias and the translation as /spanish-alias. The /spanish-alias will now still be a 404 because the link doesn't know that it should be in loaded with the spanish language. for session negotiation, that could be fixed by adding ?language=es to the URL, but that would change your persisted language configuration. And for a language preference stored in your user, you can't even do that on a link. Thinking about this, I suspect this was one of the reasons why we have the language_url language type although we can see that it doesn't really solve the problem because using any non-url based language negotiation method in reality means that there is no way to view an page/entity in a different language.

c) cry and give up...

d) Remove all non-url based language language negotiation methods ;)

e) What actually might work but I haven't fully thought it through yet is when interface and content have different negotiations and you allow something like session or user preference based negotiation only for interface language but content must use path/domain. Then you can have the website in a fixed language, but you're able to view and edit content in any language you want. But that still means that it would be enough to have interface and content language types. It also means that only very few language negotiation configurations really make sense and work. But our current UI allows about a million different variations but most of them actually just allow you to misconfigure it and break some cases. Maybe we should reconsider that generic UI and just offer a few specific options that actually *work*? With a way to override it maybe, in case someone wants to do something stupi... different :)

"The bigger question is what exactly the point of the url language type is and I'm honestly unsure. Discussed a bit with @plach and he said "IIRC the idea is that you may want to have a language for UI or content different from the one carried by the current URL". But I don't understand what a real-world use case for that would be to be honest. And @plach could also not come up with a specific scenario but it was also pretty late in the night for both of us :)"

The most common use-case for overriding content language setting is dead simple: moderators/editors/admins want to be able to moderate ALL CONTENT under a single domain, because separate domains require separate login sessions and Drupal has no OOB support for sharing sessions between multiple domains. User sessions are a problem when language negotiation is done at the domain level.

I think the issue is becoming more critical now that Drupal is considered to have multi-language support OOB and not every module has to be hacked in one way or another to provide support. People are less afraid to use it and more prone to running into problems with it.

The patch does not work for me.
As I understand
/core/core.services.yml patch is not needed
/core/lib/Drupal/Core/Routing/RouteProvider.php partially
/core/modules/language/tests/src/Functional/LanguageSwitchingTest.php need
/core/tests/Drupal/KernelTests/Core/Routing/RouteProviderTest.php not needed

I had a similar issue in Drupal 7 + pathauto, and I found out the problem was with the missing language prepend.
I tried patching core and went with the idea from #17, but all it resulted in was an endless loop of redirects.
Ended up fixing with a hack-ish thing, that simply forces all content to have a language prepend:

function mymodule_path_update(&$path) {
  $language = $path['language'];
  $defaultLanguage = language_default();
  $defaultLanguage = isset($defaultLanguage->language) ? $defaultLanguage->language : 'en'; // Fallback to english.
  if (isset($language) && $language !== $defaultLanguage && $language !== 'und') {
    $pos = strpos($path['alias'], $language . '/');
    if ($pos === FALSE) {
      $path['alias'] = ltrim($path['alias'], '/');
      $path['alias'] = $language . '/' . $path['alias'];
      path_save($path);
    }
  }
}

I am posting this as I work on the issue, so this might have a glaring flaw that I haven't found yet.

Also keep in mind these could be specific to my setup.

As mentioned at #2666628-11: Language-aware aliases are broken with anything but path language negotiation, a workaround to this:

1. make the language_url configurable by manually editing the 'language.types' config entry, adding 'language_url' to the configurable section as follows:
   

         1 all:
         2   - language_interface
         3   - language_content
         4   - language_url
         5 configurable:
         6   - language_interface
         7   - language_url
   ...
   

2. apply patch from #2824086-9: URL language detection has missing title and description
3. go to Configuration -> Regional and language -> Languages ( /admin/config/regional/language/detection ). The URL language detection is now configurable, adjust to match the interface text selection

Now that path alias is an entity can we quickly add test to make sure this is still an issue? Is #43 test only patch correct interpretation of the bug?

Moving this back to major. This is really a problem with us allowing people to configure a site such that it doesn't work as expected, the individual pieces are working as they should.

IMO session language negotiation is the bug and we should just deprecate it, then remove it entirely, although #817114: Deprecate the session language detection method was marked won't fix nine and a half years ago.

Marking #1294946: Language detection based on session doesn't work with URL aliases as duplicate.

Hi,

just for information, i needed to apply steps describe in #52 for resolve problem with translated aliases.

I use a custom language negotiation based on proxy vars due to a complex multi-language proxy configuration (that can't work with default url / domain negotiation).
So, in my case, it really matters to be able to edit configuration for LanguageInterface::TYPE_URL.

Thanks,

@manuel.adan

Be aware,

like mention above, i use #52 instruction to configure my custom language negotiation for generate good alias (for example in language switcher). But, when in enable a new module (or disable) system reset url language negotiation to ->url.

Did you experience such problem ?

Thanks.

I checked it on 3 different sites with Drupal versions mentioned below, And the issue still exists:

• 9.0.5
• 8.9.3
• 8.8.4

Steps in #13 mentioned this being the problem with language detection method of session, But I think its beyond that and is rather true of other language detection methods as well.

Assumption: The default site language is English.

Steps to reproduce:

1. Enable language & content_translation modules
2. Go to the path admin/config/regional/language. Add Spanish & French languages.
3. Go to the path /admin/config/regional/language/detection and ensure your language detection and selection methods for Interface text language detection and Content language detection are set to URL. [I don't this step matters and the issue exists for other detection and selection methods too. I have mentioned this step as I tested the whole thing with this config. See attached screenshot for the config.]
4. Create an content type such that its translatable(See attached screenshot for content type configuration)
5. Add content in English and add URL alias
6. Translate the English node to Spanish such that it also has alias. [This step is optional]
7. Now, Change the language of English node to French. Without doing anything to URL alias, Save the node.
8. Edit the newly saved node and You will notice that the URL Alias is no longer present on it.

Summary: Changing the language of source translation is causing the node to loose its URL alias.

An update on #52 in response to #58, the locked flag must be removed from the URL language type to prevent the settings being reset on module (un)installation.

Instead of patching core with #2824086-9: URL language detection has missing title and description, the URL language type can be altered in a hook_language_type_info_alter() implementation as follows:

/**
 * Implements hook_language_type_info_alter().
 */
function MY_CUSTOM_MODULE_language_types_info_alter(array &$language_types) {
  // Make URL language negotiation configurable by removing the 'locked'
  // flag. Work-around until #1125428 // #2824086 // #2666628 from core
  // solved.
  $language_types[LanguageInterface::TYPE_URL]['locked'] = FALSE;
  unset($language_types[LanguageInterface::TYPE_URL]['fixed']);

  // Set name and description, not provided by core since this is considered
  // as internal.
  $language_types[LanguageInterface::TYPE_URL]['name'] = t('URL');
  $language_types[LanguageInterface::TYPE_URL]['description'] = t('Order of language detection methods for URLs. If a language prefix is configured for the detected language, it will be added to the URL.');
}

I ran into a similar situation today, but with user negotiation instead of session.

Steps to reproduce:

1. Do a site install with standard profile
2. Enable language module (content_translation is disabled)
3. Go to admin/config/regional/language. Add a language - I used german for testing - and set this language as default.
4. Go to admin/config/regional/language/detection untick URL and and select User instead
5. Click Save settings
6. Create article node and give it an URL alias

Expected result: The node is accessible with the given alias.
Actual result: You get a "Page not found" on the alias.

The funky thing is, you can fix this, at least for the default language, when you got to the configuration form of the disabled "URL language detection configuration" (admin/config/regional/language/detection/url) and remove the path prefix of the default language.

Now you can actually access the page with the alias. I would have assumed, that the configuration of a disabled language detection should not have any impact.

Here's the simplest tests to reproduce this bug without changing default languages or doing anything too surprising.

1. Install standard in English
2. Install locale and language
3. Add the German language
4. On admin/config/regional/language/detection - disable URL detection
5. On admin/config/regional/content-language - enable the language selector on the content types
6. Create a node with an alias and select German as the language.

This will create an alias with the language 'de' but the alias does not work and leads to a 404. There is no way for the site to determine a \Drupal\Core\Language\LanguageInterface::TYPE_URL with this set up.

The question is what should we do here? @Berdir's comment in #46 lays out some of the options. I think the key statement is

But our current UI allows about a million different variations but most of them actually just allow you to misconfigure it and break some cases. Maybe we should reconsider that generic UI and just offer a few specific options that actually *work*?

FWIW this issue get's even worse if you change your default language - see #3262873: "Content monolingual" sites with multiple interface translations are very difficult to set up

Here's a fix for this issue. It allows the AliasRepository to fallback to any language if the URL negotiation is not enabled because there's no way we can use path aliases to negotiate language in this case - so that feels reasonable. I also explored setting all path alias' langcode to UND when this is the case but that haas the downside of not working as expected if you turn off URL negotiation after creating some content.

Here's an alternate implementation that ensure new aliases have the UND language when created and url language negotiation is off. I think this fix needs further work to ensure that if URL language negotiation is disabled and the aliases in a language other than the default language or UND we display a warning that they will not work and also on the alias edit form to disable the language selector if the alias is a new alias and URL language negotiation is disabled.

I think the test fails indicate there are problems with setting the langcode in presave or even in the create hook - because we have stuff that sets the langcode outside. The default value for langcode of path aliases in already UND so I think we have to fix the callers to use the correct default depending on langcode configuration. So we need to fix the PathItem field.

Closed #3020627: Creating a content with another language different from the official site one displays a 404 error using the alias. as a duplicate, adding credit.

The difference with that issue is what is ticked on the detection page,

And I tested the patch in #71 and it did not work for me.

alexpott asked in Slack for me to confirm my results. I retest, starting from a drush D10 standard install. I followed the steps in the IS, except the second language was Italian. And reproduced the bug.

1. Then I applied that patch
2. navigating to the alias, and got page not found.
3. cleared cache
4. navigating to the alias, and got page not found.
5. made a new node, in English with a new alias, save
6. navigating to the alias works
7. edit node and save as Italian
8. navigating to the alias works!

So, the patch does work for new nodes. :-)

@quietone - ah okay - I see - yep exisiting content is tricky. I came up with a solution that would work for existing content in #67 but this broken some pretty explicit testing of expectations. For example, \Drupal\Tests\path\Functional\PathLanguageTest::testAliasTranslation() has the following code:

    // Disable URL language negotiation.
    $edit = ['language_interface[enabled][language-url]' => FALSE];
    $this->drupalGet('admin/config/regional/language/detection');
    $this->submitForm($edit, 'Save settings');

    // Check that the English alias still works.
    $this->drupalGet($english_alias);
    $this->assertSession()->pageTextContains($english_node_french_translation->body->value);

    // Check that the French alias is not available. We check the unprefixed
    // alias because we disabled URL language negotiation above. In this
    // situation only aliases in the default language and language neutral ones
    // should keep working.
    $this->drupalGet($french_alias);
    $this->assertSession()->statusCodeEquals(404);

Which is almost exactly your steps for existing content.

The reason I went from #67 to #69 is this. If you create aliased content with URL language negotiation on the content is available at langcode/alias. With #67 it would suddenly be available at /alias which does not feel right.

However as @quietone one as pointed out if you then edit the translation and save it the code in #69 doesn't update the alias to have a langcode of UND... essentially you can into a spot where you can never fix the alias on the node edit for so that's not correct.

We could consider updating the path alias langcode to UND if URL negotiation is disabled. I think might be the best fix.

We could consider updating the path alias langcode to UND if URL negotiation is disabled. I think might be the best fix.

This however will result in the following behaviour if you do the following:

1. Install Drupal with the Language and Content Translation modules
2. visit admin/config/regional/language, press "Add language" and select "Spanish" from the drop-down
3. add content: node/add/article, specify an alias under "URL path settings" and in the Language drop-down select "Spanish". Save
4. The alias will work with the language prefix
5. visit admin/config/regional/language/configure and disable Detection Method URL
6. The alias will NOT work (with or without the language prefix)
7. Edit and save the spanish node without making a change
8. The alias will work without the language prefix

Is this the correct behaviour? Not sure.

I think one thing I can say is the current behaviour in HEAD is the worst of all possible choices and #67 represents a big improvement for a site with multiple languages and Detection Method URL disabled. One possible way forward is to delete aliases in languages other than the default or UND if the user disables the URL detection method after warning the user. Or we could disable the ability to disable in this case and tell the user to remove the language specific aliases first.

What do people think?

So here's some work on #76. It prevents a user disabling the language URL method when there are aliases not in the default language.

However while working on this I was trying to explain why I was only targeting the interface language type. And I really couldn't explain it because in AliasManager it's always doing LanguageInterface::TYPE_URL - it turns out that \Drupal\language\HttpKernel\PathProcessorLanguage::initProcessors() is what registered language negotiators for path processing and that uses \Drupal\Core\Language\LanguageManagerInterface::getLanguageTypes() which only returns the configurable processors. But is that correct shouldn't we also/only be doing TYPE_URL here? Let's see what falls if we do. If I make this change then multilingual aliases keep working even if you disable language url from language interface detection. However the interface stays in the default language. Which is pretty much what I think should happen. Thoughts...

Here's the alternate approach with tests fixed... probably need some more explanation.

The fails for #78 were randoms caused by JS and the theme blocks stuff.

Triggering for 10.1

Tried testing #78

Drupal 10.1 with a standard install
Enabled a 2nd language
Checked "Language from a request/session parameter"
Unchecked "Language from the URL (Path prefix or domain)"
Enabled translations for Articles

Created an Article with alias /english
Edited the Article by changing language to my 2nd language
Save the page and the URL is node/1
Go back into edit and my alias is gone.
Adding it back
I still can't go to /english

Let me know if I tested wrong.

I just ran into this problem on a Drupal 9 site as follows:

• Install Drupal in English
• Enable language module
• Add Afrikaans
• For article content type, enable Show language selector on create and edit pages
• Create article node in English with alias and alias works as expected
• Create article node in Afrikaans with an alias and alias does not work, only node/123

Added the patch from #78 and then resaved my Afrikaans node and now it's showing the page as /af/node79aliasaf. Note that I did have to resave the node... just applying the patch wasn't enough. Do we need an update hook?

This doesn't make sense to me because I have path prefix language negotiation disabled. IMO, if that's disabled, it should just allow the alias as is without a path prefix.

That said, I haven't read all the comments above :)

UPDATE: Also tested with "Not specified" and "Not applicable" and the former works without the patch and the later does not (same 404 behavior as non-default-language).

Testing on my local and try to fix.

I also got the same results as #87

#88 seems a different problem, if we look at steps to reproduce we want to edit an article and change the language to non-default. In comment #88 we are just creating an article with non default language which is also a bug, but it is not what this issue is talking about.
#3259403: Aliases are lost when entity language is changed from the edit form seems duplicate of this.
I am trying to fix both the Problems in this issue, so we can close the other one.

In my opinion, there are two problems

1. Saving an article with non-default language with URL alias doesn't work
2. Editing an article and changing the language to non default will lose the saved URL alias, this was described in steps-to-reproduce and also #3259403: Aliases are lost when entity language is changed from the edit form

This should fix both the problems.

The first issue from my comment #92 is not a bug it's designed to work like that, see #347265: URL aliases not working for content not in default language.

This fixes the problem when we try to edit the language of an existing node.

Verified the issue described in the IS.

Ran the tests in #95 without the fix and it correctly failed

Behat\Mink\Exception\ResponseTextException : The text "aUpF5Ne1CVk1V1UzpXYkXGjVc4bVyVey" was not found anywhere in the text of the current page.

Think this is good for committer review.

The bug fix fixed seems to be very different to what the issue title and summary seem to be talking about? the closed issue #3259403: Aliases are lost when entity language is changed from the edit form seems a better match for that?

I agree that the title does not match the fix, but we have already closed #3259403: Aliases are lost when entity language is changed from the edit form, and the issue summary for this is already the same as of the duplicate, so we can just change the title of this issue and continue here?

I am doing triage on the core RTBC queue.

Thanks to everyone for working on this tricky issue.

I read the issue summary. There are steps to reproduce and a proposed resolution, which helps reviewers. However, the proposed resolution refers to drupal_loookup_path which is no longer in core. And it appears the resolution is coming from comment #8, which is 10 years old. The remaining task list has 6 items and there is no indication that they have been resolved. And in the User Interface section there seems to be more tasks. It is rather confusing. Therefor, I am tagging for an issue summary update and setting to needs work.

I read through the comments to determine if there is any task not completed and if the remaining tasks were resolved. There is certainly a lot of discussion here of the problem and possible solutions, all of which should have been summarized in the issue summary. But I fail to see an agreement on the solution. Maybe I missed it? And one patch from here moved to another issue and the latest one is not solving the problem as stated in the Issue Summary.

It was good to find an answer to "what is the use case/reason for the language_url to even exist" (#43). Which is "moderators/editors/admins want to be able to moderate ALL CONTENT under a single domain, because separate domains require separate login sessions and Drupal has no OOB support for sharing sessions between multiple domains. User sessions are a problem when language negotiation is done at the domain level." (#47)

I tested this on Drupal 11.x, using the steps in the Issue Summary. I was able to reproduce the problem. I applied the patch and retested. There was no change. I cleared cache and retested. Again no change. That confirms, for me, that patch #95 is solving the problem in #88 which they say is different. Because this was not tested before setting to RTBC I added the tag for manual testing.

And since the patch in #95 is not fixing the problem in the issue summary, that should be moved to a separate issue. Can someone take care of that?

Can we go ahead with #71 and make it work for existing content? I tried testing that the results are same as https://www.drupal.org/project/drupal/issues/1125428#comment-14492542

Hi, does #78 work for anyone? I went through the issue again and tried all the available solutions, only thing worked for me was #69 but that approach will only work for new nodes. Can someone try #78?

I made it compatible with Drupal 11.2.0-rc2

Adding triage credit per #28:

I discussed this issue with @xjm, @cottser, @catch, @alexpott and @lauriii.