[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] XLIFF Process and Agent Related Terminology Proposal
Hi David, all,
I read through the proposal and I think this goes a bit overboard.
I think we can define what a “user agent” (or “agent”) is (although I see it used in many specification without definition).
Extracter and Merger (or whatever _expression_ we settle on) would be useful too, but probably in very simple terms.
And, in my opinion, that’s about it.
We define a file format, where our PRs must be expressed in relation to the format and what the user agent knows about the format. We can't assume any type of processing workflow.
So, statements like "Modifier MUST be able roll back the core and bin-file structure of an XLIFF that it has previously modified" or "Validation MUST NOT be performed at the time of Merge." are going way too far.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Dr. David Filip
Sent: Tuesday, December 11, 2012 7:35 AM
Subject: [xliff] XLIFF Process and Agent Related Terminology Proposal
Hi all, I've been working on this process and agent related terminology. The plan is to use this as definitions in the XLIFF 2.0 spec. The idea is that this should help formulate PRs for core features, modules and extensions.
Unfortunately we still do not have sufficient module related PRs, and worse we do not have the newly approved features as Docbook articles.
Please comment on the proposed definitions within this week. If I do not hear serious objections by the end of this week I will start implementing the terminology in the Docbook spec along with some other pending changes.
The proposed text is attached (as docx and pdf) AND pasted down below. The attachment contains also an illustartive BPMN diagram (png attached separately) that was socialized with the TC before. I am aware that the BPMN digram needs to be harmonized with the proposed terminology, still I prefer doing the harmonization after the proposed terminology has been discussed and stabilized.
My plan is adding PRs to the spec by the end of 2013, so that its implementations become verifiable based on conformance statements rather than based on tribal knowledge (term courtesy of Ryan King :-).
Dr. David Filip
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
Process and Agent Related terminology in XLIFF 2.0
Agent – a tool that does anything to an XLIFF file from extract to merge inclusively.
Extract/Extraction – the process of encoding localizable content from a native content or User Interface format as XLIFF payload, so that localizable parts of content in the source language are available for translation into the target language along with necessary context.
Extractor (Agent) – an Agent that performs the Extraction process.
Merge – the process of importing XLIFF payload back to the originating native format, based on the full knowledge of the extraction mechanism, so that the localized content or User Interface strings replace the source language in the native format.
Merger (Agent) –an Agent that performs the Merge process.
Unless specified otherwise, Merger is deemed to have the same knowledge of the native format as the Extractor throughout the specification. Mergers independent of Extractors can succeed, but it is out of scope of this specification to specify interoperability for merging back without the full extractor knowledge of the native format.
Enrich/Enriching – the process of associating module and extension based metadata and resources with the extracted XLIFF payload.
Enriching MAY happen at the time of extraction.
Enricher (Agent) – an Agent that performs the Enriching process.
Extractor knowledge of the native format is not assumed while Enriching.
Modify/Modification – the process of changing core XLIFF structural elements and bin-file module elements.
Modifier (Agent) – an Agent that performs the Modification process.
Structural elements MAY be Modified and Enriched at the same time. Modifier MUST be able roll back the core and bin-file structure of an XLIFF that it has previously modified.
Enricher or Extractor knowledge of the native format is not assumed while Modifying.
Rollback of Modifications performed by a different Modifier is out of scope.
Edit Source/Source Editing – the process of changing payload of <source> children of <segment> elemensts.
Source Editor (Agent) – an Agent that performs Source Editing.
Source editing MAY be performed at the time of Modification.
Translate/Translation - a rendering of the meaning of source text, expressed in the target language. As an XLIFF based process it means creating and changing <target> children of <segment> elements.
Translation Editor (Agent) – an Agent that performs the Translation process.
Review/Revision – the process of creating or changing any annotation elements, attributes or values specified in core, modules or extensions. This includes marking spans of <source> and <target> children of <segment> elements.
Revision Agent – an Agent that performs the Revision process.
Revision MAY be performed at the time of Translation.
Revision MAY be performed at the time of Modification.
Validate/Validation – the process of checking XLIFF payload against any rules specified via the Validation Module or any general, core or module specific Processing Requirements.
Validator (Agent) – an Agent that performs the Validation process.
Validators MAY add test results via the Validation Module.
Validator MUST not modify any other XLIFF elements, attributes or values.
Validation MUST NOT be performed at the time of Merge.
Extractor/Merger Agents will benefit from use of a Validator. Even though the Validator will often be a part of the same tool/platform, it is important to distinguish between validation and the actual Merge. Validation will routinely precede Merge, while failed Validation will lead to exception handling, such as returning the XLIFF file to a Revision Agent or Translation Editor, Modifier etc.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org