If you don't want to translate your URL alias, the original URL alias won't work with your translations

In Drupal 9, with, or without this patch, translated URLs only work if you use an automatically generated URL.

If you create an english node, give it a manual URL and then translate the node, the translated node has a url of example.com/node/

@Greg Boggs: I could not reproduce the issue you report. Used a clean 9.5.9 install on simplytest.me and tried both Drupal core alone, as well as with pathauto (different instances).

Testing results:

Drupal core 9.5.9

1. Install: language, content translation
2. Add 'de' language
3. Enable translation for Article bundle and url alias field
4. Create article, en langcode, manual alias: article loads using alias
5. Added 'de' translation, keep manual alias unchanged, save: article loads using lang-prefixed alias.

Drupal core 9.5.9 + pathauto

1. Install: language, content translation, pathauto
2. Add 'de' language
3. Create pathauto pattern for 'article' bundle
4. Enable translation for Article bundle and url alias field
5. Create article, en langcode, manual alias: article loads using alias
6. Added 'de' translation, keep manual alias unchanged, save: article loads using lang-prefixed alias.

The goal is to not enable url translation so your URLs should be:

example.com/hello
example.com/es/hello

It sounds like to me you got:

example.com/hello
example.com/es/hola

I can get it all to work as long as an editor always manually enters the URL and uses the checkbox. But, as soon as the default automatically generated alias is used, I cannot.

I was trying to reproduce the problem from steps to reproduce, can someone confirm if they can do step 5: Within Article, uncheck the URL alias field for Drupal 11.x? I am not able to do so because once we enable translation for article it gets enabled for all the fields and if we try to save admin/config/regional/content-language with URL alias for article unchecked it does not get saved.

Need some help with #167 🐛 If you don't want to translate your URL alias, the original URL alias won't work with your translations Needs work

Can the steps be updated please.

Followed them but going to es/my-alias took me to the Spanish translation. So I didn't have the issue.

I also cannot reproduce this anymore. I think there's a good chance that this was fixed by #2336597: Convert path aliases to full featured entities → (or at least improved). If there's a set of customizations required to trigger this, it would be great if the steps in the issue summary would be updated with those.

I have not tested this in two months.

Steps to reproduce:

1. Enable content translation and language detection based on URL and add the Spanish language.
2. Enable all the article translation options except URL.
3. Enable Pathauto with the default path for articles.
4. Create an English article with the title of Hello and the automatic path of example.com/hello
5. Translate the English article to Spanish with a title of Hola. Do not change the path.

The Spanish article should have a path of example.com/es/hello

In fact, the Spanish article will have a path of example.com/es/hola thus translating the path even though URL is supposed to be untranslated.

to work around this, the editor can manually set the url on the spanish translation back to /hello thus setting the URL back to example.com/es/hello. But, if the automatic URL is used, the url is translated based on the spanish title rather than using the untranslated english path.

I was able to reproduce this with the steps in #171. The key step is to not enable translation for URL alias field when enabling translation for the content type. 👍

After applying patch #161 for 11.x in MR, url alias(admin/config/search/path) with Language None is created.

Updated issue summary after also confirming the issue following steps in 171

Applying the MR does resolve the issue for me.

Some thoughts on this, I didn't look at everything in depth, but posted a few comments on the test as well, pretty sure that's not quite ready and needs some cleanup, it's obvious that parts of it are very old.

* We need to be careful about existing sites here, as this changes the behavior for them suddenly. Until now, the translation setting on this field didn't really do anything and there are two possible cases to consider here:
** Sites that accidentally have this configured but don't actually want this behavior. There's not much we can do about that, but we should have a change record and probably also a release snippet to tell users to review their alias field translation setting and enable it if they want to have per-language aliases.
** Sites that would like to have this behavior, tried it, are not using this patch but kept it as that. That's fine, it will start to work for them now. We do however need to make sure that existing aliases continue to work. Specifically, that means the alias lookup should be the language or UND, not either or (exclusive OR) the other depending on the setting. Maybe that's already covered in tests, but we should do a manual test as well. Either by creating content first then applying the patch, or changing the translation setting.
* There is a very strange and unfortunate module exists check that was added in #121 and was never talked about again later. Hardcoded module exists checks are really not nice. If it's needed, then other modules might need it too and won't be able to add the same workaround. Or it's not needed and we should instead fix some tests like many other tests were adjusted as well. Can we remove that snippet and see what exactly ails and look into that?
* Not a problem, just a note. There's a similar but different use case of alias fallbacks: 🐛 Allow altering of the language fallback for path aliases Needs review . The difference is that you can *optionally* have translated aliases if your content is translated, but if it's not then you want it to fall back to the alias of whatever language does exist. This is typically useful in combination with language fallbacks and regional/sub-languages, where not all content is expected to be translated. I think they are completely parallel and should not interfere, but make sure that your use case isn't actually that issue.
* This feature has also been asked for in the pathauto issue queue and I've pushed back/ignored it for now until core is consistent, now/once this actually happened, pathauto will need to be updated as well to correctly respect this setting as well.

Hi,

we also actually use the patch, but with the module language_neutral_aliases → .
We test a lot of variants, but it seems that only the module really works.

With the patch from #161 🐛 If you don't want to translate your URL alias, the original URL alias won't work with your translations Needs work alone it is not really working. We have
* Languages DE and EN
* Content is translatable, but url alias field is not translatable
* url alias pattern is set for all languages

But in result for new created content the path alias is set in database for DE language only. Not for "UND" (language neutral). So with no translation the path alias won't work with the second language.

If the path alias field is not translatable, the path alias should always be set to langcode UND, what the patch in our case did not do. Should it work like this?

With the module language_neutral_aliases the path aliases would be created as UND-aliases, so you can call it with other languages and get the default language not translated content. And of course the path alias stays always the same. (we use a alias pattern with node:source:title) so it is using always the original language title.

Bye
Martin

This issue will only work with manual aliases, not pathauto, that will need to be adressed separately in that module

Hi, I am bit confused between #171 and #180. #171 says we need to enable pathauto to reproduce this issue and #180 says we shouldn't.

What are the steps to reproduce without using pathauto for this issue, as suggested by @Berdir?

The STR include enabling Pathauto, but as @berdir points out in #180, this should be reproducible in vanilla core.
Can someone update the IS to explain how to reproduce this without Pathauto?

heh, that's my fault. Y'all are correct. I didn't realize drupal core generates aliases without pathauto because I've never seen a Drupal site without Pathauto. After looking at core without Pathauto We'll need a separate ticket in Pathauto for the Pathauto part.

So are the steps in #171 accurate minus the pathauto module?

Tried following #171 without pathauto and the steps aren't super clear. Do we need to manually set the alias now?

> Do we need to manually set the alias now?

Yes.

I have this issue in my D10 site — unable to use language-neutral alias on second+ language.
Which patch do I have to apply?

I updated the patch from #161 to work with Drupal 10.2.3. Only one small change within core/modules/jsonapi/tests/src/Functional/NodeTest.php