Hello all,
here are my few cents as somebody on the "receiving end"
(LSP).
Printed version of XLIFF 2.0 has 135 pages, compared to 71 for
v1.2. Inserting examples directly into the specs would further
extend the length and might prove difficult to manage.
Putting them in the SVN, along the existing test-suite (as proposed
in the original post) would be more maintainable. This way it could
contain not just fragments, but the whole (commented) files in
different stages of the life-cycle. Also different file-types can
be included.
Other than that, Yves already listed the best practices and I'm
glad he put the CDATA bit at the first place :). Using CDATA might
seem like a simple way how to handle inline codes, however you are
losing all the advantages of proper extraction.
You can represent block elements using (nested) groups and units
(table/row/cell as group/group/unit), inline codes using
<ph/>, <pc> pair, or <sc/>, <ec/>. Please
consider the update on extraction/merging best practices in the
latest XLIFF2.1 draft.
Do not forget the editing hints, which will help you to
prevent technical issues during merging, and context attributes
(e.g. disp*, type), which will simplify the life for
translator.
However, a lot depend on your particular situation:
- CMS capabilities (content fragmentation, multimedia, metadata
available. Is the native format well-formed?)
- CAT tool/LSP capabilities (does it support the features/modules
you plan to use?)