OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [xliff] Reformat Suggestion for XLIFF 2.0

Despite the suggestion to postpone the reformat element in 1.1, I have still been thinking about the issue
I have been doing more work with an xliff 1.0 implementation for Oracle, and the issue has required numerous untidy workarounds.
This is therefore a new simpler suggestion for 2.0.
If it as simple as I think it may be, I have no objections to reinserting into 1.1
One problem overlooked in reformattable elements or attributes, is that any structure that is changed during translation has no placeholder to store the original value
Say we have some structure that is to be modified during translation
For example
During translation this becomes
But we have lost the original value of xxx
New Solution
The idea is that any structure that may be translated is enclosed within a reformat element
is translated to
Any structure not enclosed within a reformat element may not be changed during translation, except state etc.
If concerned about wordiness
    <sval> x-value="xxx"<\sval>
     <tval> x-value="zzz" <\tval>
If a transunit has five reformattable elements, then we need five <rfmt> elements. If we tried to put all into one element, we will have problems matching up like with like.
An advantage is that any structure can be controlled in this way, regardless of being XLIFF standard or an extension
This is just an Idea. I have not checked to see if it is workable within the schema

Attachment: Matthew Lovatt.vcf
Description: text/vcard

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC