Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
We're trying to set up Translation Manager (v2.4.1) on an existing site (Umbraco v7.11.1).
We have multiple hostnames set up on the same site, so the translation set we created is a circular set with the same root node for the different languages.
The pages that need translating have a couple of Vorto fields for things like meta data, and a grid field for the main page content that uses DTGE where each DTGE item uses Vorto fields for the translatable content within that grid element.
When we create a translation job for any of the pages using the XLIFF provider, the exported .xliff2 file does contain the main meta Vorto fields, but none of the grid blocks are included.
Is there something we need to configure for those grid fields to be included?
that 'should' work. although with doctype grideditor there are so many config elements it might be missing something,.
I've just tested it out of the "box", with a doctype grid editior with the standard views/etc, with a vorto datatype with a text string in it, and the value was extracted (and reimported) tothe xliff.
things to check:
if you where for example to put -gridContent in the properties box that would stop anynested vorto elements from ever being found
Custom DocTypeGridEditor Views ?
I think if you change the view in the grid config that might cause issues. the default:
How Translation Manager finds mappers in the grid is a little bit complex because unlike datatypes they don't have a set-id of any form, so the doctype grid editor is found (like a few other grid elements) by the view name, which in the default case it 'doctypegrideditor' this means we are looking for a mapper for Umbraco.Grid.doctypegrideditor
if the view name ends in something else we won't find the mapper for the doctypegrid editor.
at the moment there isn't a simple config for this (there should be). you could have a class that inherits DocTypeGridEditorMapper and override the editor values to match your doctype grid editors.
public class MyCustomDocTypeGridEditorMapper : DocTypeGridEditorMapper, IValueMapper
public override string Editors => new string
(where the bit after Umbraco.Grid. is the filename of the custom view, minus the .html)
i think that would fix it.
Thanks for you suggestions.
The settings in our translation set are exactly the same as in your screenshot, and we don't override the DTGE view either so that is the same path as well.
But one thing that is 'different' is that the grid field for the node is included via a composition.
I just tested it again by adding another grid field (using the exact same data type) directly to the doc type (same tab as well), added a DTGE field with some text in one of the Vorto fields (like we have in the first grid field), and then ran another translation export.
This time the newly added grid field is included (including the Vorto field data as expected).
Could it be somehow related to the fact that the original grid field is added via a composition that it's not included in the export?
So I did a few more tests, and I don't think it's related to the compositions at all:
But then I had a look in the logs and I can see the following error:
Jumoo.TranslationManager.Core.Services.TranslationValueService - Failed Property: [My Page] layout - System.InvalidCastException: Cannot cast Newtonsoft.Json.Linq.JArray to Newtonsoft.Json.Linq.JToken.
at Newtonsoft.Json.Linq.Extensions.Convert[T,U](T token)
at Newtonsoft.Json.Linq.JToken.Value[T](Object key)
at Jumoo.TranslationManager.Core.ValueMappers.VortoValueMapper.GetSourceValue(String displayName, String propertyEditorAlias, Object value, CultureInfoView culture)
at Jumoo.TranslationManager.Core.ValueMappers.DocTypeGridEditorMapper.GetSourceValue(String displayName, String propertyTypeAlias, Object value, CultureInfoView culture)
at Jumoo.TranslationManager.Core.ValueMappers.GridValueMapper.GetSourceValue(String displayName, String propertyEditorAlias, Object value, CultureInfoView culture)
at Jumoo.TranslationManager.Core.Services.TranslationValueService.GetPropertyValue(IContent item, String alias, CultureInfoView culture)
So it looks like it fails to parse some of the content.
Any ideas on why that might be?
So I think I narrowed down to what the issue might be:
Some of our DTGE modules have Vorto fields that wrap a Nested Content field (to group multiple fields together inside a single Vorto group):
If I don't have any of these modules in my grid field the export is fine, but as soon as I add one the export fails with the previous JSON conversion error.
I'm guessing that the VortoValueMapper isn't expecting that, hence why it fails on converting the value (which is a NC JSON array).
Am I right in my assumptions here?
yeah that sounds about right, i think i have seen this before with slightly different setup.
The NC content is actually stored in different ways depending on if it's in the grid or just in another value (so a Vorto with a NestedConent in it not in the grid, would store it a bit differently).
I will take a look because we've done something very similar before, and we then we should be able to fix the vorto mapper.
just released an update (v2.4.2) which fixes nested content elements inside vorto elements (inside the grid!).
this should resolve the issues you are having.
That's great news!
I won't have time to test it until later this week, but will definitely let you know how we get on.
I've just tested it with the updated version, and all the content from the grid is now in the export.
We'll now go and send this to the translators and then test the import as well with the translated text, so will let you know if that is working as well.
Thanks for providing the updated version so quickly 👍
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted