RE: [dita] Cascading of xml:lang attribute

[<bryan.s.schnabel@tektronix.com>]

Hi Bruce,

Regarding your question:

> can't you send fragments smaller than a topic for translation if
> that's all that has changed?

I think that depends on your method of sending topics out for translation. I see this as an absolute real-world requirement. And I think a great way is to use the open standard for translation, XLIFF, as part of your DITA process.

I hope to resurrect the DITA Translation SC (under the DITA Adoption TC) as soon as I can marshal the bandwidth. One of the things members of that SC have talked about in the past is evaluating the use of XLIFF as a best practice for translating DITA. Using XLIFF as your Interchange File Format when translating DITA topics enables exactly what you are talking about.  The idea is that all of the topics referenced by a given map would be transformed into an XLIFF file (XLIFF is a preferred file format for translation providers and is natively consumable by translation tools).

So if fragments within the topic need to be translated the XLIFF file can identify the strings that need to be translated, and lock (but provide for context) the strings that do not need translation. Here's a little sample:

For this topic segment:
<section>
 <title>Electric Guitars</title>
 <p translate="no">Lester William Polsfuss aka Les Paul was
                   a pioneer of the development to the Solid
                   body Electic Guitar and modern recording
                   technologies.</p>
  <p translate="yes">Clarence Leonidas Fender, also known as
                   Leo Fender, moved the development of Electric
                   Guitars into the modern era, with smaller, more
                   portable solid body Electric Guitars.</p>
</section>

This XLIFF segment would trigger the translator to translate the second paragraph, but provide the first paragraph as a locked, for context only topic fragment (note the @state attribute):

<group id="section-3">
 <trans-unit id="title-4">
  <source>Electric Guitars</source>
  <target state="needs-translation" xml:lang="de">Electric Guitars</target>
 </trans-unit>
 <trans-unit id="p-5">
  <source>Lester William
   Polsfuss aka Les Paul was a pioneer of the development to the Solid
   body Electic Guitar and modern recording technologies.
  </source>
  <target state="final" xml:lang="de">Lester William Polsfuss alias Les Paul war ein
   Pionier der Entwicklung hin zur Solidbody-E-Gitarre und moderner
   Aufnahmetechniken.
  </target>
</trans-unit>
<trans-unit id="p-6">
 <source>Clarence Leonidas Fender, also known as Leo Fender,
  moved the development of Electric Guitars into the modern era, with
  smaller, more portable solid body Electric Guitars.</source>
 <target state="needs-translation" xml:lang="de">Clarence Leonidas Fender, also known as Leo Fender,
  moved the development of Electric Guitars into the modern era, with
  smaller, more portable solid body Electric Guitars.</target>
 </trans-unit>
</group>

Hopefully this answer doesn't abstract too far beyond the scenario you had in mind.

- Bryan

-----Original Message-----
From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
Sent: Thursday, August 05, 2010 8:56 AM
To: JoAnn Hackos; Chris Nitchie; Su-Laine Yeo; Helfinstine, David; DITA TC
Cc: Robert D Anderson
Subject: RE: [dita] Cascading of xml:lang attribute

I've not been directly involved with this, but can't you send fragments smaller than a topic for translation if that's all that has changed? Or are other means used to identify just those parts that need the translator's attention?

A topic may have different xml:lang values on different fragments in it. Quotations, citations, and legal requirements for bilingual environments come to mind.

        /B

> -----Original Message-----
> From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
> Sent: Wednesday, August 04, 2010 4:57 PM
> To: Bruce Nevin (bnevin); Chris Nitchie; Su-Laine Yeo;
> Helfinstine, David; DITA TC
> Cc: Robert D Anderson
> Subject: RE: [dita] Cascading of xml:lang attribute
>
> When we automate the process of sending topics out for
> translation, we ask the translators to change the xml:lang
> attribute to the correct languages, which in the CMS
> environment enables the topics to be synchronized correctly
> with the source language topics. It's very important that the
> attribute be placed on every topic correctly.
>
> When topics are changed, we can are able to send only those
> topics for retranslation or, in some cases, only the
> individual strings that have been changed. All of these
> controls helps to reduce translation costs.
>
> The xml:lang attribute at the map level will not have the
> correct effect. The translators do not see the maps.
>
> JoAnn
>
> JoAnn Hackos PhD
> President
> Comtech Services, Inc.
> joann.hackos@comtech-serv.com
> Skype joannhackos
>
>
>
>
>
> -----Original Message-----
> From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> Sent: Wednesday, August 04, 2010 9:09 AM
> To: Chris Nitchie; Su-Laine Yeo; Helfinstine, David; DITA TC
> Cc: Robert D Anderson
> Subject: RE: [dita] Cascading of xml:lang attribute
>
> If the value of xml:lang cascades to a topic that has no
> value set, then it would be mandatory (a strongly advised
> best practice?) for someone or something to set xml:lang on
> every topic to avoid problems. But if we expect every topic
> to have xml:lang set, then there's no reason to have xml:lang
> cascade. By that logic, it should be up to the processor to
> decide what assumptions are appropriate when xml:lang is not
> explicitly specified, and on what basis to make such assumptions.
>
> The descriptive/prescriptive dichotomy isn't apt. Any
> attribute value specifies something descriptively about the
> content, and any attribute value that isn't used for some
> kind of processing has no use case. The value of xml:lang is
> no exception.
>
>       /B
>
> > -----Original Message-----
> > From: Chris Nitchie [mailto:cnitchie@ptc.com]
> > Sent: Tuesday, August 03, 2010 8:50 PM
> > To: Su-Laine Yeo; Helfinstine, David; DITA TC
> > Cc: Robert D Anderson
> > Subject: Re: [dita] Cascading of xml:lang attribute
> >
> > I would think in such a situation, where you have to manage a large
> > number of languages, the only rational process is to mark
> each piece
> > of content with its language. The potential for assigning the wrong
> > language to a piece of content via cascading, processor
> defaults, or
> > any other mechanism is higher in such cases than it is for the
> > customer with only one or two languages.
> >
> > If xml:lang cascaded from maps to topics when there's no explicit
> > xml:lang on the topic, you'd wind up with content in the
> output marked
> > with the wrong language via cascading, and we would have to
> call that
> > valid DITA processing even though it's obviously incorrect. The
> > xml:lang and other locale-related attributes are different
> from other
> > cascading attributes because they are descriptive, not
> prescriptive;
> > they describe the content as it is, not metadata for how it
> should be
> > processed. Topics are in a language, and they're in that
> language no
> > matter what map references them, and no matter whether they specify
> > xml:lang or not. Allowing a map - or anything else - to impose a
> > language setting invites outcomes that are simply wrong. I suspect,
> > but can't say for sure, that the language in the spec about
> processor
> > defaults is there because something has to establish a language
> > eventually, but it's not a very good substitute for
> assigning language
> > markers on your content.
> >
> > Chris
> >
> > On 8/3/10 6:07 PM, "Su-Laine Yeo"
> > <su-laine.yeo@justsystems.com> wrote:
> >
> > > Hi Dave,
> > >
> > > For teams which publish primarily in one language,
> setting a "good"
> > > default for the processor or putting xml:lang in the
> > template is not a big burden.
> > > However, consider a team that publishes in a dozen locales.
> > That team
> > > needs to set the locale parameter for the processor up to a dozen
> > > times and get it right each time. You can automate builds
> to avoid
> > > having to set parameters over and over, but many adopters
> > do not have
> > > automated build processes, especially in the the early
> > stages of adoption.
> > >
> > > The question is whether processors should apply the
> xml:lang of the
> > > primary map *if that is the only place where xml:lang is
> > defined*. Why
> > > should the answer be no? I'm aware that changing the
> > xml:lang on a map
> > > or topic does not change the language of any other sub-topics or
> > > sub-maps. However I donıt see how that (obvious) fact is
> > relevant to this question.
> > >
> > > Cheers,
> > > Su-Laine
> > >
> > >
> > > -----Original Message-----
> > > From: Helfinstine, David [mailto:dhelfinstine@ptc.com]
> > > Sent: Tuesday, August 03, 2010 1:33 PM
> > > To: dita@lists.oasis-open.org
> > > Cc: Robert D Anderson; Su-Laine Yeo
> > > Subject: RE: [dita] Cascading of xml:lang attribute
> > >
> > > Greetings,
> > >
> > > The xml:lang should be considered an attribute set in each
> > document.
> > > There are other language type attributes like @dir and
> > @translate that
> > > are also document attributes. They also do not cascade from
> > map to map
> > > or map to topic or topic to sub topic, etc. These might be
> > important
> > > when processing so it would not necessarily be xml:lang
> alone that
> > > would need to be considered. As has been mentioned, changing the
> > > xml:lang on a map or topic does not change the language of
> > any other sub-topics or sub-maps.
> > >
> > > The comments regarding setting the xml:lang in every
> > document can be
> > > overcome by setting a good processor default. If the
> > processor default
> > > in a French environment is ³fr² then it might be reasonable
> > that the
> > > processor default would be ³fr² unless a different xml:lang is
> > > encountered in a map or topic. If however one of the French
> > documents
> > > were put into a different language map then the processor default
> > > would probably be set to that language. The French author
> > would have
> > > to remember to put the xml:lang=²fr² in the French topic to
> > keep that
> > > from happening. Having the xml:lang=²fr² on the topic tag would
> > > alleviate the problem in the first place. For those users who use
> > > templates, it might be great to include in the template the
> > xml:lang already set to a decent default value. That way ­
> no worries!
> > >
> > > Before the DITA 1.2 the cascading of attributes was not
> > defined. There
> > > was talk of inheritance in DITA 1.1 and there was the one
> > reference to
> > > xml:lang regarding topicref and the actual topic. But as a
> > whole this
> > > topic was not defined rather than DITA 1.2 being a change
> > to the way they behaved.
> > >
> > > Thanks.
> > >
> > > - Dave H.
> > >
> > > Dave Helfinstine
> > > DHelfinstine@ptc.com
> > >
> > > -----Original Message-----
> > > From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> > > Sent: Tuesday, August 03, 2010 2:56 PM
> > > To: Robert D Anderson
> > > Cc: dita@lists.oasis-open.org
> > > Subject: RE: [dita] Cascading of xml:lang attribute
> > >
> > > Thanks Robert.
> > >
> > > We've received some quite strongly-worded comments from
> DITA users
> > > that having to set xml:lang on every single topic file
> would be an
> > > enormous hassle. For the case of a mostly-French document
> > that pulls
> > > in one English topic, it is reasonable to ask users to set
> > > xml:lang="fr" once on the map, and xml:lang="en" once on
> > the English
> > > topic. However I don't see why we would also require users to set
> > > xml:lang="fr" on every French topic if they want those
> > topics to be processed in French.
> > >
> > > I see this as being a substantial change over the DITA 1.1
> > spec which
> > > adds work for users, and I can't see the practical benefit.
> > >
> > > Su-Laine
> > >
> > >
> > > -----Original Message-----
> > > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > > Sent: Tuesday, August 03, 2010 12:33 PM
> > > To: Su-Laine Yeo
> > > Cc: dita@lists.oasis-open.org
> > > Subject: Re: [dita] Cascading of xml:lang attribute
> > >
> > > Trying to remember the discussion of this - I believe that your
> > > reading of the 1.2 spec is correct.
> > >
> > > I think the idea was that the language is a property of the
> > document
> > > itself that travels with the document, and cannot be set or
> > reset from
> > > above. For example, if you have a map with all French
> > topics, but then
> > > reference an existing English topic somewhere else that
> > does not set
> > > xml:lang, the fact that you're referencing it from a French
> > map does
> > > not make the topic French. Following the spec's recommendation to
> > > ensure xml:lang is on the root element of every document
> > helps bypass
> > > this issue and any resulting confusion.
> > >
> > > Robert D Anderson
> > > IBM Authoring Tools Development
> > > Chief Architect, DITA Open Toolkit
> > >
> > >
> > >
> > >              "Su-Laine Yeo"
> > >              <su-laine.yeo@jus
> > >              tsystems.com>
> >             To
> > >                                        <dita@lists.oasis-open.org>
> > >              08/03/2010 03:11
> >             cc
> > >              PM
> > >
> >        Subject
> > >                                        [dita] Cascading
> of xml:lang
> > >                                        attribute
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi everyone,
> > >
> > >
> > > A bug report for the DITA Open Toolkit has raised some interesting
> > > discussion:
> > >
> > >
> > >
> >
> https://sourceforge.net/tracker/?func=detail&atid=725074&aid=3038532&g
> > > roup_id=
> > > 132728
> > >
> > >
> > > Users need to know if they need to set the xml:lang
> > attribute only in
> > > their primary map, or for every topic. Developers of
> > processors need
> > > to know if processors should look at the map when deciding
> > what locale
> > > to use when displaying topics.
> > >
> > >
> > > Say you have a <note> element in a DITA topic that is
> > referenced by a
> > > DITA map. My reading of the DITA 1.1 spec is that language
> > should be
> > > determined as follows:
> > >
> > >
> > > 1) Get xml:lang from the <note> element. If xml:lang is
> not defined
> > > there, get it from the closest ancestor within the topic.
> > >
> > >
> > > 2) If xml:lang not defined in an ancestor of <note> within
> > the topic,
> > > get it from the <topicref> in the map.
> > >
> > >
> > > 3) If xml:lang not defined in the <topicref>, get it from closest
> > > ancestor of the <topicref> within the map.
> > >
> > >
> > > 4) If xml:lang is not defined in any ancestor of the
> > <topicref> within
> > > the map, the processor should assume a default value.
> > >
> > >
> > > However, the draft DITA 1.2 spec contains the sentence ³The
> > @xml:lang
> > > value does not cascade from one map to another or from a map to a
> > > topic², which seems to imply that the language should be
> > determined as follows:
> > >
> > >
> > > 1) Get xml:lang from the <note> element. If xml:lang is
> not defined
> > > there, get it from the closest ancestor within the topic.
> > >
> > >
> > > 2) If xml:lang not defined in an ancestor of <note> within
> > the topic,
> > > the processor should assume a default value.
> > >
> > >
> > > Is this the intention?
> > >
> > >
> > > Su-Laine
> > >
> > >
> > > Su-Laine Yeo
> > > Solutions Consultant
> > >
> > >
> > > JustSystems Canada, Inc.
> > > Office: 778-327-6356
> > > syeo@justsystems.com
> > >
> > >
> > > www.justsystems.com
> > >
> > >
> > > XMetaL Community Forums: http://forums.xmetal.com/
> > >
> > >
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the
> OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > oups.php
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS
> TC that generates this mail.  Follow this link to all your
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php