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 "com.day.cq.dam.core.impl.process.CreateAssetLanguageCopyProcess" and "com.day.cq.dam.core.impl.process.UpdateAssetLanguageCopyProcess" 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 "com.day.cq.dam.core.impl.process.CreateAssetLanguageCopyProcess" and "com.day.cq.dam.core.impl.process.UpdateAssetLanguageCopyProcess".
Please let me know if there is any easy/other ways to do the same.
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.