[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] XLIFF 2.0 Core finished?
Hi Rodolfo, Yes, it seems that you are right. I missed the fact that reading the spec to the letter, it a target element exists at all, it must contain a translation. Actually, according to that wording, even an empty element <target></target> would be non-compliant unless the translation is precisely an empty string. For some reason, nearly all tools generating XLIFF, including the mainstream ones, are priming untranslated target strings with source strings. This includes CAT tools online, offline and also XLIFF generators included in developer's IDEs. We could even be looking at something of at least 90-95% of XLIFF non-compliance in terms of XLIFF material prepared for translation which is definitely not good for a standard. I'm not sure what got broken with XLIFF 1.2 that made that nearly no one is following the spec on this aspect. I can speculate that perhaps it was the fact that it was simpler to prepare XLIFF files for TagEditor if there was a already a target construct to overwrite with an .ini file for an XML instead of with a proper xliff<->ttx roundtrip conversion. And at some point we all forgot what the spec creators were really aiming for because we needed to resolve real-life scenarios with the incumbent tools at the time and the easier way was probably that one. Therefore, the conclusion seems to be that even when the XLIFF 1.2 was minimalistic and probably even elegant if you look at it combined with the alt-trans feature, it did not manage to make it in the mainstream use because it turned out that very few people were following the XLIFF 1.2 target element generation rules for whatever reason. Thank you for all your feedback on this matter, I certainly had got it wrong. Hopefully the TC comes up for 2.0 with a solution that is more fool-proof! Regards, Josep. ________________________________________ De: Rodolfo M. Raya [firstname.lastname@example.org] Enviado el: martes, 22 de mayo de 2012 17:54 Para: Josep Condal; email@example.com Asunto: RE: [xliff-comment] XLIFF 2.0 Core finished? Hi, XLIFF 1.2 will not be updated. Its defects will remain there while we focus on XLIFF 2.0. Updating XLIFF 1.2 and publishing an errata costs too much time and effort. Nevertheless, you should notice that the definition of <target> in XLIFF 1.2, as available at http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#target, is quite clear: "Target - The <target> element contains the translation of the content of the sibling <source> element." As you correctly say, the content of <target> must be a translation of <source> or it must be blank. There is no doubt. Some tools place a copy of <source> content in <target> instead of leaving target empty. That is not compliant with the specification. The "state" and "state-qualifier" attributes are there to help you evaluate the quality of the target content. This attribute combination might not be enough for you, but it covers most needs for a regular user. I would say that for this particular case, the defects you observe are in the tools poorly implementing support for XLIFF 1.2, not in the specification. Regards, Rodolfo -- Rodolfo M. Raya firstname.lastname@example.org Maxprograms http://www.maxprograms.com > -----Original Message----- > From: Josep Condal [mailto:email@example.com] > Sent: Tuesday, May 22, 2012 12:14 PM > To: Rodolfo M. Raya; firstname.lastname@example.org > Subject: RE: [xliff-comment] XLIFF 2.0 Core finished? > > Hi Rodolfo, > > The XLIFF 1.2 spec reads "The optional 'approved' attribute indicates whether > the translation has been approved by a reviewer.", so my understanding is > that we should not expect that a compliant tool will set approved="yes" for a > 100% match leveraged from a translation memory or a machine translated > segment. > > For example, we received today a file for a user complaining that segments > were not shown in our QA tool. The file contained translate="no" as an > attribute for trans-unit. > > In this case, we can unambiguosly tell the user "Your XLIFF file is wrong. You > should change it or have it changed it." because the translate="no" attribute > clearly specifies in the XLIFF 1.2 spec that the segment should not be > touched. > > In this case, the spec was a great success, because we can tell univocally right > from wrong and the other party knows exactly what it must do to fix it if they > want to be compliant with XLIFF. > > But this is not the case for translatable segments that are not yet approved > by a reviewer. > > All we can implement are hacks on attributes whose default value is > "undefined". > > There are suggestions to infer state based on if target exists or not, but the > XLIFF 1.2 spec fails to say something like "If there is a target text, it must be > the translation of source, otherwise it must be blank.", and therefore a file > generated with for example "tikal -x filename" is perfectly valid according to > XLIFF 1.2 and you cannot know if segments are translated or not. You can > only guess. > > According to XLIFF 1.2 you can only know if they have been approved by > reviewer and even that is optional and still perfectly XLIFF 1.2 compliant. > > In my opinion something is missing in the spec, either it is a > translated="yes|no" attribute to replace or complement the > approved="yes|no", a remark that says that populated or existing target > means it is translated, a state="translated|untranslated" with a mandatory > default value plus a stage atribut for workflow, I don't know, some kind of > anchor. > > Regards, > Josep. > > ________________________________________ > De: Rodolfo M. Raya [email@example.com] Enviado el: martes, 22 de > mayo de 2012 15:38 > Para: Josep Condal; firstname.lastname@example.org > Asunto: RE: [xliff-comment] XLIFF 2.0 Core finished? > > Dear Josep, > > You need to separate two things: > > 1) segment translation status > 2) target state > > In XLIFF a segment can be either translatable or not. This is indicated with an > attribute. In turn, a translatable segment can be approved or not. This status > is indicated in a separate attribute. > > An XLIFF document is considered translated when all translatable segments > are approved. This is clearly indicated in the new specifications. > > Target status is a different problem. A translation inserted in target could be > perfect or completely wrong. It could have been entered by a professional > translator or generated by a machine. It could have been inherited from a TM > system and need review. There is a whole set of combinations that need to > be analyzed and the XLIFF TC has not started working on this yet for XLIFF > 2.0. > > Regards, > Rodolfo > -- > Rodolfo M. Raya email@example.com > Maxprograms http://www.maxprograms.com > > > -----Original Message----- > > From: Josep Condal [mailto:firstname.lastname@example.org] > > Sent: Tuesday, May 22, 2012 10:26 AM > > To: Yves Savourel; email@example.com > > Subject: RE: [xliff-comment] XLIFF 2.0 Core finished? > > > > Hi Yves, > > > > Thank you for the update. Since I see this is an open question, > potentially > > open for suggestions, I would like to add my own for consideration. > > > > In my opinion, a translatable segment has only two possible states: > > Untranslated and Translated. > > > > Untranslated means that we know that segment is not translated and > > Translated means that we know that the segment is translated, no > > matter how dubious. For example, we know that a 80% fuzzy match does > > not aim to be the translation of the original because we know for a > > fact that nothing > was > > done to address the missing 20%. On the other hand, we know that a > > machine translation of a segments aims to be the translation of the > > full segment, no matter how bad it can possibly turn out to be. > > > > Therefore the state of an 80% primed into target is "Untranslated" and > > the state of a machine translated segment is "Translated". The essence > > is to notify if the text in target has any foundation to be a valid > > translation > or not. > > > > Depending on application, each state can have one or more stages, > > supported under a different attribute that could be named "stage", > > which will depend on the workflow needs for users/allowed by tools. > > > > In other words, in my opinion the "state" attribute tries to describe > basic > > information, and the proposed additional "stage" attribute could > > support > any > > workflow needs no matter how complex or tool/company specific. We, as > > a LSP, can have workflow stages as specific as "client query pending", > > which are nevertheless vital for a flawless execution. > > > > Also mostly workflow stage (translated, reviewed, QAed, etc) we are > > concerned about is typically more relevant file-level information, not > > segment-level information so segment-level stage information becomes > > eventually obsolete when the whole file is understood to be at a given > stage. > > > > I think that trying to consolidate workflow stage and segment state in > > a > single > > attribute as is is done currently in XLIFF 1.2 is making the state > attribute > > unreliable unless you own the whole stack of tools used in the process. > > > > Regards, > > Josep. > > > > ________________________________________ > > De: Yves Savourel [firstname.lastname@example.org] > > Enviado el: martes, 22 de mayo de 2012 13:22 > > Para: Josep Condal; email@example.com > > Asunto: RE: [xliff-comment] XLIFF 2.0 Core finished? > > > > Hi Josep, > > > > While the discussion is currently about extensibility, the core is not > complete > > yet. > > But it is well advanced. > > > > The topic about knowing if a segment is translated or not is still > > under > work: > > http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/TranslationState > > > > cheers, > > -yves > > > > > > From: Josep Condal [mailto:firstname.lastname@example.org] > > Sent: Tuesday, May 22, 2012 2:31 AM > > To: email@example.com > > Subject: [xliff-comment] XLIFF 2.0 Core finished? > > > > Hi All, > > > > I see in the TC mailing list that focus in XLIFF 2.0 has now moved > > mainly > to > > extensibility. > > > > Has work on the XLIFF 2.0 unnegotiable Core been mostly completed? > > > > In particular I'm interested on if for XLIFF 2.0 there will be a > > univocal > way to > > determine if a segment is translated or not. > > > > Regards, > > Josep. > > > > > > -- > > This publicly archived list offers a means to provide input to the > > OASIS > XML > > Localisation Interchange File Format (XLIFF) TC. > > > > In order to verify user consent to the Feedback License terms and to > > minimize spam in the list archive, subscription is required before > posting. > > > > Subscribe: firstname.lastname@example.org > > Unsubscribe: email@example.com > > List help: firstname.lastname@example.org > > List archive: http://lists.oasis-open.org/archives/xliff-comment/ > > Feedback License: http://www.oasis- > > open.org/who/ipr/feedback_license.pdf > > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > Committee: http://www.oasis- > > open.org/committees/tc_home.php?wg_abbrev=xliff > > Join OASIS: http://www.oasis-open.org/join/ > > > > -- > This publicly archived list offers a means to provide input to the OASIS XML > Localisation Interchange File Format (XLIFF) TC. > > In order to verify user consent to the Feedback License terms and to > minimize spam in the list archive, subscription is required before posting. > > Subscribe: email@example.com > Unsubscribe: firstname.lastname@example.org > List help: email@example.com > List archive: http://lists.oasis-open.org/archives/xliff-comment/ > Feedback License: http://www.oasis- > open.org/who/ipr/feedback_license.pdf > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > Committee: http://www.oasis- > open.org/committees/tc_home.php?wg_abbrev=xliff > Join OASIS: http://www.oasis-open.org/join/