Hi Tom,

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:

1. does the translation set have the vorto element defined in the Multilanguage properties? and there isn't anything in the properties box stopping the properties been found?

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:

"view": "/App_Plugins/DocTypeGridEditor/Views/doctypegrideditor.html",

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.

e.g.

public class MyCustomDocTypeGridEditorMapper : DocTypeGridEditorMapper, IValueMapper
{
    public override string[] Editors => new string[]
    {
        "Umbraco.Gird.MyCustomDocTypeView",
        "Umbraco.Grid.AnotherCustomView"
    };
}

(where the bit after Umbraco.Grid. is the filename of the custom view, minus the .html)

i think that would fix it.

Hey Kevin,

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:

• I added a test grid field to the same composition as the original grid field, added some content and did an export: it exported the second field just fine.
• I tried renaming the original grid field to something else and then did another export: grid fields not included.

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?

Hey Kevin,

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...