Specification & documentation -- Community collaboration to draft a functional specification explaining the intended support coverage for ODF and the provisional implementation choices taken for XLIFF (style for inline tags, etc.)
Every block of text extracted from an ODF file will be labeled to inform the translator what is being translated. The possible labels will be:
(TODO The list above is only an example, write the real list.)
Nick Shaforostoff says:
I also ask you to fill ctype attribute of <g> tag for some common cases: ctype=“italic” when the style of the text is italics, see http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#ctype
Friedel says: We handle duplicates in several ways when converting in the toolkit. The preferred method is to use msgctxt to add unique information. Having identical translations without msgctxt is an invalid PO file. We could merge identical strings (this is one of our existing duplicate handling strategies), but for document translation I think this will be very risky, and possibly cause translation out of context.
More here: duplicates_duplicatestyle
By default the software will only segment on a block level, not sentence.
The interface will accept an SRX file as an optional parameter, if provided it will be used to segment the block into sentences. The software will not include any SRX file.
When converting to XLIFF, let us try to favour the use of tags that remove the codes from the source (<g>, <x/>, <bx/> , <ex/>), rather than tags that mask off codes left inline (<bpt>, <ept>, <sub> , <it>, <ph>). ODF is verbose with long tags that is mostly not useful for a translator.
For example: ODF: A sentence with <text:span text:style-name=“T1”>important words</text:span> XLIFF: <source>A sentence with <g id=“1”>important words</g>
There is mostly no use for the translator to see <text:span text:style-name=“T1”> in a bpt tag.
--- Friedel 2008/09/26 08:25