I'm looking into creating a tool to automatically convert all internal links to link to the translated versions of those links for their respective languages. Is there currently a way to find the translated version of the page from the original page? If not, it would be a nice feature enhancement, perhaps running it through umbraco's relationship api.
Translation Manager is using the relations service underneath to manage how it translates between your original page and the translated one(s) -
The LinkedPages package lets you see and edit these links from the page. (https://our.umbraco.com/packages/backoffice-extensions/linked-pages/) but its more of a management tool to help when that hasn't gone as expected.
So you can update links by looking at the relationships of a link to find the other languages.
There is a built-in link updater with Translation manager (since v2) updates the internal links in a translated item to those on the translated site as part of the approval process - I am not sure if this is the type of thing you are looking at?
At the moment that link updater is tied into the translation jobs - but we do have a task on our list to have an option just to call it and it updates all links on the page.
it's a bit complicated because links in pickers and standard RTE boxes are relatively simple, it just becomes a bit more of a pain when the link is inside some inner content which a grid inside using a leblender. so the link updater has "mappers" (much like translation manager does for content) which find the links and then do the updates.
What you can access with the current version of translation manager is the LinkResolver (in Jumoo.TranslationManager.LinkUpdater namespace)
if you know the translation set you can call it to resolve a link from one site to another.
An example of that might look like:
// get the translation manager services.
var setService = TranslationManagerContext.Current.SetService;
var resolver = new LinkResolver(contentService, relationService, setService);
// work out what translation set a bit of content is in (so you know where the master site is)
var sets = TranslationManagerContext.Current.SetService.GetTranslationSetByTargetPath(contentItem.Path);
// a node can be in multiple sets, so you might have to do something here
var set = sets.FirstOrDefault();
// the site is the target language for the page based on the set it is in
var site = setService.GetTargetSite(set, contentItem.Path);
// this will resolve it to the equivlant in the target set/site
resolver.ResolveLink(set, site.Id, linkId);
// this will resolve Udis in the target set/site.
resolver.ResolveLink(set, site.Id, linkUdi);
So you could do this, or you can just go through the relation service for each bit of content and resolve back to the parent (this is what we are doing, just with a few extra checks, for multiple sets, targets etc)
I tried running a test page with an internal link in an rte through translation, but it didn't map the link to it's the equivalent link in the target language after I approved the changes. I checked Translations.config and both picker and inline options for links are set to true. The xliff 1.2 file I ran through the translation can be seen below.
I just manually filled in the targets by copying the source. At the bottom there is a grid rte control with a link to one of the pages on the master site. This link wasn't automatically pointed at the Spanish version of the page. Is there something I'm missing? I'm running v2.1.5 of Translation Manager (haven't installed the updated version of the xliff provider you made in response to one of our other threads, since it turned out the translation service we wanted it for didn't support xliff at all).
The link updating happens at the approve & publish (or just approve and save) phase, so any link information that ends up inside a link inside the XLIFF won't update.
When you approve and save and then view the translated content on the site you should see the links all now point to the language site.
all links should be updated not just the ones that are then in the XLIFF file (we don't, for example, put content pickers into the XLIFF, but the links are updated)
but only links that have an equivalent in the language site will be updated - so there has to be a relationship between the page being linked to and the page on the target site (these should already be in place if you are translating the site / created it with copy relate to original).
but if it doesn't seem to be working, try turning up the logging
(in log4net.config)
you will then see lots of debugging, but on approval, you should also see entries for LinkUpdater - and it should already be logging things if it encounters errors.
I tested it with the debugger on, but didn't encounter any errors. It appears to be attempting to map it, as there is a line showing the before and after, but the link doesn't change. See below for the relevant lines from a translating a page with just one link within a grid rte.
2019-02-13 18:24:56,518 [P14572/D8/T21] DEBUG
I know the node I linked to in this test has a spanish relation, so I'm at a bit of a loss why it's not transformed. Any chance a missing license prevent it from running properly when testing in a local environment? I haven't installed one yet, though I imagine there would be errors logged if it was looking for that.
Is there a way to get the translated versions of a page from the original page?
I'm looking into creating a tool to automatically convert all internal links to link to the translated versions of those links for their respective languages. Is there currently a way to find the translated version of the page from the original page? If not, it would be a nice feature enhancement, perhaps running it through umbraco's relationship api.
Hi Jesse,
Translation Manager is using the relations service underneath to manage how it translates between your original page and the translated one(s) -
The LinkedPages package lets you see and edit these links from the page. (https://our.umbraco.com/packages/backoffice-extensions/linked-pages/) but its more of a management tool to help when that hasn't gone as expected.
So you can update links by looking at the relationships of a link to find the other languages.
There is a built-in link updater with Translation manager (since v2) updates the internal links in a translated item to those on the translated site as part of the approval process - I am not sure if this is the type of thing you are looking at?
At the moment that link updater is tied into the translation jobs - but we do have a task on our list to have an option just to call it and it updates all links on the page.
it's a bit complicated because links in pickers and standard RTE boxes are relatively simple, it just becomes a bit more of a pain when the link is inside some inner content which a grid inside using a leblender. so the link updater has "mappers" (much like translation manager does for content) which find the links and then do the updates.
What you can access with the current version of translation manager is the LinkResolver (in Jumoo.TranslationManager.LinkUpdater namespace)
if you know the translation set you can call it to resolve a link from one site to another.
An example of that might look like:
So you could do this, or you can just go through the relation service for each bit of content and resolve back to the parent (this is what we are doing, just with a few extra checks, for multiple sets, targets etc)
Thanks for the quick response. That sounds like exactly what I'm looking for.
Hi Kevin,
I tried running a test page with an internal link in an rte through translation, but it didn't map the link to it's the equivalent link in the target language after I approved the changes. I checked Translations.config and both picker and inline options for links are set to true. The xliff 1.2 file I ran through the translation can be seen below.
I just manually filled in the targets by copying the source. At the bottom there is a grid rte control with a link to one of the pages on the master site. This link wasn't automatically pointed at the Spanish version of the page. Is there something I'm missing? I'm running v2.1.5 of Translation Manager (haven't installed the updated version of the xliff provider you made in response to one of our other threads, since it turned out the translation service we wanted it for didn't support xliff at all).
Hi Jess
The link updating happens at the approve & publish (or just approve and save) phase, so any link information that ends up inside a link inside the XLIFF won't update.
When you approve and save and then view the translated content on the site you should see the links all now point to the language site.
all links should be updated not just the ones that are then in the XLIFF file (we don't, for example, put content pickers into the XLIFF, but the links are updated)
but only links that have an equivalent in the language site will be updated - so there has to be a relationship between the page being linked to and the page on the target site (these should already be in place if you are translating the site / created it with copy relate to original).
but if it doesn't seem to be working, try turning up the logging (in log4net.config)
you will then see lots of debugging, but on approval, you should also see entries for LinkUpdater - and it should already be logging things if it encounters errors.
Kevin
I tested it with the debugger on, but didn't encounter any errors. It appears to be attempting to map it, as there is a line showing the before and after, but the link doesn't change. See below for the relevant lines from a translating a page with just one link within a grid rte. 2019-02-13 18:24:56,518 [P14572/D8/T21] DEBUG
I know the node I linked to in this test has a spanish relation, so I'm at a bit of a loss why it's not transformed. Any chance a missing license prevent it from running properly when testing in a local environment? I haven't installed one yet, though I imagine there would be errors logged if it was looking for that.
is working on a reply...