Sorry, Short answer is no real way to do that on nested content.
:onger answer :
With Nested Content (and other content-inside-content property editors) its hard for us to ignore individual elements like images, mainly because of how these items are stored
Translation of a nested content item has two elements, firstly translation manager extracts all the text bits from the content item and puts them into the translation (so i assume you don't see the image in that bit).
Then when the translation comes back, Translation Manager attempts to put those elements into the JSON for the nested content on the target item.
The problem can be those items may not have been in the same order or even be of the same type as the ones from the source. (if for example the Source content was re-ordered, or extras added since the last time the target was translated, the JSON is the way off).
To ensure the translated content end up in the same 'place' in the nested content we use the source JSON as the key; the translated values into that and make it the target JSON. This means things like images will also come across from the source.
We get around some of the issues you have for things like links and content items by having a link updater elements that runs after approval. This goes through content and updates any linked content to point to the relevant items in the target content tree - this wouldn't work directly for media though :(
It really depends on your site but you could have the editors pick content items with the media on them instead of the images, then the link updater would update the values per site but I can see this wouldn't be as nice.
Wow! Extensive and quick answer. Thanks alot man - really appreciate it.
But what about ignoring images in general at all (I mean any image at all)? Not possible either I assume since the nested content issue it would create with the key.
I was thinking about a ValueMapper returning null on all mediapickers... But that didn't seem to work either, obviously...
On 'normal' properties; no media or media pickers should go into the translation because there are no value mappers for them - so they don't get translation values, and at the other end translation manager doesn't do anything with them (it will attempt to update relative links, but that shouldn't be an issue for media)
So if you have media on its own, so not in a nested content item, or anything like that, then it won't get taken into the translation and it won't get moved across to the target (other than the first time the content is created).
but you have a point, You might be able to do something clever with a custom ValueMapper that would take media values but put the target value into the translation in place of the source one, and then when it comes out the other end it would be correct - but...
they would then appear in the translation sent to translators, and they would no longer be version controlled (so all the translation stuff is working on the version of the content at the time of creation, not the time when the content is returned, it might have changed) so it might not work.
Ignore images?
We're running the latest version of Translation Manager on a customers page.
1-1 relationship between two different startnodes (SV-SE -> EN-GB).
We have alot of content in nestedContent-fields.
The customer now wants to ignore images from being moved to the english nodes in the translation process.
It seems that I can ignore normal fields but not fields inside nested content. Is anyone else getting this issue?
Are there any other way for translation manager to ignore images completely?
Best Regards Alex
Hi Alex,
Sorry, Short answer is no real way to do that on nested content.
:onger answer : With Nested Content (and other content-inside-content property editors) its hard for us to ignore individual elements like images, mainly because of how these items are stored
Translation of a nested content item has two elements, firstly translation manager extracts all the text bits from the content item and puts them into the translation (so i assume you don't see the image in that bit).
Then when the translation comes back, Translation Manager attempts to put those elements into the JSON for the nested content on the target item.
The problem can be those items may not have been in the same order or even be of the same type as the ones from the source. (if for example the Source content was re-ordered, or extras added since the last time the target was translated, the JSON is the way off).
To ensure the translated content end up in the same 'place' in the nested content we use the source JSON as the key; the translated values into that and make it the target JSON. This means things like images will also come across from the source.
We get around some of the issues you have for things like links and content items by having a link updater elements that runs after approval. This goes through content and updates any linked content to point to the relevant items in the target content tree - this wouldn't work directly for media though :(
It really depends on your site but you could have the editors pick content items with the media on them instead of the images, then the link updater would update the values per site but I can see this wouldn't be as nice.
Kevin
Wow! Extensive and quick answer. Thanks alot man - really appreciate it.
But what about ignoring images in general at all (I mean any image at all)? Not possible either I assume since the nested content issue it would create with the key.
I was thinking about a ValueMapper returning null on all mediapickers... But that didn't seem to work either, obviously...
Hi,
On 'normal' properties; no media or media pickers should go into the translation because there are no value mappers for them - so they don't get translation values, and at the other end translation manager doesn't do anything with them (it will attempt to update relative links, but that shouldn't be an issue for media)
So if you have media on its own, so not in a nested content item, or anything like that, then it won't get taken into the translation and it won't get moved across to the target (other than the first time the content is created).
but you have a point, You might be able to do something clever with a custom ValueMapper that would take media values but put the target value into the translation in place of the source one, and then when it comes out the other end it would be correct - but...
they would then appear in the translation sent to translators, and they would no longer be version controlled (so all the translation stuff is working on the version of the content at the time of creation, not the time when the content is returned, it might have changed) so it might not work.
is working on a reply...