xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xliff] RE: Resource Data Module <was: RE: [xliff] Binary Module>
- From: Helena S Chapman <hchapman@us.ibm.com>
- To: Ryan King <ryanki@microsoft.com>
- Date: Thu, 31 Jan 2013 14:46:55 -0500
I am much more comfortable with this. Thank
you for making those changes.
One question, if a target is to be replaced
completely, would there a need to keep track of that "replacement
history"? Would that be handled thru the "track changes"
proposal?
From:
Ryan King <ryanki@microsoft.com>
To:
"xliff@lists.oasis-open.org"
<xliff@lists.oasis-open.org>
Date:
01/30/2013 02:31 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 Helena S Chapman/San Jose/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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]