[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> <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----- 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
Description: Resource Data Module.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]