[MURLTRANS-2] Module doesn't work for page variants Created: 18/Jan/18  Updated: 17/Jul/19  Resolved: 27/Jul/18

Status: Closed
Project: URL Translation
Component/s: None
Affects Version/s: 5.6
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Ervin Vystup Assignee: Richard Gange
Resolution: Won't Do Votes: 1
Labels: i18n, incubator
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File rename-field.png    
Issue Links:
relation
is related to MGNLPN-396 Variant node name can be changed when... Closed
is related to MURLTRANS-3 Make property name and query node typ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Hi, When I use URL Translation module made by Richard Gange (from old urltrans module), it doesn't work for translated variants.

Problem is a query that is used in URLTranslator.java, which expects node to be [mgnl:page]. When you have path like:

page/page/page/variants/variant, it can't find anything.

I made workaround of this problem and I'm using [nt:base] as type in this query, but I think that should be fixed properly.



 Comments   
Comment by Richard Gange [ 31/Jan/18 ]

I think the fix will be to replace [mgnl:page] with [mgnl:content] based on the nodetypes files from:

Comment by Richard Gange [ 09/Apr/18 ]

After some thinking about this issue there are a few problems here. First of all this module was developed before personalization existed. So it does not surprise me we hit the issue now. One workaround would be to try and use component variants over page variants to avoid the problem altogether.

I was thinking I could fix the URL Translation module to look at the parent page for it's translations in the case where a variant is requested. This is not a problem. However, there are two things that would also need to be fixed.

  1. The dialog for the page variant would need to be different. It would have to disable the name field. That really doesn't seem doable.
  2. When creating a page variant we would need to keep the name field from being copied to that page variant. This is doable.

So for now I will say this module cannot be used with page variants. I am also going to revert the change I made on the query.

Comment by Richard Gange [ 09/Apr/18 ]

One approach does come to mind. We use a special dialog for setting the page translations. It can be triggered via a custom action that is only available for the parent node.

Comment by Richard Gange [ 10/Apr/18 ]

I think I may have a solution for this. Rather than control the page names via the page level dialog, instead the approach will be to use the "Rename page" action. This action provides a light dialog that can be i18nized on the jcrName field.

This action is already restricted to page nodes only. So, not variants. You cannot rename a variant node.

Comment by Marvin Kerkhoff [ 24/Jul/18 ]

Hi Rich,

this should be easy to fix, but it needs a change in a core class:

We just need to wrap a codeline in info.magnolia.ui.dialog.action.SaveDialogAction

Wrap line 81 following:

if(!NodeUtil.hasMixin(node, "mgnl:variant")){
   setNodeName(node, item);
}

This should exclude all variant nodes from nodename changes. In my opinion this should be a save solution.

Comment by Richard Gange [ 24/Jul/18 ]

Hello Marvin-

Right, I know what you mean. However, making a change to core to help support an extension is not likely to happen.

What I was thinking might be doable is to change the property which holds the translation. The idea was to make that configurable, see MURLTRANS-3.

 

Comment by Marvin Kerkhoff [ 25/Jul/18 ]

Yes this would be also a solution. But in my opinion adding the 2 lines of code into the core will help making the product more stable. Because it's not only this extension that can add a name property to a website. In the end you don't wan't that the node name changes if there is a name attribute, this would be always an issue.

Comment by Richard Gange [ 25/Jul/18 ]

Yes I understand. The problem is every bug/code-change has a certain amount of overhead. We only have so much man-power. Therefore we have to prioritize tickets.

You are right about the node name. Probably it would have been better to not store the translation under a property called name in the first place. But again, at the time this code was written Personalization was not yet a thing in Magnolia.

Anyway, I will try and tackle MURLTRANS-3 this week. Perhaps Friday. I'll let you know.

Comment by Richard Gange [ 27/Jul/18 ]

MURLTRANS-3 introduces the option to configure the query.

Generated at Mon Feb 12 11:08:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.