MHonArc v2.5.0b2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [xliff] XLIFF inline elements with spacial characteristics
Hi Andrzej,
we are currently working on the question how tagging can help to simplfy the
handling of text processing in our localization tool and we want to solve
similar problems like,
Access keys: F&ile where the '&' breaks the word file and a lot of functions
like spellchecker or terminology look up have to handle this issue.
Or we have file formats like delphi where null character are used as
separators:
File0This is the tooltip help for file.
For our internal representation we want to use something like the x-element
extended by an additional attribute (currently) called rawreplace.
The two examples now would look like this:
F<x id='1' ctype='x-akey' rawreplace=''>ile and
File<x id='1' ctype='x-ch-null' rawreplace=' '>This is the tooltip help for
file.
By just evaluating rawreplace a tool can create a string "File" or "File
This is the tooltip help for file." and can use this string for further
processing like wordcount etc. This trick also allows a correct
transformation back to the original format even if the tagged string has
been edited. and without knowing the original text. Taking your example, the
question is what should happen if <br> has a preceding space. Should a space
still be added to the XLIFF representation or not?
I hesitate to really open a discussion about a solution within the XLIFF
spec right now, as we want to finalize XLIFF 1.2 But may be you could use an
extension like x-rawreplace for this purpose.
Best regards from Bonn,
Florian
-----Urspr�ngliche Nachricht-----
Von: Andrzej Zydron [mailto:azydron@xml-intl.com]
Gesendet: Montag, 6. M�rz 2006 11:56
An: xliff@lists.oasis-open.org
Betreff: [xliff] XLIFF inline elements with spacial characteristics
Hi Everyone,
GMX-V (Global Information Management Metrics eXchange - Volume) is a
draft LISA OSCAR standard for word and character counts
(http://www.lisa.org/standards/gmx/). This should bring some sanity to
word and character counts. GMX-V is predicated on a canonical form that
is based on XLIFF.
We are almost at the end of the internal GMX-V review before it goes out
for final public comment. We have had a final discussion concerning
inline elements that imply some form of white space, but may not be
necessarily preceded of followed by any spaces e.g.
<p>This is a<br/>that is not preceded nor followed by spaces.</p>
This instance would be rendered in XLIFF as:
<source>This is a<x ctype="x-html-br"/>that is not preceded nor followed
by spaces.</source>
In the proposed GMX-V standard it is recommended that the program that
is creating the XLIFF file precedes the any inline elements with spacial
characteristics with a space if there is not one present:
<source>This is a <x ctype="x-html-br"/>that is not preceded nor
followed by spaces.</source>
This is specific to XLIFF files created for GMX-V purposes.
I was wondering if it would be desirable/beneficial to consider this
requirement within the XLIFF specification itself. Certainly having a
space would assist any segmentation algorithms etc. The onus would be on
the merge program to remove any such spaces that were inserted. It is
only the extraction and merge processes that can do this as they have
the required intimate knowledge of the source environment.
Please find attached the latest version of the GMX-V draft specification
(version 0.7).
Best Regards,
AZ
--
email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
PO Box 2167
Gerrards Cross
Bucks SL9 8XF
United Kingdom
Mobile +(44) 7966 477 181
FAX +(44) 1753 480 465
www - http://www.xml-intl.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
may not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. Unless
explicitly stated otherwise this message is provided for informational
purposes only and should not be construed as a solicitation or offer.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]