RE: [ISSUE-15] target-pointer

On Sun, 2012-05-13 at 20:21 -0600, Yves Savourel wrote:
> Hi Shaun,
> 
> > ...
> > The Best Practices for XML Internationalization 
> > explicitly recommends not doing this:
> >
> > http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc
> >
> > I agree with all the reasons, but disagree with the 
> > conclusion. As far as I'm concerned, the only sane 
> > way to deal with these kinds of formats is to write 
> > the source XML as if it were monolingual, use 
> > per-language XLIFF or PO files to manage translations,
> > and automatically merge the translations into the 
> > published file.
> 
> I'm probably not understanding this properly. You do seem to agree
> with the conclusion of the first note:
> 
> "It is admissible to store multilingual copies of a content in a
> single document before the document to send to localization, or after
> all localization tasks are done. For example, a final resource file
> could be constructed by collating the different language entries."
> 
> It seems to be what you are doing.
> Or I'm missing something?

You're right. I completely missed that note, apparently.

> In any case, your example illustrates a good use case I didn't include
> so far: a set of multiple elements that normally are 'paragraph-level'
> rather than just one element per language:
> 
> <application>
>   <license xml:lang="en">
>     <p>This is the license.</p>
>     <p>It has multiple paragraphs.</p>
>   </license>
>   <license xml:lang="de">
>     <p>Dies ist die Lizenz.</p>
>     <p>Es verfügt über mehrere Absätze.</p>
>   </license>
> </application>
> 
> 
> > Unless I treat license as a unit (and thus, 
> > paragraphs as within text), this doesn't work.
> 
> I agree, I don't see how we could have multiple extracted units merged
> back in a different location that is not the top-level node. It may be
> doable, but at a high cost of complexity.

My code shapes my perspective, so my immediate thought is that I'd
need a way to identify which elements are repeatable, in a way that
prescribes the elements to create, rather than describes elements
that already exist.

  selector="//license[@xml:lang='en']" repeatable="yes"

That would probably do it for me (not having tested it in an actual
working extension yet). But this makes an assumption target-pointer
doesn't, namely that the other-language elements have the same name.

> And maybe it's ok to have such limitation as it's only a limitation on
> how to work around a bad practice.
> 
> 
> As for your example, could something like the following be a solution:
> 
> <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="2.0">
>  <its:translateRule translate="no" selector="//application"/>
>  <its:withinTextRule selector="//p" withinText="yes"/>
>  <its:translateRule translate="yes"
> selector="//license[@xml:lang='en']>
>   <its:targetPointer language="'de'
> selector="../license[@xml:lang='de']"/>
>  </its:translateRule>
> </its:rules>
> 
> The merging back is still complicated, though. That is if there is
> more than one target.

Indeed. You'd have to deconstruct the XPath to create an element that
would be selected by it. It's possibly doable if you restrict it to
only relative location paths, not full expressions.

I suspect you and I are looking at two related but very different sets
of problems.

--
Shaun

Received on Monday, 14 May 2012 03:01:39 UTC