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: 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 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" />


  <unit id="1" name="130;WIN_DLG_CTRL_">

    <segment id="1" state="translated">

      <source>Load Registry Config</source>

      <target>Registrierungskonfiguration laden</target>



  <unit id="2" name="133;WIN_DLG_CTRL_">

    <segment id="1" state="translated">

      <source>Remove Registry Config</source>

      <target>Registrierungskonfiguration entfernen</target>





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.



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.





-----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.









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
Description: Resource Data Module.pdf

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