Use interface language on the add URL alias form

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Can we add a simple test assertion for this.

I was looking into whether the work here could help resolve #2484411: Manual path aliases are not the same as aliases on the node form on single-language sites → by ensuring new aliases were created in the same language on the standalone path creation form, but I noticed that the current approach overrides the language when editing any existing path alias entity (which might already have a specific language). I think this should only be about setting the default initial value on creating an alias entity? So I've pushed a fix for that.

I've also made it respect the language settings configured at /admin/config/regional/content-language which allows choosing what the default language for aliases should be (which itself defaults to the site language), so that this is actually configurable too.

Hi, I have added test case to validate the path alias functionality across language switches. This test verify that the correct language is selected in the UI when creating aliases for nodes in different languages, ensuring users can easily access the aliases based on their current language.

Please review the changes, and let me know if any further adjustments are needed. I appreciate any feedback or suggestions for improvements.

Thanks!

I've run the test-only pipeline job, which passed - i.e. your test passes without the changes. The test is simply checking that aliases work for nodes that happen to be called 'English node' or 'French node'; it's not checking that the aliases are created in an appropriate language for appropriate node translations. I also believe the monolingual scenario should be covered: aliases should be created in the same language on the standalone alias form as when creating them via the node add/edit form (i.e. the site default language for both; whereas the standalone alias form creates aliases as language-neutral without these changes).

@james.williams

I also believe the monolingual scenario should be covered:

But that is what issue #2484411 is about is it not? So should be fixed in that issue?
At #8 @smustgrave requested a 'simple test'. Is that not now in place?
At #9 you linked #2484411. It will help if the issue description is filled out especially the 'steps to reproduce'. But if the test coverage covers this issue then perhaps #2484411 can be dealt with as a child issue. Under it the test coverage can be extended.

I interpret the current ticket description as being about ensuring that the right language is selected for creating aliases in, from the URL alias form. At the moment, the alias form creates aliases as Language Neutral (shown as 'Not specified', see the screenshot I've added for the issue summary). So regardless of whether a site is monolingual or multilingual, aliases are not currently created in the interface language. I believe that is what a valid test should show.

Normally a test should fail to show an expectation isn't being matched, and then pass when run alongside a fix. At the moment, the test is passing against core itself, because it is not checking the unexpected behaviour. Yes, perhaps that's just because the issue wasn't clear enough - so I've updated the steps to reproduce, including that screenshot.

Another way of testing could be to check whether an alias added through the standalone URL alias form is given the same language as an alias created from a node creation form. At the moment; they would be different. That is the angle that #2484411: Manual path aliases are not the same as aliases on the node form on single-language sites → looks at this problem from. I believe both of these issues can be solved with the solution that I added in MR !8175 for this issue.

My MR changes did go a bit beyond the basic request, to respect the configurable language content settings for more flexibility for different use cases.

@james.williams Thank you, the new 'steps to reproduce' make things nice and clear. It appears that the test should be quite simple and specific: the default setting of one particular field in the form.

Another way of testing could be to check whether an alias added through the standalone URL alias form is given the same language as an alias created from a node creation form. At the moment; they would be different. That is the angle that #2484411: Manual path aliases are not the same as aliases on the node form on single-language sites looks at this problem from. I believe both of these issues can be solved with the solution that I added in MR !8175 for this issue.

This all sounds good to me.