[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]