W3C home > Mailing lists > Public > public-tt@w3.org > June 2003

RE: TT Req (translation markup)

From: Glenn A. Adams <glenn@xfsi.com>
Date: Mon, 30 Jun 2003 12:31:01 -0400
Message-ID: <7249D02C4D2DFD4D80F2E040E8CAF37C03BB4F@longxuyen.xfsi.com>
To: <Johnb@screen.subtitling.com>, <Luke-Jr@cox.net>
Cc: <public-tt@w3.org>
My position on your questions would be:
(1) TTAF should not attempt to specify the descriptive vocabulary of the XLIFF mtype values; rather, a generic attribute such as "role" would be defined to take arbitrary user defined values. If the TTWG really feels strongly that some specific roles should be defined, then we could do so.
(2) The intention of the phrase element is to encapsulate an arbitrary unit of content that is logically smaller than a paragraph. It does not have a narrow meaning, but an arbitrary meaning; i.e., it is not intended to be limited to use in delimiting a natural language phrase alone. Think of it as another way of writing the HTML span element.
(3) The issue of extensibility is addressed by requirements R103, R107 and R108. XML Namespaces will be used to distinguish non-standard element types and attributes from standard W3C defined element types and attributes.
So, in conclusion, I don't see any new requirements here that aren't already addressed.


	From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
	Sent: Monday, June 30, 2003 12:11 PM
	To: Glenn A. Adams; Luke-Jr@cox.net
	Cc: public-tt@w3.org
	OK, I see what you mean, I guess the questions then are
	1) Does TT AF need to include a descriptive vocabulary that supports some or all of the XLIFF mtype values?
	2) Is the element name phrase appropriate - since phrase has a rather narrow meaning.
	3) Will TT AF allow extension to support user defined inline markup? Does TT AF need a "get-out" clause (rather like the ruby parenthesis one?) 
	regards John B

		-----Original Message-----
		From: Glenn A. Adams [mailto:glenn@xfsi.com]
		Sent: 30 June 2003 14:26
		To: Johnb@screen.subtitling.com; Luke-Jr@cox.net
		Cc: public-tt@w3.org
		Subject: RE: TT Req (translation markup)
		The purpose of the phrase vocabulary item indicated in TT AF 1.0 Requirement R209 is to satisfy the types of usage you have listed below. So I think we are already covered here.


			From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
			Sent: Monday, June 30, 2003 6:10 AM
			To: Luke-Jr@cox.net; Glenn A. Adams
			Cc: public-tt@w3.org
			Luke, Glenn, et al 

			Actually this may be an important issue. 
			It may be desirable to allow inline markup within a TT document that marks sections of the text for specific purposes. I have in mind the XLIFF <mrk> element.

			The specification for XLIFF can be found at: 

			The mrk element has an mtype attribute 

			<mrk mtype/> 

			where the recommended values for the mtype attribute are as follow 

			(this list is not exhaustive  and reference should be made to the XLIFF specification): 
			- abbrev = abbreviation, acronym, etc. 
			- datetime = date or time information. 
			- name = proper or common name. 
			- phrase = sub-sentence level. 
			- protected = text that should remain untouched during the process. 
			- term = one or more words of a terminology entry. 

			Some examples of a text element using mrk markup are shown below: 
			<text id="T2" class="Charlie">Afternoon, <mrk mtype="abbrev">Dr</mrk>. <mrk mtype="name">Sparrow</mrk>.</text> 
			<text id="T27" class="Sir Lancelot">I don't want <mrk mtype="protected" xml:lang="en-us">garbage</mrk> on my car.</text>

			The first example illustrates the use of the mrk element to identify an abbreviation and a proper name that would probably require special processing by a machine translation system. In the second example the mrk element protects the word 'garbage' from machine translation  thus this word should remain as 'American English' regardless of any translation of the remainder of the surrounding text.

			Is there any reason why TT format would prohibit or prevent the use of such markup? 
Received on Monday, 30 June 2003 12:31:06 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:23:59 UTC