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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-translation message

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


Subject: Re: [dita-translation] XLIFF, workflows and comments



Hi Rudolfo,

Thank you for your comments. I would like to expand on some of your points:

1) There is nothing in DITA to mandate the use of a CMS. Nevertheless I 
personally would consider it a best practice to do so. Anything 
involving more than one author and a dozen or more topics becomes very 
difficult to manage without one. If you take into account say 10 or more 
target languages and revisions and the normal document life cycle 
effect, then trying to manage without a CMS becomes error prone and 
extremely labor intensive. My personal view is that in anything bar the 
most simplistic environment it is very difficult to try and implement 
DITA without a CMS system to handle versioning and languages.

2) There is nothing preventing the generation of XLIFF files directly 
from a DITA document. If you are happy to farm out all of the 
translation process to a third party there is no problem. You might as 
well just send them the DITA documents. Why bother with XLIFF at all. 
The downside of completely relinquishing the localization process is one 
of cost. If you leave all of the translation operations to a third party 
you will incur costs for processes that can be totally automated within 
the CMS workflow. In the end it will boil down to the amount of data 
being processed. If the volumes are anything but very small, then you 
will gain savings by automating the TM and other operations within the 
workflow. Otherwise someone has to process the files manually or semi 
automatically. Someone else then also has to manage the memories etc. 
All of these operations can be time consuming and expensive.

3) The flow chart that is shown in your email does not include any of 
the normal localization elements required for an efficient process, 
among them being Document Directives (what is to be translated and what 
is not to be translated, what are translatable attributes and which are 
inline elements). You can 'hard wire' these into a program or XSLT style 
sheet, but this would be a very short sighted strategy. You then have to 
do this for every implementation from scratch again. Missing is also 
segmentation and any translation memory operations. Yes, you can 
generate XLIFF documents very easily, but an XLIFF document on its own 
is of marginal use if you then have to pay someone to do your matching 
and segmentation for you.

4) xml:tm is a proposed Open Standard. In its simplest implementation it 
can be used to pre-prepare a document for XLIFF extraction. It enables 
the implement ion of extraction on the basis of future W3C ITS Document 
Directives and segmentation on the basis of the SRX standard. It 
provides a framework for implementing many other L10N standards into the 
XML environment. The fullest form of xml:tm introduces the concept of 
reuse at the sentence level. The concept of reuse is significant - it 
introduces 'exact matching' as part of the standard as well as 'focused' 
translation memory matching. Reuse is also at the heart of the DITA 
principle. The two standards are in complete harmony - DITA at the 
concept/topic level xml:tm at the text unit level.

Exact matching does not require any translator intervention as therefore 
does not incur any translation cost. You cannot do this without the 
previous source and target versions of the document which implies a CMS. 
100% matches coming from a TM are not exact matches. They still require 
proofing which carries a cost which can still be significant, specially 
if the amount of change to a document has been small.


5) xml:tm does not require the use of a CMS as part of the standard, in 
the same way as DITA does not require the use of a CMS as part of the 
standard. In practical terms the use of an automated translation 
workflow has many benefits and this is made much easier if you have a CMS.

It is all to do with automating language processing and thereby 
providing greater efficiency and reduced costs. It is also an example of 
two symbiotic standards working in perfect harmony.

Best Regards,

AZ

Rodolfo M. Raya wrote:
> 
> Hi All,
> 
> Here are some links to XLIFF-related material.
> 
> *What Is XLIFF and Why Should I Use It?*
> /by Peter Reynolds and Tony Jewtushenko/
> http://xml.sys-con.com/read/121957_1.htm
> 
> The key picture in this article is this:
> 
> 
> ------------------------------------------------------------------------
> 
> 
> *Internationalization: Implementing the XLIFF Standard*
> /by Jon Allen - /PowerPoint presentation
> http://web.princeton.edu/sites/isapps/jasig/2003summerWestminster/presentations/XLIFF%20IM030610.ppt
> 
> This presentation describes a workflow based on ANT and XSL stylesheets 
> for converting XML documents to XLIFF.
> 
> ------------------------------------------------------------------------
> 
> 
> *An Introduction to XLIFF*
> /by Tony Jewtushenko - /PowerPoint presentation
> http://www.igniteweb.org/documents/xliff_12_detailedintro.ppt
> 
> This presentation focus on the importance of XLIFF mostly, but has a 
> section called "The real World", starting on slide 54 with details on 
> workflows based on XLIFF.
> 
> ------------------------------------------------------------------------
> 
> 
> Andrzej's presentation includes details on how to embed xml:tm namespace 
> into DITA documents and how to use the extra data in the translation 
> process. If you remove all process steps that involve xml:tm from the 
> presentation you get a simpler picture similar to the one above.
> 
> As I said, it is not necessary to use xml:tm in the translation process 
> if the workflow includes a good TM engine somewhere. There are 
> advantages on using xml:tm, but end users should balance the pros and 
> cons, not the DITA TC.
> 
> Andrzj is also right when he says that a CMS is useful for handling DITA 
> documents, if not essential in large projects. However, using xml:tm may 
> require a CMS as complement. From recent threads on the dita-user 
> mailing list at Yahoo! I have the feeling that most users don't work 
> with a CMS. This is something that should be seriously considered.
> 
> Best regards,
> Rodolfo
> --
> The information in this e-mail is intended strictly for the addressee, 
> without prejudices, as a confidential document. Should it reach you, not 
> being the addressee, it is not to be made accessible to any other 
> unauthorised person or copied, distributed or disclosed to any other 
> third party as this would constitute an unlawful act under certain 
> circumstances, unless prior approval is given for its transmission. The 
> content of this e-mail is solely that of the sender and not necessarily 
> that of Heartsome.
> 
> 
> ---------------------------------------------------------------------------------------------------
> *Text inserted by Panda Platinum 2005 Internet Security:*
> 
> This message has NOT been classified as spam. If it is unsolicited mail 
> (spam), click on the following link to reclassify it: It is spam! 
> <http://127.0.0.1:6083/Panda?ID=pav_48619&SPAM=true>
> ---------------------------------------------------------------------------------------------------


-- 


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]