Translatable Inline Text vs, non-Translatable Inline Text

Title: Message

Hello,

 

This is a good 
discussion.  I think it is important that we solve this tricky business 
first, then attach our solution to whatever profile it applies 
to.

 

I think we 
should table the discussion about "How to translate text within G tags" in 
the context of the HTML Profile until we understand the underlying 
issue.

 

My participation and role in the TC has been 
as an advocate of XML and to look at each topic through my XML-purist 
lens.  Others in this TC have more knowledge and background than 
I, in related Localization standards (like TMX). They look at each topic 
through that lens, and I am happy to learn from them.

 

To apply my bias to 
the issue at hand, I like the idea of having an element like the <g tag (or 
some tag) to succinctly delimit inline tags within <source and <target 
tags.  To me, an inline element is easy to define because it always has a 
parent element, and it can always have PCDATA as a sibling.  That means it 
can always fit into a single element that can (should) fit into a *single* 
<source or <target element.

 

The idea that an 
inline element can start in one <trans-unit, and end in a different 
<trans-unit, facilitating the need for a <bpt in one element, and its 
partner <ept in another element, is unattractive to me.  It lends itself 
to producing mal-formed XML.

 

That's why the idea 
of a <g element is more attractive.  Its start and end tag must always 
be contained in the same <source or <target element.

 

I'm also very 
uncomfortable with the practice of including escaped markup in XML.  This 
is an example of what I'm talking about:

 

<ph 
id="1">&lt;i&gt;</ph>this is bold<ph 
id="1">&lt;/i&gt;</ph>

 

<bpt 
id='1'>&lt;i&gt;</bpt>this is bold<ept 
id='1'>&lt;/i&gt;</ept>

 

So I took a look at 
the specification to try to understand why people think the using the <g tag 
for translatable text is a bad idea.

 

Here's what it says 
(my comments interjected):

 

3.2.4. Inline 
Elements
The inline elements are the elements that can appear 
inside the 
<source> and <target> elements. They enclose 
or replace any 
formatting or control codes that is not text, 
but resides within the text 
unit.

[Schnabel, this is 
okay so far. Nothing to preclude the <g tag from having translatable 
text]

 

<g>

 

Generic group 
placeholder - The <g> element is used 
to replace any inline code of 
the original document 
that has a beginning and an end, does not overlap 

other paired inline codes, and can be moved within its 
parent structural 
element. 

[Schnabel, so far this sounds exactly like the kind 
of element one would like to have for translatable inline 
elements]

 

The required id 
attribute 
is used to reference the replaced code in the skeleton 
file. 

[Schnabel, this is understandably confusing.  
It makes it sound like it should only be used in concert with a skeleton 
file.  I think we could tighten this 
sentence]

 

The optional ctype 
attribute allows you to specify 
what kind of attribute the placeholder 
represents; e.g. 
"bold". 

[Schnabel, this is great.  Just what we 
want]

 

. . 
.

 

The optional 
xid 
attribute references a <trans-unit> or <bin-unit>, 
through its 
id attribute value, which can contain any 
translatable text from the 
replaced code. 

[Schnabel, I can see how this might be a clue that 
<g's use is for some code somewhere else that can be translated, but it's not 
very clear to me.  Maybe because I don't know as much about other related 
standards]

 

So I like the <g 
element for this purpose, maybe because I don't know enough about other 
standards.  If the <g has connotations that make it a bad element for 
translatable inline text, I would rather create a new tag with a specific 
definition that enables it to work to enclose an inline element with 
translatable text, in a single <source or <target 
element.

 

I am, so far, not 
convinced that changing the HTML profile in ways proposed so far, are 
useful.

 

Thanks,

 

Bryan