[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] XLIFF 2.0 Core
> You can't consider PO sources or software document sources > as the main source type for XLIFF files. I didn't. Sorry if I was unclear. I was just giving examples where dealing with inline codes is done different ways by translation tools; so for some tools makers generating abstract inline codes as most of us in the TC do is not something necessarily obvious. And I was wondering if the conformance clauses of 2.0 should make this (creating inline codes) a requirement; and if they should, how to go about it (because it seems not possible to me). I think you answer that question. > As I see it, inline elements are a core part of XLIFF standard. I could not agree more. > If a tool generates "<source>Text in <b>bold</b>.</source>" from > a document that clearly requires the use of inline elements, users will > hate it and hopefully will not buy that tool. > You cannot force a tool vendor to use or support inline elements. > Nevertheless, you can make inline elements available to all tools. > Implementers and users will decide what they want. I'm not sure I get this: The two statements "inline elements are a core part of XLIFF standard" and "You cannot force a tool vendor to use or support inline elements" seem contradictory. If inline codes are part of the core, then they are part of the minimal set of features a compliant XLIFF tool has to support. Or I have misunderstood what the XLIFF core means? To be clear on the inline codes aspect: I think we cannot force a producer tool to generate inline codes, but I think there would be advantages to force consumer tools to support them. -ys
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]