Thanks David for your feedback. One of the motivations for a resource data module is to
enable localization of user interface elements which can be affected by
translation of string data, for example, modification of size and position due to increased string length. Since existing resource formats can vary widely and new ones can be created at will, it would be very difficult to represent localizable resource
data such as this as standardized XLIFF elements. Hence, in order to keep XLIFF as interoperable as possible, and to still enable localization of user interface elements, the need to associate localizable string data in XLIFF to localizable resource data in
an external file.
As for a needing a target reference screenshot, there are cases, such as when a source string has been updated, but a translation of the previous source exists,
or a target string has been recycled from a previous translation, where a target screenshot could still provide a translator with needed context, e.g. surrounding strings and user interface elements, etc.
Thanks,
Ryan
From: David Walters [mailto:waltersd@us.ibm.com]
Sent: Thursday, February 7, 2013 5:21 AM
To: Ryan King
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>
Ryan, I am uncomfortable with the concept of an XLIFF file pointing to another file, with the expectation that the referenced file would be modified during the translation process. From your
description in the Resource Data Model:
This module is used to store references to external resource data that
may need to be localized or used as contextual reference during translation.
The whole concept of XLIFF is that all localization information should be defined within the XLIFF file itself, and that everything is defined in a format-neutral manner. Implying that an outside file must be modified in a format-specific manner does not conform
to the intent of the XLIFF standard. The XLIFF charter states: "The specifications are tool-neutral,
...". When the XLIFF file is created, all localizable information should be defined directly in the XLIFF file.
If that is not possible, then the XLIFF Specification would have to be enhanced to allow defining that data in a format-neutral way.
In the referenced example below, the first <res:resourceData> element references an XML file. What are the XLIFF processing expectations for that XML file? If the XML file contains the <unit>'s
<source> text and we are trying to show how the text is originally defined or used, then we are now in the format-specific realm and are no longer format-neutral. The second <res:resourceData> element references a JPEG file. I can understand the usefulness
of providing a reference image of how the<source> text is used within the product, but I do not see the usefulness of providing an image of how the <target> text is used, as the translation has not yet been performed.
Maybe I am the only one which concern about this module, and how it is changing the general scope of XLIFF as an interchange format. But I would also like to hear what othes have to say about
this change in direction.
David
Corporate Globalization Tool Development
EMail: waltersd@us.ibm.com
Phone: (507) 253-7278, T/L:553-7278, Fax: (507) 253-1721
Ryan
King ---01/30/2013 01:30:47 PM---Hi All, I haven’t seen any feedback on the draft for the Resource Data Module (formerly Binary Data
From:
Ryan King <ryanki@microsoft.com>
To:
"xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>,
Date:
01/30/2013 01:30 PM
Subject:
[xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>
Sent by:
<xliff@lists.oasis-open.org>
Hi All, I haven’t seen any feedback on the draft for the Resource Data Module (formerly Binary Data Module). Please send them to the list so that I can incorporate any changes before
working on the DocBook files and publishing it to the spec.
Thanks,
Ryan
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Ryan King
Sent: Wednesday, January 23, 2013 3:46 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] Resource Data Module <was: RE: [xliff] Binary Module>
Hello All,
In the TC call on 12/8, there was the suggestion of keeping a registry on the OASIS wiki for the custom mime-types of the binary module proposal. After the call, we had some discussions internally
about the feasibility of this and believe that it will be very difficult to keep and maintain such a registry on the OASIS wiki. I believe that others have expressed similar concerns. To this end, we'd like to propose that we only keep one module at the <file>
level that references external files/containers, and no longer propose embedding binary data at the <unit> level as a module. Here is an example:
<file id="1">
<res:resourceData id="1" mime-type="text/xml">
<res:source href="resources\en\registryconfig.resources.xml" />
<res:target href="resources\de\registryconfig.resources.xml" />
</res:resourceData>
<res:resourceData id="2" mime-type="image/jpeg">
<res:source xml:lang="en-us" href="screenshots\en\loadregistryconfig.jpg" />
<res:target xml:lang="de-de" href="screenshots\de\loadregistryconfig.jpg" />
<res:reference xml:lang="de-lb" href="\screenshots\lb\loadregistryconfig.jpg" />
</res:resourceData>
<unit id="1" name="130;WIN_DLG_CTRL_">
<segment id="1" state="translated">
<source>Load
Registry Config</source>
<target>Registrierungskonfiguration
laden</target>
</segment>
</unit>
<unit id="2" name="133;WIN_DLG_CTRL_">“
<segment id="1" state="translated">
<source>Remove
Registry Config</source>
<target>Registrierungskonfiguration
entfernen</target>
</segment>
</unit>
</file>
In this example, external XML is referenced that may contain resource data for a user interface control. The control is the container for the text “Load Registry Config” and may need to be resized
to accommodate the increased length of the string due to translation. 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. A second set of external files are referenced,
which are images that could be used for context when translating.
Please find attached the detailed specification for the module. We would appreciate your comments and thoughts.
Thanks,
Ryan, Alan, Kevin, and Uwe
-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Ryan King
Sent: Wednesday, January 16, 2013 5:11 PM
To: Yves Savourel; xliff@lists.oasis-open.org
Subject: RE: [xliff] Binary Module
Thank you Yves for your evaluation and feedback. You are correct on each point below for the functionality provided by the binary module. Your notes on the proposal itself were also very helpful.
Each one was valid and made sense. I will make changes to the draft accordingly.
thanks,
ryan
-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Yves Savourel
Sent: Monday, December 24, 2012 8:22 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Binary Module
Hi Ryan, all,
Thanks for the updated proposal regarding the 'resource' case of the binary module.
I'd like to step back for one moment and list the requirements that, I think, you have for the functionality provided by the proposed binary module. From the email discussions and examples I
have seen so far, I believe they are as follow:
- one should be able to store an arbitrary block of non-textual data that may be binary (e.g. a widget)
- one should be able to identify the original format of that block of data (e.g. a Windows control)
- one should be able to identify the encoded representation of that block of data (e.g. base64)
- one should be able to associate that block of data to a given unit
- one should be able to store both the source and the target representation for that block of data
- one should be able to store both the source and target representation outside the XLIFF document
- one should be able to keep track of the status of the target representation (which may differ from the status of the corresponding text)
- one should be able to indicate whether or not the block of data needs to be modified (in addition to the extracted text)
=== Notes on the requirements:
In many aspects it looks like your requirement are basically calling for some form of element that is comparable to the skeleton with two main enhancements: a) it is directly associated with
a unit, and b) it is capable of carrying a target representation.
=== Notes on the proposal itself:
-- I would name that <bin-unit> element something else to avoid the perception that a) it is at the same level as a <unit> (a sibling), and b) that it is always binary (one can store non-binary
data there too). If originalData was not already taken I would suggest that. Maybe unitData or something similar will do?
-- Keeping <source> and <target> should be fine because they are in a different namespace than the core <source> and <target>.
-- The tree show "<bin-unit> *" not "<bin-unit> ?" is that mean you really want to allow more than one block of data per unit? If so is there an existing use case that justifies it? (I can't
think of any case where a text would be existing in two different location and need to be treated as one).
-- If we can keep this element to zero or one then there is probably no need for the id attribute.
-- Why use CDATA with Base64? Just curious, since none of the 64 possible character of base64 needs to be escaped. Note that nothing guarantee that you will get CDATA back. On very large file
that's just extra nodes for nothing.
-- The state attribute for the translated text is at the segment level per the F2F resolution (see
https://lists.oasis-open.org/archives/xliff/201210/msg00070.html).
By the way: I realized today that I'm the one with the action item to update the specification with the 'state' and 'subState' attributes. I'll try to do that as soon as I can find the time. Sorry for the delay.
cheers,
-yves
---------------------------------------------------------------------
To unsubscribe, e-mail:
xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
xliff-help@lists.oasis-open.org
[attachment "Resource Data Module.pdf" deleted by David Walters/Rochester/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php