RE: Comments on "TML proposal"

WOW

 

This feedback is phrased so nicely, it does look like a marvel of copywriting actually, ready to use “F.A.Q. off” comment for the future TML standard Q&A section J.

 

What is interesting however is the practice of course, not the “fight of standards”.

 

ITS may not be so much implemented yet for a simple reason – it was crated later than XLIFF 1.0 and the world of big clients are now waiting for XLIFF 2.0 (which is supposed to support ITS) before they bet heavily on it.

 

The benefit of TML may be that it does not need to wait for anything to happen before some ignorant “practicing developer” shall build some code using it.

 

What I would therefore propose here is to shift this discussion away from standards talk (and measuring whose text is longer), and move to business solutions talk.

 

As an LSP owner (and very practical one) I (and many others I think) would be interested to hear proposed use cases for TML.

 

Shall we try to identify them and then discuss and THEN we may be able to see if the TML idea actually holds water.

 

?

 

Cheers,

Serge

 

 

 

From: Brian McConnell [mailto:bsmcconnell@gmail.com] 
Sent: Thursday, April 09, 2015 5:54 PM
To: Jaap van der Meer
Cc: Serge Gladkoff; public-i18n-its-ig; Member Services; Anna Samiotou
Subject: Re: Comments on "TML proposal"

 

Hi All,

 

ITS is a XML based standard which, as far as I am aware, nobody has implemented in the real world. It is an example of a bloated and over-engineered solution that was designed by people who have little operational experience writing useful software (see also SOAP). Practicing software developers tends to favor lightweight and easy to implement solutions (this is why JSON won out over XML for data interchange). 

 

What I am describing is not a system that tries to capture every weird edge case, but rather a simple way to embed comments, synonyms, etc within loosely formatted documents in a way that won't break browsers or applications that are unaware of the microformat. 

 

Best regards,

 

Brian McConnell

 

On Thu, Apr 9, 2015 at 1:36 AM, Jaap van der Meer <jaap@taus.net> wrote:

Thanks Serge,

 

Yes, that was a bit an oversight on my part. I am of course aware of ITS 2.0, but I failed to make the connection here with Brian’s article submission for TAUS Review.

Anyway, I am happy to see that the magazine is being read. Yves also already commented.

 

The best way to have this clarified is perhaps copy the discussion/emails to the community forum on the TAUS web site: https://www.taus.net/community

 

Brian, you may want to kick this off by publishing a summary of your idea into the Forum.

 

Let me know if that works.

 

Thanks,

 

Jaap

 

From: Serge Gladkoff [mailto:serge.gladkoff@gmail.com] 
Sent: Thursday, April 9, 2015 12:39 AM
To: bsmcconnell@gmail.com; jaap@taus.net
Cc: public-i18n-its-ig
Subject: Comments on "TML proposal"
Importance: High

 

Hi Brian, Jaap,

 

Please, let me to step forward with a comment on the “TML proposal” that has been published in recent article in TAUS Review #3 on 'translation mark-up'  language:

http://issuu.com/tausreview/docs/tausreview-dataissue-april2015/14

 

The proposal suggests an annotation mark-up.

 

On “volunteer mandate” from my fellow members of W3C ITS interest group, please let me to point out the following:

 

The TML seems to replicate ITS2.0 terminology and text analysis tag functionality. ITS 2.0 is (just for the reference) as W3C standard which has been developed recently by representative group of industry experts (http://www.w3.org/TR/its20/).

 

Your TML idea seems to be a simplified approach of similar nature.

 

Well, ideas are hanging in the air, and Kudos to you for coming up with the idea that has been good enough to develop the W3C standard, recognized by well-deserved support of EU funding!

 

However, ITS2.0 is well developed, stable standard with lots of implementations and case studies already, not to mention the group used that has developed it.

 

AND, actually, looking at the proposal in more detail, my colleagues have been quick to point out that “TML” as proposed has some real problems in that it exposes metadata in ways that would totally break in non-aware processes. Because it is relying on native HTML mechanisms that only work if tools are of the “kludge” used to hide the data, it would end up blowing up word counts for other tools, result in content being accidentally translated (since <span> tags are not, by default protected), etc. We really do not like the overloading of existing mechanisms in this way when they serve fundamentally different purposes. It would take only one tool in the chain that processed the content in an intelligent way that does not match the expectation for things to break.

 

There is a real advantage to using ITS in these contexts because then tools that don't understand it also know that they don't understand it. The proposed TML in the article however, would be problematic because there is nothing in it to tell the tools (a) that they don't know what to do with it and (b) what they should do with it. It is thus entirely opaque in a bad way.

 

ALSO, the „embedding comments“ section looks like a replication for „Localisation note“. All three replications seem to be nearly exact copies of ITS data categories. So for enabling ITS processors to understand the proposed markup, one could create an ITS rules file. You write „adding support will be a minimal effort“, but that has the drawback that e.g. no validation is possible - which is easy with validator.nu . Also, this only covers HTML5 - what about Dita, docbook, mallard, TTML, XLIFF, ... (ITS spans across all these.)

 

Finally, here’s FAQ on the HTML „translate“ attribute:

http://www.w3.org/International/questions/qa-translate-flag.en

 

Does TML have a translate marker? That would be an overlap with the HTML native „translate“ attribute. 

 

Besides this maybe useful: this section

http://www.w3.org/International/questions/qa-translate-flag.en#stickyness

using class attributes, like TML does, to provide such metadata, is described as legacy approaches. See esp.: "replacing a class attribute value with an attribute that is a formal part of the language makes this feature much more reliable, especially in wider contexts.“

 

Consequently, we would say that we would really recommend to use ITS in these contexts. It is important that ITS effort is promoted, since it serves to better purpose of interoperability and decrease of duplication of effort in developing similar but incompatible solutions in different corners of the industry.

 

Jaap, is there a way to make sure that this feedback is propagated to the TAUS Review readership?

 

Perhaps we can arrange W3C ITS Interest Group to write a small “counterpoint” article in the next issue of TAUS Review? Arle and Dave Lewis could contribute with the language of the article.

 

Very Best Regards,

Serge Gladkoff