Unable to resolve path on node in other language than default

Thanks for the detailed bug. This will be a nice fix for multilingual sites.

Thanks for the patches! you rock!

I hope to review this soon.

Re-rolling #22 patch against 2.x branch.

Re-rolling #23 against 2.0.1 as 2.x-dev have some code changes which case the patch to fail for 2.0.1.

The issue reported is also applicable for the redirects. With the patch from #23, the redirects are being queried with language prefix in "RedirectPathTranslatorSubscriber", while in the db they are stored as path (without language prefix), this results in 404's.

#25 was not considering language-specific redirects.

Updating patch from #22, the getTranslationFromContext was not returning the languages that exist for the node, instead returning entity with the default language. This patch is for version 8.x-1.11

updated patch #22 with following patch

• 3111456-28.patch

Following is the diff between patch #22 and #28

• patch22_and_patch28_diff.txt

Added patch for problem in getTranslationFromContext is that the call to getFallbackCandidates does not return the languages that exist for the node, making it display just the default language. Added patches #28 for 8.x-1.11 and 2.x.

The patch is not considering that language prefix can be different than language id, e.g: I have 'en' as lang code and 'en-gb' as language prefix, which made the redirects not work for English.

Lang code has been introduced in the response but not yet in the tests.

Hi @bojan_dev,

I've done a brief test of this patch and it appears to be working as expected, and I can see the presence of updated automated tests. Can you specify what additional work you believe is still required?

removed accidental tag

Hi @Deciphered,

Functional-wise, I believe it's working fine, I'm using this patch on a high traffic production website.
I think we are complete, it would be nice if we could have a test for the following change: interdiff_31-32.txt. It's not required, but again it would be nice to have test coverage for this inconsistency between lang code and lang prefix.

Ran into a need for this fix today - patch applied cleanly and worked as expected.

Making a note of the need for additional tests on this one. If future me, or someone like future me could help out with that, would be great to get this one merged.

While testing I noticed that the entryPoint isn't correctly prefixed.

https://nginx.develop.demo-api-druxtjs-org.au2.amazee.io/router/translat...

I have opened a feature branch for this work and committed the latest patch with due credit.

I've added a fix for the issue I mentioned in #40.

The patch can be accessed from https://git.drupalcode.org/project/decoupled_router/-/merge_requests/5.diff, or via commit from the gitlab repo as required.

I agree that it's important to get full test coverage here if possible, I don't personally have the capacity or full understanding of the implications and usecases of using 'en-AU' or similar langcodes.

I do think that it's worth getting this merged in and making a followup story for the testing and inconsistencies with prefixes and langcodes, as in the meantime there will be greater access to multilingual support in decoupled builds.

It's also worth noting, and maybe updating, that the pathPrefix and basePath don't have the langcode prefix. Thoughts?

Hi @Deciphered,

The commit you made looks fine: https://git.drupalcode.org/project/decoupled_router/-/merge_requests/5/d...

Unfortunately I'm pretty jammed with work currently, otherwise I could help out, but for now making a separate issue for the test coverage makes sense.

I agree with your comment about basePath/pathPrefix; it should include the langcode prefix as well.

@Deciphered Thanks for the patch. I'll test and report back.

Agreed with you both on the langcode missing.

From the screenshot above, is there a reason individual and entryPoint have different langcode?

@shadcn, the different langcodes was the bug I reported @ #40, that one has been fixed, but I've also added the prefix to basePath and pathPrefix now:

I have created the follow-up issue @ https://www.drupal.org/project/decoupled_router/issues/3280591

All that is needed now is for someone to mark this issue RTBC and I will get it merged in and released.

Sorry for openening a new ticket, was not aware that they are related to each other. Made adjustments on this merge request here in this issue: https://www.drupal.org/project/decoupled_router/issues/3309874

Maybe somebody can feedback so it could eventually be proceed here.

Got some errors loading translated webform. I tweaked patch 34 to check if entity object has getTranslation method.

CI is failing, and it appears to be due to Drupal being run in a subdirectory?

https://www.drupal.org/pift-ci-job/2498799

I'm unsure of the cause of this, but it will need to be accounted for.

Could you also provide a test for when the prefix doesn't match the the langcode?

here is the updated patch for the new release 2.0.4
there an error in patch please refer #58

here is the updated patch.

Adding #51 again to the latest patch. can you please add that method exist call on your next patch file please?

if ($entity->hasTranslation($this->langcode) && method_exists($entity, 'getTranslation')) {

This fixes the webform entity because webform doesn't have getTranslation

Thanks!

Patch #59 with decoupled_router 2.0.4 works fine for me.
Thank you!

There is a problem with not being able to resolve the redirect and the current language, I expected that if you don't provide a language prefix, the current language will be used instead of only 'und'. This patch addresses the problem, but I think there will be slight problems if the prefix is also found in 'und' langcode. interdiff included.

I updated the test config so we can run tests on #61.

Looking forward to see an RTBC here.

The patch in #61 looks good apply in D10. But I did only see one issue with whitespaces warning throwing up. So created a new patch.

Also remove the Assigned to Unassigned so that people can find and review issue which are open to review.

The patch in #3111456-63: Unable to resolve path on node in other language than default seems to work fine, but RedirectPathTranslatorSubscriber does not correctly take into account the language of the selected redirect.

Attached a modified version of the patch and the interdiff

Issue reported by Druxt user:

it's failing when there's a URL like: "/fr/test?query=value"

Patch attached cleans additional query string from resolver.

Added the patch from Unable to resolve path on path with fragments in patch #66

#63 was the last green run. With #64 to support RedirectPathTranslatorSubscriber the tests started to fail, in what looks like a valid failure. #66 looks like a valid addition to the patch, but tests still fail. #66 looks irrelevant because it adds another issue into this patch.

Can someone confirm is the test failure is positive not?

Trying to clean up files.

Not sure why test is failing but #66 works great for me.

Updated patch #68

So this patch has all the fixes from

RouterPathTranslatorSubscriber uses wrong param when resolving the url #2
Unable to resolve path on path with fragments #2

and #66

@vhin0210 is there a reason to add the patches from #3411402: RouterPathTranslatorSubscriber uses wrong param when resolving the url and #3397122: Unable to resolve path on path with fragments to this?

Mixing issues generally makes the individual issues a lot more challenging to test, fix, and get merged by the maintainer.

Uploading re-rolled #63, as it was the last one with not failing tests.

Rebased the MR!11 with 2.x-dev and pushed minor changes.
Now gitlab pipeline is executing so avoid creating anymore patches, lets try to fix the tests in the MR only.

Updated patch to retrieve the redirect URL corresponding to the language specified in the query parameter path.
eg : http://URL/fr/router/translate-path?path=/en/products/electronics/laptop...
response :

{
  "resolved": "http://example.com/en/products/electronics/laptops/dell-xps",
  "isHomePath": false,
  "entity": {
    "canonical": "http://example.com/en/products/electronics/laptops/dell-xps",
    "type": "node",
    "bundle": "product",
    "id": "789",
    "uuid": "def45678-abc1-2345-6789-0abcde123456",
    "langcode": "en",
    "path": "/en/products/electronics/laptops/dell-xps"
  },
  "label": "Dell XPS",
  "jsonapi": {
    "individual": "http://example.com/en/jsonapi/node/product/def45678-abc1-2345-6789-0abcde123456",
    "resourceName": "node--product",
    "pathPrefix": "en/jsonapi",
    "basePath": "/en/jsonapi",
    "entryPoint": "http://example.com/en/jsonapi"
  },
  "meta": {
  },
  "redirect": [
    {
      "from": "/en/products/electronics/laptops/dell-xps-15",
      "to": "/en/products/electronics/laptops/dell-xps",
      "status": "301"
    }
  ]
}

Updated patch to add support for external redirects borrowing similar changes from #3133681: No information for external redirects.

Before:
Path Examples
/router/translate-path?path=/external-redirect
/router/translate-path?path=/es/external-redirect

{
  "message": "Unable to resolve path /external-redirect.",
  "details": "None of the available methods were able to find a match for this path."
}

After:
Path Example: /router/translate-path?path=/external-redirect

{
  "resolved": "https://google.com",
  "redirect": [
    {
      "from": "/external-redirect",
      "to": "https://google.com",
      "status": "301"
    }
  ]
}

Path Example: /router/translate-path?path=/es/external-redirect

{
  "resolved": "https://google.com",
  "redirect": [
    {
      "from": "/es/external-redirect",
      "to": "https://google.com",
      "status": "301"
    }
  ]
}

Attached a modified version of the patch and the interdiff.

Patch does not work correctly for me.

In my case the default language is Swedish.

I have a node with path /sv/aktiviteter

/router/translate-path?path=/en/aktiviteter

correctly returns the resolved path /en/activities

but it's unable to translate back and /sv/activities returns:

{"message":"Unable to resolve path \/sv\/activities.","details":"None of the available methods were able to find a match for this path."}

Patch works in my case.

#78 does not apply on latest dev

This patch was quite a mess after the other upstream changes.
I've cleaned it up and opened a new MR !30, and attaching patch version of same.
I'm not going to bother with an interdiff.

Adding a patch for 2.0.5

Need to re-rolls patch as per 5.0.6 latest release.

Created MR!36 with required changes to work with 5.0.6

Hi @chandu7929 and thank you for the re-rolled patch.

The only important point is that the entity URL must be specified in the requested language if found, to avoid wrong content translation for multilingual websites.

Therefore, at least jsonapi > individual needs to be changed to use the found "en" langcode, just similar to the patches provided earlier in this thread. Please check the attached screenshot.

Thanks @serg.linkin, I have included the changes for jsonapi, also adding latest patch here.

Fixes redirect failures when URLs contain encoded non-ASCII characters (e.g., Arabic: %D8%A7%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9).

The patch decodes URLs before matching redirects and aliases, ensuring proper handling whether the redirect source is stored in encoded or decoded form. Also adds multilingual support with language prefix detection and proper entity translation handling.

Fixes redirect failures with the prefix multi-language code

in MR !35 the langcode property has been moved from entity object to the root of the response. Is there a reason for this? It breaks currently next-drupal, see: https://github.com/chapter-three/next-drupal/blob/main/packages/next-dru....

I have created this MR that would fix the regression stated by @bojan_dev in the previous comment #99.

Please @chandu7929 check if this would make sense to be merged into the issue main MR !35 or there was a specific reason to move "langcode" key to a different place.

EDIT: I merged main branch as this langcode has been there for the entire history of this issue.

The MR !35 seems to return access denied for the node when following steps are taken.

1. Create a node in one language and publish it.
2. Visit the node in front-end, it is visible.
3. Create a translation of it, but keep it unpublished.
4. Visit the original published node in front-end, access to it is denied.

The MR seems to check access to the entity before it gets the translation. Perhaps that is the cause. I think it was other way round in the old MR !11.

I've been working with the patches from #3111456 and #10134399 and discovered an additional issue that affects multilingual sites.
Root Cause:
In the current patch, the entity translation is retrieved AFTER the access check. This means the access check runs on the default
language entity (which is unpublished), causing it to fail before we even get to the translated entity.

Additional fix in getPathFromAlias(): The method was returning the path WITH the language prefix (e.g., /ar/node/123), but the router expects paths WITHOUT the prefix.
Changed to return only the system path:

$system_path = $this->aliasManager->getPathByAlias($path_without_prefix, $langcode);
// Return the system path WITHOUT the language prefix.
// The router expects paths without language prefix - language is handled via $this->langcode property.
return $system_path;

I've attached a combined patch that includes:
- The language issues fix from #3111456-98
- The isHomePath fix from #10134399
- The translation unpublish fix described above

Tested on Drupal 10.x with decoupled_router 2.0.6.