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:]
> 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.
>
> Skype joannhackos
>
>
>
>
>
> -----Original Message-----
> From: Bruce Nevin (bnevin) [mailto:]
> 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:]
> > 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"
> > <> 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:]
> > > Sent: Tuesday, August 03, 2010 1:33 PM
> > > To:
> > > 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
> > >
> > >
> > > -----Original Message-----
> > > From: Su-Laine Yeo [mailto:]
> > > Sent: Tuesday, August 03, 2010 2:56 PM
> > > To: Robert D Anderson
> > > Cc:
> > > 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:]
> > > Sent: Tuesday, August 03, 2010 12:33 PM
> > > To: Su-Laine Yeo
> > > Cc:
> > > 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
> > > <>
> > > 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
> > >
> > >
> > >
> > > 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
>
>
