Skip Assets from Asset Translation Job




Hello Team,


We are using AEM 6.4.2 and using Human Translation project to send pages/assets for translation.


I have configured my Translation rules to exclude/Include paths with /content/dam/ path allowed.


My DAM structure is "/content/dam/XYZ/global", "/content/dam/XYZ/us", "/content/dam/XYZ/uk" "/content/dam/XYZ/de" etc..


I have image component which will be used by authors in different sections of the page and browse images from the above paths. Here I want to exclude images from "/content/dam/XYZ/global" but take images from other locales for translation while they submit pages for translation.


I have debugged the OOTB code and logic was in "" and "" Process steps, is not having any logic to bypass the certain folders on any criteria.


I can think of two options as of now:-

1. Setting a DAM property either manual or automatic to configure a "global" = "true" on Asset metadata for global assets and set filter in translation rules

2. Overlay OOTB Translation workflows, "dam-create-and-translate-language-copy", "dam-create-language-copy", "dam-update-and-translate-language-copy", "dam-update-language-copy" and write our own logic of excluding above "/content/dam/XYZ/global" in customized workflow process of "" and "".


Please let me know if there is any easy/other ways to do the same.


@BrianKasingli @Theo_Pendle . @Arun_Patidar @Jörg_Hoh @vanegi @kautuk_sahni 

Accepted Solutions (1)

Accepted Solutions (1)




Technically that's a feature request, and I would raise it as such with support. The question is the priorization of it.

You probably cannot wait for 6 months for that to happen, so I think that you go forward with a more hacky solution, which you can replace as soon as the feature is available.


Customizing the workflow sounds like the better idea, but decompiling product code and introducing a modified version of it into your application isn't a good idea either (omitting all the legal aspects of it), because this code can change with every SP/release/.....

Which means that more obvious workaround (maybe setting this global flag) might be safer.


But in the end there's no really good way to handle it, because you would need a small feature within a larger framework.

Answers (0)