[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Groups - Event "XLIFF TC Call" added
First let me say that I really appreciate your clear words.
We had a longer discussion process in Lionbridge over the past weeks about our position concerning XLIFF 2.0, how to use it (as a processing format, or only as an exchange format), and about the recent addition (to v2.0) specifically of the bin-unit.
Looking at it, the bin-unit, as Helena points out, breaks the guarantee that XLIFF wanted to give in the first place: That you can take an XLIFF file from any creator, and by knowing the XLIFF spec you can be sure that you know how you will process the translatable (textual) content.
It would be interesting to understand why the bin-unit was added to v1.2. Having it back in 2.0 breaks, as we see it, the fundamental principle of XLIFF again. Please, we are open for any elaboration on this point, did we misunderstand about that principle?
I think that the TC decision process about this feature went too fast, at least too fast to discuss options and alternatives, and consider the issues.
We would propose to split XLIFF into two standards: One Container standard and one Content standard. The Content standard would be XLIFF without the bin-units, and the Container standard would be the bin-units, if you will. The Container would allow to store arbitrary binary files, including XLIFF, alongside property data describing these files. The Container could also be used to store multiple revisions of the same file, which is a very common scenario in the loc process. From any XLIFF file inside the container you could point to any arbitrary file in the same container. This will replace the bin-unit.
Now why will this help us: because it will raise awareness with our clients that arbitrary files which they put into the container are not prepped files as XLIFF files are. This way they will understand that if they put, say, a binary word processor file of a only locally known maker in it, we will not automagically be able to translate it. It will raise awareness with our production people that arbitrary files in the container mean risk, cost, and time. Therefore they will analyze the files properly before approving the handoff, and adjust the offer. When there are only XLIFF files in the Container, they can prepare a cheaper offer.
One might argue that this Container exists: Linport. That might be the case, I do not yet know it well enough to tell. However, to some extend we appear to be in a catch 22 with Linport, as they refuse to use XLIFF as their Content format as long as it is as lax as today. And bin-units would be very lax in their view.
The Container could be as simple as ZIP plus a catalog.xml. I think that is what Linport does.
Thank you for your attention, I am curious about your opinion. And have a great weekend!
Joachim
________________________________
Joachim Schurig
Senior Technical Director,
Lionbridge Fellow
Lionbridge
1240 Route des Dolines
06560 Sophia Antipolis
France
From: xliff@lists.oasis-open.org
[mailto:xliff@lists.oasis-open.org]
On Behalf Of Helena S Chapman
Sent: Donnerstag, 13. Dezember 2012 16:48
To: Bryan Schnabel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Groups - Event "XLIFF TC Call" added
Bryan. I would like to point to the elephant
in the room and let's have a blunt discussion. I personally have real concerns
with the direction of XLIFF 2.0. For example, the ability to include binary
entities into XLIFF as a "container". Especially this late in
the game for 2.0.
To me, XLIFF is an interchange format for "textual" content for
localization purposes during the content life cycle. Using embedding binary
in XLIFF as an example again, I want to know very clearly the reason for
including binary entities into an interchange format and expect the tools
to actually understand how to parse and process that in a interoperable
fashion. I maintain XLIFF is NOT a processing format by design though some
vendors may choose to use it so, it does NOT serve the purpose of the majority
users' intent for using XLIFF.
Why would one want to include binary entity in XLIFF? Is it to pass video
files embedded in content between systems? If so, the only thing the translation
vendor would need to worry about really is the audio and transcript portion
of the file. Why can't one just use SSML (http://www.w3.org/TR/speech-synthesis/)
for the purpose of that interchange? Why introduce that complexity into
XLIFF? Why can't it be managed as an external reference with an absolute
path if needed? When it comes to binary entities, there is too much complexity
around how it can be "processed", "understood", and
"exchanged" consistently across systems, trying to absorb all
that into XLIFF is simply asking for trouble.
XLIFF is becoming a "kitchen and sink" standard in the last few
months and I do not agree with this direction. I am very lucky in that
I have a much simpler job than most on the TC. I am in charge of my entire
company's internationalization and translation architecture, tools and
processes and we tell our vendors what to do. For these XLIFF 2.0 features
that I disagree with, I simply tell my team that these features are simply
passthrus that we do not process or support within our operation. However,
for a real tool vendor who has to support more than a single client scenario,
things are not as easy. This also points to the fact that we do NOT have
enough major tool vendor participation (except for Lionbridge) to make
this 2.0 effort really worthwhile.
I have abstained and kept quiet on the last few calls, however, I realized
it perhaps is not in the best interest of XLIFF TC or myself if I continue
to do so. I would prefer my name is not associated with a standard that
cannot be widely adopted by the localization industry.
Best regards,
Helena Shih Chapman
Globalization Technologies and Architecture
+1-720-396-6323
or T/L 938-6323
Waltham, Massachusetts
From: Bryan
Schnabel <bryan.s.schnabel@tektronix.com>
To: xliff@lists.oasis-open.org
Date: 12/03/2012
12:21 AM
Subject: [xliff]
Groups - Event "XLIFF TC Call" added
Sent by: <xliff@lists.oasis-open.org>
Submitter's message
Two Notes:
1 - I will spend a few minutes announcing a change in secretary personnel
2 - We've had a very robust mailing list session. I will parse the emails
and provide a summary for the agenda so we can hit the ground running
-- Bryan Schnabel
Event Title: XLIFF
TC Call
Date: Tuesday, 04 December 2012,
11:00am to 12:00pm EST
Agenda
Owner: Bryan Schnabel |
[attachment "ical_34010.ics" deleted by Helena S Chapman/San
Jose/IBM]
---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]