Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Taxonomy routing conflicts of multi-language #17485

Open
yqzhen1990 opened this issue Feb 14, 2025 · 8 comments
Open

Taxonomy routing conflicts of multi-language #17485

yqzhen1990 opened this issue Feb 14, 2025 · 8 comments
Labels
Milestone

Comments

@yqzhen1990
Copy link
Contributor

Describe the bug

I added LocalizationPart to the taxonomy type and created English and German versions of Tags.
English verstion : localhost:5001/tags;
German version : localhost:5001/de/tags;
After I saved the English version of tags and visited localhost:5001/de/tags, All the tag terms displayed on the page were German letters but English version tag permalink, and the when you click to visit the tag term just like : localhost:5001/de/tag/earch it response with a 404 error.

Orchard Core version

2.1.5

Logs and screenshots

Image

Image

Image

Image

@hishamco
Copy link
Member

Explain how you added a localized version on taxonomies, I remember there's unknown bug, that I fixed in my last working website but not submitted a PR yet

Could you share a minimal project or recipe to reproduce the issue

@yqzhen1990
Copy link
Contributor Author

  1. Use Blog theme create a new project;
  2. Enable content localization feature;
  3. Add LocalizationPart for taxonomy;
  4. Create another language version for Tags and publish it;
  5. Request default language page of Tags and the new language page of Tags, the bug will be reproduced.

@hishamco
Copy link
Member

You can request the localized version by access the page by the newly added permalink

Add LocalizationPart for taxonomy;

As I said earlier there's a known bug, when you add a LocalizationPart to Taxonomy all the taxonomies will be localized. It might ok for your case, but sometimes we might some of them to be localized

@yqzhen1990
Copy link
Contributor Author

You can request the localized version by access the page by the newly added permalink

Add LocalizationPart for taxonomy;

As I said earlier there's a known bug, when you add a LocalizationPart to Taxonomy all the taxonomies will be localized. It might ok for your case, but sometimes we might some of them to be localized

Ok,thanks for your suggestion.

@yqzhen1990
Copy link
Contributor Author

You can request the localized version by access the page by the newly added permalink

Add LocalizationPart for taxonomy;

As I said earlier there's a known bug, when you add a LocalizationPart to Taxonomy all the taxonomies will be localized. It might ok for your case, but sometimes we might some of them to be localized

I debugged‌‌ the source code, and found when I add a 'LocalizationPart' to "Taxonomy" A and create a localized version B or clone A as a new Taxonomy Contentitem B. The taxonomypart's terms' ContentItemIds in B are the same with the corresponding terms' ContentItemIds.

In AutorouteEntries.cs:

` public async Task<(bool, AutorouteEntry)> TryGetEntryByContentItemIdAsync(string contentItemId)
{
ArgumentException.ThrowIfNullOrEmpty(contentItemId);

    await EnsureInitializedAsync();

    if (_paths.TryGetValue(contentItemId, out var entry))
    {
        return (true, entry);
    }

    return (false, entry);
}`

only the ContentItemId of the term passed in as the key to filer the AutorouteEntries , but in the AutoroutePartIndex table , multiple data entries with the same ContainedContentItemId exist at the same time. As a result, the returned Path may not be the expected one.

Image

@hishamco
Copy link
Member

I need to recheck again or let us chat in Discord

@sebastienros
Copy link
Member

Can you confirm that your issue is that the tags (taxonomy terms) of the DE taxonomy are loosing the parent Taxonomy's route (with the "de" prefix).

@sebastienros sebastienros added this to the 3.x milestone Feb 20, 2025
Copy link
Contributor

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants