Translatable Inline Text vs, non-Translatable Inline Text

[<bryan.s.schnabel@exgate.tek.com>]

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