Meeting Notes: [xliff] Reminder: details for today's XLIFF TC optional discussion meeting

MHonArc v2.5.0b2 -->

xliff message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: Meeting Notes: [xliff] Reminder: details for today's XLIFF TC optional discussion meeting

From: "Tony Jewtushenko" <>

To: "'XLIFF TC'" <>

Date: Fri, 2 Jun 2006 17:52:41 +0100

Attendees:  Tony, Doug, Mat

 

We discussed the topic of whether the
XLIFF TC should recommend a “Best Practice” for creation of XLIFF
documents when extracting content from other resource formats. 
Specifically, the main issue is whether as a new XLIFF document is created
initially if a blank “target” element should be created and
populated from the contents of “source” element upon extraction, 
or on the other hand if the new XLIFF document should be created without “target”
elements.

 

First we all agreed that any
recommendation for extraction “best practices” would not be
included in the normative spec or non-normative representation guides. 
Any recommendations for tools developers would be strictly limited to a couple
of *brief* paragraphs or even sentences
in a FAQ or Whitepaper.  It was agreed that some mention of a couple of recommended
scenarios would be a good idea, but to stress that it’s really up to the
tools developer to decide on features.

 

Secondly, we all agreed that an XLIFF
document with source but no target elements is still a valid XLIFF document, and
as such XLIFF capable tools should support opening such a document for editing.
What the tool does next is not to be specified in any TC recommendation. It was
mentioned that XLIFF enabled tools produce new XLIFF documents inconsistently –
ie, one tool copies source -> target while another creates new XLIFFs without
a target.  It was recommended that the FAQ or whitepaper indicates that
opening XLIFF documents without target elements should be supported by all
XLIFF tools, as it is a perfectly valid document.

 

Third, it was mentioned that the IGNITE EU
funded project will be working independently to “certify” localization
tools for compliance with localization standards, XLIFF being one of
them.  They would be the natural body to establish best practices for
implementing best practices, not the XLIFF TC.  We should of course provide
input.  And TC members may contribute to that group as well – see http://www.igniteweb.org

 

We briefly discussed the most logical
scenarios for creating a new XLIFF document and target element handling during
an extraction process:

 
Do not create a ”target”
     element when no translation exists.  Omit the structure completely. 
     Let the tool or user decide to create the “target” when they
     need it,  and optionally copy over content and attributes & their
     values – these are feature specs for the tool developer to decide
     how to handle.

 
Create a “target”
     element and populate it with the entire elements contents and properties w/
     values from the “source” element.  Mark it with an
     appropriate state such as “needs-translation”

 
Create a “target”
     element but leave it empty or fill it with some sort of content, and
     populate with properties w/ values from the “source” element.

 

Advantages of Scenario 1:

1.      
Conserves space, improves
tool performance and reduces network bandwidth requirements by eliminating
redundant content.

2.      
Lets the tool decide on
best way to create a target.

 

Disadvantages of Scenario 1:

 
Translation tool or other
     process would have to have logic to test for presence of “target”
     element, then create “targets” when necessary, and decide what
     content should be copied over from “source” – could have
     performance implications in some scenarios.

 
Relies on tool or user to
     decide if markup should be copied over – may result in corruption or
     unintentional omission of markup 

 

Advantages of Scenario 2:

 
simplifies logic of tool and
     reduces structural complexity of XLIFF documents

 
ensures the markup in “target”
     is identical to “source”

 

Disadvantages of Scenario 2:

 
Creates unnecessary content
     that can negatively affect storage, processing and performance.

 
imposes limitation on tool and
     user behavior to a very narrow set of functionality ( ie., reduces ability
     to design clever or user friendly features)

 

Advantages of Scenario 3:

 
Couldn’t really think of
     any – scenario seems unlikely and poorly conceived.

 

Disadvantages of Scenario 3:

 
implies inconsistent tool feature
     behavior and unstructured content

 
does not provide any of the advantages
     of either of the 2 scenarios but all of their negatives.

 

That’s about it.

 

Further suggestions and comments are
welcome, and I’d like to progress this discussion via email as far as
possible.

 

Regards,

Tony