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] | [List Home]


Subject: FW: [xliff-comment] using xliff to translate html


For some reason I can't get through on the xliff-comment.
So I'm posting this here.

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Fri, September 05, 2003 4:38 PM
To: Nico van de Water; xliff-comment@lists.oasis-open.org
Subject: RE: [xliff-comment] using xliff to translate html


Hello Nico,

Thanks for your comments, I'm glad you made them. The importance of context
for the translator is an aspect developer of translation tools and processes
have a tendancy to forget.

I would go even one step further: Ideally the translator should have access
to the final form of the data (the formatted page, the dialog box, etc.) as
often the format of the source file itself may not be enough to get a
correct context.

There are a few aspects of XLIFF or XLIFF-related process that may help with
this issue:

- Some of the metadata like restype can hold a clue about the origin of the
data (for example that it's a checkbox, or a radio button, vs a normal
paragraph, and so forth).

- Grouping of items together (e.g. the controls of a dialog box, the
hierarchy of a set of menus, etc.) can be maintained in XLIFF by using the
<group> elements adequately (they can be nested if necessary).

- Some information about the context can also be carried along with the
translation units through the <context-group> and <context> elements.


This said, I realize it is not enough to ensure you get the context you need
because those aspects are mechanism that *could be used*, with no certainty
that they will be.

To help in that regard, one of the aims the XLIFF TC has is to create
"profiles", documents that describe the recommended way to represent a given
format in XLIFF. This is one area where we can push for the use of the
context-oriented mechanisms.


As you pointed out the lack of context goes beyond XLIFF: it happens more
and more in the source format itself (properties files, XML documents,
etc.). I think the long term effort is to "educate" the designer of source
formats (e.g. creators of XML document types) in the importance of having
information about the context in the source file itself. This should be part
of the guidelines for designing internationalized schemas and DTDs.

I would also add that XLIFF may not necessarily be the format of choice to
translate *all* formats. If tools support correctly a given format there is
probably no needed to complicate the process by extracting to XLIFF and
merging back. At the same time, the same given format may take advantage of
being extracted to XLIFF for other tasks than translation (e.g. terminology
extraction, validation, alignment, and many others), so we have to make sure
XLIFF can support it.

In some circumstances XLIFF can actually help to bring more context. For
example, I'm currently working on a tool for image/graphic localization and
in this occurrence XLIFF is helping me to associate context information and
the text to localize. I've attached an example: an XLIFF file that uses XSL
to render pictures (it could the bitmaps of a UI) along with the text to
localize. See the Trados screen shot, or just open the XLF file to see. Note
the comment displayed for the last image. We could not do this directly with
HTML (the comments would be either not visible (<!-- --->) or seen as
translatable). So I think in some case XLIFF could help for bring more
context, while in some other cases we need to be careful not to loose a
minimal information set the translator needs.


Kind regards,
-yves

ContextExample.zip



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