Nigel Lock (hi!) Yes, I thought of this too, but I still think the proposed solution is better than managing tons of files. There is always some communication with the translators when a job kicks off, so they shouldn't be surprised to see some new and some updated content ... assuming their localization manager has done their job well of course :)

I think this is a duplicate Idea: community.sdl.com/.../localization-combine-all-objects-for-a-chapterappendix-submap-into-a-single-file-for-translation

I can definitely see that managing fewer files can be easier for a translator and with DITA being inherently component based it can produce many 'files' for a translator. In the proposed intermediary XLIFF scenario, I wonder if it might be confusing for the translator when translating updates to existing content vs. first time translation of new publications? For a round of updates, perhaps only 50% of the DITA components have changed, so when the DITA components get exported for translation, the XLIFF concatenation will only contain 50% of the publication. Might the content being in a single XLIFF file for translation cause confusion for translator, with chunks of content not logically flowing due to components being 'missing' since they didn't need to be sent for translation?

Hi Elizabeth, I want me to solve it as well.