Under Community Review

Translation: Combine topics for an entire "chapter" into a single DITA File

If a publication with 12 chapters (or large "sections" in Help) contains 500 topics, and those topics need to be sent to translation, it would be much easier for the translators to manage 12 "chapter/section" files than 500 individual files. Currently, the translators either translate them as they show up in their system (alphabetically?), or they have to manually search for the next logical topic for translation. This would not only make it easier for the translators (and reviewers or anyone else in the l10n chain) to manage the files, but it would improve translation quality since they would better understand the content with its surrounding context.

The system would do something like this: review the "chapter/section" map, identify the objects that need to be translated to language X, merge them in the order of the map into a single DITA file to be translated. After translation, they would be de-constructed during the import process.

Note: Bryan Schnabel presented a similar idea at an SDL conference a few years ago: https://sourceforge.net/projects/ditaxliff/files/

Elizabeth Gschwind
Parents

  • 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?

Comment

  • 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?

Children
No Data