"Export DITA Map" function without filtering option

[ckabstein]

Hi everyone,
The "Export DITA Map" function is a really great feature that allows you to export all referenced files of a root DITA map.
Unfortunately, it does not allow you to filter, i.e. if you want to export only those files that are related to one product only, you cannot do this.
Since we use this function quite regularly for translations (we also use the Translation Package Builder, by the way), there's no option that avoids that the export contains files that don't need to be translated. Our authors usually go through the files and delete the non-needed ones manually. I could imagine that there is a better way to handle this situation.
I would be interested to know if other Oxygen users are in the same situation and how they handle this.
Or maybe others do not use the "Export DITA Map" function and use a different approach? Then please let me know. Any ideas are very welcome.
Thanks,
Christina

[chrispitude]

Hi Christina,

Some operations, such as refactoring operations, will skip files that are excluded when the Show Excluded Content filtering option is unchecked:

image.png (21.19 KiB) Viewed 960 times

This is a great feature and we rely on it for some of our workflows.

However, I tried an experiment and the Export DITA Map function does not seem to consider this option. So maybe requesting this enhancement could move you toward achieving what you need.

[ckabstein]

Yes, all of those filter options won't make a difference, because they just make things visible or not (although I think that all of this is really helpful nonetheless). We make use of all of these options including the profiling condition sets.

[chrispitude]

Hi Christina,

Note that some operations do consider what content is hidden by exclusion. For example, if Show Excluded Content is unchecked and you run a refactoring operation on the "Current DITA map scope", then any topic files hidden by the profiling conditions are excluded from the refactoring operation. For example, we rely on this to exclude topics hidden by @props from refactoring operations.

It sounds like you want a similar consideration by the Export DITA Map feature.

[Radu]

Hi Christina,

We have an internal issue for the feature you need, I'm adding its ID below for future reference:
EXM-33078 Export DITA Map by applying DITAVAL filter
If we get to fixing it I will update this forum thread.
There is yet another way in Oxygen to export a DITA map taking into account filters which might remove certain topicrefs in the DITA Map:
post53320.html#p53320

One thing I do not understand about these cases is that usually the translated DITA XML content stays in a separate folder let's say named "fr" or "de" located next to the original "en" folder containing the DITA XML in English for example. And these folders ideally would need to be perfectly synchronized with each other and contain the entire translation of the original "en" folder. But you seem to want to translate only a part of the original DITA XML content, a part pertaining to a certain product. How will you keep the translated content? Do you keep it per-product?

Regards,
Radu

[ckabstein]

Hi Christina,

Note that some operations do consider what content is hidden by exclusion. For example, if Show Excluded Content is unchecked and you run a refactoring operation on the "Current DITA map scope", then any topic files hidden by the profiling conditions are excluded from the refactoring operation. For example, we rely on this to exclude topics hidden by @props from refactoring operations.

It sounds like you want a similar consideration by the Export DITA Map feature.

Aha, that's interesting. We don't have a use case like yours, but if anything like that will become a use case in the future, this is very good to know.
Exactly, when we apply our profiling conditions, we would like the Export DITA Map function to exclude everything that should not be part of the document.

[ckabstein]

One thing I do not understand about these cases is that usually the translated DITA XML content stays in a separate folder let's say named "fr" or "de" located next to the original "en" folder containing the DITA XML in English for example. And these folders ideally would need to be perfectly synchronized with each other and contain the entire translation of the original "en" folder. But you seem to want to translate only a part of the original DITA XML content, a part pertaining to a certain product. How will you keep the translated content? Do you keep it per-product?

Hi Radu,
Thanks for the link to the other topic. This definitely sounds like something that we could use for now.
The only place where we keep translations is on release branches (in our Subversion repo) - to ensure that a documentation will be available in all translations in a specific state - and in the translation memory of our translation tool. One of the reasons for this is that in the past, we ran into a lot of issues with merging all the translation states back to trunk and the fact that we have different products that share files led to constant unwanted overwriting of these shared topics when a merge took place, because releases don't happen at the same time and it is 100% likely that release branches in a specific state are kept for a while.
In addition, a lot of our products share the same basic content: root ditamap, sub ditamaps and topics. Sometimes, it can be necessary that only one of these products needs to be released. In this case, we want to be able to only translate the relevant topics - and not all of them. You cannot be sure that the non-relevant files do not contain changed content. If there is changed content in a non-relevant file, this will eventually lead to a non-necessary translation, because at the time of translation, it is not clear whether that changed content is in a final state.
Christina

[Radu]

Hi Christina,
Thanks for taking the time to discuss your project's general architecture and workflow.\
So even if your dita project includes both products "X" and "Y" in the same folder initially with maps and topics, you have separate release branches for products "X" and "Y"?
Regards,
Radu

[ckabstein]

So even if your dita project includes both products "X" and "Y" in the same folder initially with maps and topics, you have separate release branches for products "X" and "Y"?

Yes, indeed, this can happen.