RE: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>

[Yves Savourel <ysavourel@enlaso.com>]

Hi Ryan,

Thanks for the answers. Please see my notes inline (YS>)


-- I’m not sure how is expressed the relationship between the resourceData element at the top of the file and the unit. You mentioned using the name attribute of the unit. But in your example there is no such relation. So how this is working?

[ryanki] The comment from the draft was: "The name attribute of the <unit> containing the <segment> to be translated could serve as the key for a user agent to associate text and resource." This is just an example that may need to be reworded for clarity. It is conceivable that a user agent COULD use the resource ID in the name attribute to map to a resource ID in the reference XML and by default, or possibly depending on an extensible attribute, open an editor that allows the translator to make modifications to the resource data mapped to that resource ID. 

YS> I see how things *could* work. But my point is that there is no defined way in the current draft to link a <resourceData> to a given <unit>. This is bound to cause problem when tools manipulate the XLIFF content.



-- You also mention that maintaining a registry of custom mime-type for XLIFF would be difficult and say "To this end, we'd like to propose that we only keep one module at the <file>..." How moving the data out of the unit and putting in at the top of the file is resolving the mime-type value issue? Am I missing something?

[ryanki] The crux of it is that we are no longer proposing the use of a custom mime-type in the actual XLIFF, instead resource data should be referenced externally as a file. The processing of that external file happens outside of the XLIFF, though extensible attributes or metadata might be defined to help the user agent deal with it.

YS> I see a 'mime-type' attribute in the module. So we do use mime-type values in XLIFF.
Personally I think using the IANA MIME type registry is enough: one can register new types there. So I don't see a need to have some XLIFF-specific registry. My point was that moving the resource out of <unit> doesn't affect the mime type usage, and since moving out the resource brings new issue like how to link unit and resource I'm just wondering what are the benefits to have the resource outside of its related unit.



-- The definition of the module says: "This module is used to store references to external resource data that may need to be localized or used as contextual reference during translation". Those are two very distinct functions. How does a user agent knows which resource is for one and which resource is for the other? For example a tool may want to remove contextual references for make room, but it would want to keep the resources that do need to be localized.

[ryanki] Good point. We could add a "translate" attribute: yes=translatable, no=context; or a "context" attribute: yes=context, no=translatable. Would that work?

YS> Sure. The context attribute would probably make more sense since what need to be done for the other type (translate/localize/resize/etc.) is less clear.


cheers,
-yves