[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Fragment Identification
|
Here’s a real world example that I have not seen represented in this discussion so far. It may be pertinent, or it may not. If it is the later, please disregard. My experience with XLIFF, FWIW, is as a buyer of translations. The sources of the XLIFF files I send out for translation are mainly: - Web CMS (Drupal source where each discrete node is a <file>) - Web CMS (Drupal source where each PO file is a <file>) - Component CMS (DITA files where each topic is a <file>) - Test and Measurement Equipment (where each discrete instrument’s UI code is an <xliff>) - Test and Measurement Equipment (where each discrete instrument’s firmware code is a <file>) Unfortunately (or fortunately) I wrote each use case’s extractor/merger code at different points in time, and I’ve use minimalist (using a skeleton) and maximalist
(relying on <group>) architecture as it suited me. But the same LPSs leverage and translate all forms. We have very strict rules about the state of the translated XLIFF that comes back to us from our LSPs. In short, they must have identical structure, down to
the <file>, <group>, <trans-unit>, <source>, and <target> level. My merge code simply cannot tolerate or reconcile diversions. We do allow adding, removing, or reordering inline elements. So finally to my point. Does my story have bearing on this discussion? If so, should XLIFF be able to support my local rule set with my LSP? If the answer to each is yes, then I tend to think that the spec should not prohibit me from setting up a set of local rules with my LSP as I’ve described.
But I do not feel prescribing the manner in which my rules are set up needs to be explicitly part of the spec. FWIW, Bryan From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip Yves, people can do to the XLIFF files what the specification allows to do, not to break the guaranteed interchange. Of course, all sorts of other private things can be done with the XLIFF files. However, If you do anything to the static structure of the document, you have to be able to roll it back. It is IMHO out of scope to describe this We have the roundtrip requirement in the Conformance section and it has always been there. e. XLIFF is a format explicitly designed for exchanging data among various Agents. Thus, a conformant
XLIFF application MUST be able to accept XLIFF Documents it had written after those XLIFF Documents were Modified or Enriched by
a different application, provided that:
i. The processed files are conformant XLIFF
Documents,
ii. in a state compliant with all relevant Processing Requirements. The assumption is that an application must take back what it has previously created. Currently this includes a possibly different dynamic or segment structure, codes or markers in the other equivalnet forms etc. Changing file or groups structure is not defined ergo not allowed. It does not mean that you cannot in fact do it. but IF you do you have to undo it before continuing in the "public" roundtrip governed by the spec.
Dr. David Filip ======================= LRC | CNGL | LT-Web | CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto:
david.filip@ul.ie On Mon, Dec 16, 2013 at 3:55 PM, Yves Savourel <ysavourel@enlaso.com> wrote: Hi David,
You can't possibly define all allowed operations in the specification.
So is splitting one huge XLIFF documents into several ones to dispatch it to different translators (also a common operation). That's |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]