search

adobe / helix-home

The home of Project Helix
54 stars 84 forks source link

URL transformation #219

Open audi5 opened 3 years ago

audi5 commented 3 years ago

We need a URL transformation service that transforms and changes URLs across locales / languages and even instances.

Within Adobe.com we have multiple AEM instances setup. This setup helps us keep each individual cloud separate and there by helping us manage their roadmaps separately.

So, we have a separate instance cluster for CC, DC, Dx, etc. All these instances localize their own content independently. However, there are links on the content that point to each other's pages / products.

We need a URL transformer that understands this setup and changes the URLs of hyperlinks on pages when those links are pointing to pages on different instance cluster and when the page gets translated.

Requirements: Transform URLs across instance clusters Transform URLs across multiple content trees Have some sort of config when ran through the localization workflow - for this content path - the output should be this path. Links can exist between any server and not just acom / aem based instances.

I believe the logic is, if [www.adobe.com/[pagename].html|http://www.adobe.com/[pagename].html] and localized to Japanese, insert /jp. So the URL would them be [www.adobe.com/jp/[pagename].html.|http://www.adobe.com/jp/[pagename].html.] Authors wouldn't have to use relative links and could insert absolute links, as long as they were www.adobe.com URL's.

We have these content trees (so far):

/content/cc/ /content/cct/ /content/www/ /content/acom/ /content/offers-homepage/ /content/offers-miniplans/ /content/offers-plans/ /content/dx-dc/ /content/doc-cloud/

rofe commented 3 years ago

I think this should be handled on the delivery side, either in the pipleine or the client-side code rendering the page. Authors would not have to worry about URL transformation, it would happen automatically based on defined patterns.

Given the project-specific nature of this requirement, I would recommend keeping the logic client-side for the start. Similar to the language detection and link generation (author page, topic page, etc) we currently have on blog.adobe.com.

Later on we could offer a table-based feature which already performs the transformations in the pipeline (see metadata.xlsx).

kptdobe commented 3 years ago

The current translation tool is running as a pilot on the Fedpub project. This is something we could work with @narcis-radu and @mokimo.

kptdobe commented 3 years ago

Before implementing the client solution, I'll check if I cannot append it client side to the translation tool.