OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
Back to discussions
Expand all | Collapse all

Cascading of xml:lang attribute

Andrzej Zydron

Andrzej Zydron08-05-2010 08:34

Andrzej Zydron

Andrzej Zydron08-05-2010 08:58

  • 1.  Cascading of xml:lang attribute

    Posted 08-03-2010 19:21 
    









    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&group_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/
    


    


    


     


  • 2.  Re: [dita] Cascading of xml:lang attribute

    Posted 08-03-2010 19:34 
    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"


  • 3.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-03-2010 20:01 
    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


  • 4.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-03-2010 20:34 
    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


  • 5.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-03-2010 22:12 
    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


  • 6.  Re: [dita] Cascading of xml:lang attribute

    Posted 08-04-2010 00:50 
    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"


  • 7.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-04-2010 15:09 
    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


  • 8.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-04-2010 20:57 
    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


  • 9.  Re: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 08:34
      |   view attached

    Attachment(s)

    vcf
    azydron.vcf   240 B 1 version


  • 10.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 15:57 
    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


  • 11.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 18:18 
    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:

    
 
 
    Lester William Polsfuss aka Les Paul was
                   a pioneer of the development to the Solid
                   body Electic Guitar and modern recording
                   technologies.
    
  
    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.
    

    

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):



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

- Bryan


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 12.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 18:54 
    Hi Bryan,

Now that you are mixing DITA & XLIFF, something I really like very much, let
me point you to an article about using XLIFF to translate DITA projects.
This article is available at
http://www.maxprograms.com/articles/ditaxliff.html 

Best regards,
Rodolfo
--
Rodolfo M. Raya


  • 13.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 19:47 
    No, that's just what I had in mind, Bryan. Thanks! I've been aware of XLIFF for some time, without really looking into it.

The DITA 1.2 spec talks about this issue at "2.1.3.9.1 The @xml:lang attribute". In particular, it says: "The @xml:lang value does not cascade from one map to another or from a map to a topic...." So a value of @xml:lang that is set in a map applies only to content that is immediately contained within the map, such as a title.

Su-Laine's discussion looks at cascading, a top-down notion, from the other direction, bottom up. If @xml:lang is unspecified on some element (a note, in her example), look to the parent element, and do so recursively within the topic, but don't look outside the topic to the map. If no value is set anywhere in that walk up the DOM, assume a default.

I suppose a processor in fact might more efficiently work from the top down. When you encounter an element with @xml:lang set, push the current value onto a stack and use the new value on down the DOM from there until it's overridden or you exit the current branch dominated by the element that carried that value; whereupon take the earlier value back off the push-down stack. When you exit a topic, the last value that you can take off the stack is the system-set default.

(BTW, I just noticed a couple of typos in the section on use with @conref/@conkeyref: "If the reference element does not have an explicit value for the @xml:lang attribute, the effective value for its @xml:lang attribute is determined by using the standard @xml:lang inheritance from the referenced source.." Should be referenced element, and a single period. Do I have to go make a formal comment?)

Su-Laine was reporting that users don't want the overhead of setting @xml:lang on every topic. The spec seems to suggest that this be automated in some way ("applications should") but also makes authors responsible ("authors are urged"):

"Applications should ensure that every highest level topic element explicitly assigns the @xml:lang attribute. Authors are urged to set the @xml:lang attribute in the source language so that the translator may change it in the target language. Because some translation software does not permite translators to add elements, the absence of the @xml:lang element from the source language may result in higher administrative costs for translation." (I assume that "may change it in the target language" means "may change it in a copy (?) of the topic in which the content is translated to the target language")

This gives one strong reason why users might want to bite the bullet and find a way to tag every topic. There is also the issue of sharing content to an environment where a different default language prevails.

	/B 

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 14.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-06-2010 19:49 
    Hi everyone,

I went back to the DITA users who had told me they didn't want to have to put xml:lang on every topic, and they more or less agreed that putting xml:lang on every topic would not be a huge burden. So I believe we have consensus, which we didn't have before, on the following points:
- Setting xml:lang on each topic will assist in reuse across maps, faceted search, and possibly authoring, and is strongly recommended.
- Setting xml:lang on each topic is not too much of a burden for adopters.

Yay :)

However:
- Accidents happen. If a team tries to put xml:lang on every topic but fails in 0.1% of cases, that is approximately one error every 500-1000 pages. 
- Some processors treat xml:lang as cascading. With the current wording of the draft 1.2 spec, these processors would be required to stop this behavior. 
- There are teams with legacy content that does not have xml:lang on every topic, because they produce single-language deliverables and their processors have thus far picked it up from the map.

A good point has been raised that the map might not have the correct xml:lang for describing the language of a topic that doesn't itself include xml:lang. However if the xml:lang in the map is different from the processor's default, which is more likely to correctly describe the language of the topic: the map, or the processor default?  The processor default is more likely to be correct if we assume that a topic that does not declare xml:lang is likely to be in English. However in an environment where people are making an effort to declare xml:lang in all topics including English ones, I would think that accidental omission of xml:lang would be equally likely for all languages.

David H. said that he'd be OK with having a processor pick up the xml:lang on the map and using it to set the processor default. This seems to me to be functionally equivalent to having the xml:lang attribute cascade.

The draft 1.2 spec currently says:
"The @xml:lang value does not cascade from one map to another or from a map to a topic, and an @xml:lang value specified in a map does not override @xml:lang values specified in other maps or in topics. "

I propose changing this to:
"Processors may treat the @xml:lang value as cascading from one map to another or from a map to a topic. An @xml:lang value specified in a map may be used if @xml:lang is not defined in child maps or topics. However, an @xml:lang value specified in a map must never override explicit @xml:lang values specified in other maps or in topics. "

How does that sound? BTW, the draft 1.2 spec already has plenty of wording to encourage people to set xml:lang on every topic.

Su-Laine



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 15.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-09-2010 14:12 
    Hi Su-Laine,

> David H. said that he'd be OK with having a processor pick up the
> xml:lang on the map and using it to set the processor default. This
> seems to me to be functionally equivalent to having the xml:lang
> attribute cascade.

I don't think that is actually functionally equivalent - at least, if I
read David's words very literally. I think David is suggesting that the
xml:lang attribute on the primary map element itself - that map being the
starting point of this information set - could establish a default for the
entire information set.

If an attribute cascades, then it may be reset at different levels in the
map. If one branch is in English, and one branch in Russian, different
values would cascade from that point, and those branches could override the
original value set at the map level.

David - am I right in seeing a distinction between your suggestion and this
interpretation? Were you suggesting that the default come from the map
element in the main map, the map element in any referenced map, or (as with
other cascading attributes) any level of any map?

> I propose changing this to:
> "Processors may treat the @xml:lang value as cascading from one map
> to another or from a map to a topic. An @xml:lang value specified in
> a map may be used if @xml:lang is not defined in child maps or
> topics. However, an @xml:lang value specified in a map must never
> override explicit @xml:lang values specified in other maps or in topics.
"

I'm not entirely comfortable with that, because to me it reads exactly like
our other definitions of cascade, except that it's a may instead of a must.
If we do end up declaring this type of cascade, I'd prefer to simply state
that it may cascade, rather than redefining cascade behavior.

Personally I'm more comfortable with David's suggestion (as I read it),
which seems closer to the spec intent. The spec currently refers to a
processor default, which to me implies a single value for all topics that
do not specify xml:lang. I think it's logical to get that default from the
root element of the map, just as it's logical to get the default from a
setting in the processing software. However, if the value cascades, we may
end up with several defaults, depending on where in the map a topic is
referenced.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

"Su-Laine Yeo"


  • 16.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-09-2010 14:25 
    The xml:lang attribute doesn't--and shouldn't--cascade
(for a variety of reasons discussed in the past).

We shouldn't be saying anything about processor defaults
in the standard other than to say that they are implementation
dependent.

Since generated text is usually going to be in the target
language and generated text is usually defined in a stylesheet,
one reasonable processor default is to do something based 
on the stylesheet being used.

Another reasonable processor default is to use the system
locale value.

I think all Dave was saying was that yet another possible
processor default is to do something based on some value
in the primary map.  But I believe he was only making the
point that there are multiple ways by which a processor
could reasonably determine an implementation dependent
default in the unrecommended case that a topic is missing
an xml:lang assignment.

We do not want to be suggesting that cascading xml:lang
values is the correct--or even reasonable--thing to do.

paul

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 17.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-27-2010 01:16 
    In the TC meeting a couple of weeks ago I think we came to consensus on the following:
1) @xml:lang does not cascade from maps to topics
2) It is reasonable for a processor to set its default language for processing by looking at the @xml:lang value on the primary map file

Currently the spec only mentions #1, so people who unlike us have not spent 10 hours combing over difference between cascading and setting a default may be confused by a processor which implements the behaviour described in #2.

Page 77-89 of the PDF file in CD03 currently says:

"The @xml:lang attribute specifies the language (and optionally the locale) of the element content. The @xml:lang
attribute applies to all attributes and content of the element where it is specified, unless it is overridden with @xml:lang
on another element within that content. When no @xml:lang attribute is specified, the processor should assume a
default value."

I propose changing this to:

"The @xml:lang attribute specifies the language (and optionally the locale) of the element content. The @xml:lang
attribute applies to all attributes and content of the element where it is specified, unless it is overridden with @xml:lang
on another element within that content. If no @xml:lang attribute is specified in a given map or top-level topic, the processor should assume a
default value. The default value of the processor may be fixed, or it may be derived from a run-time parameter, configuration file, other setting, or from the content itself, such as the @xml:lang attribute on the primary map file."

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/




    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 18.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-27-2010 15:17 
    I'm mostly okay with the wording, but we have to be very
careful about our use of terminology that we don't make
things more confusing.  Comments below.

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 19.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-27-2010 23:27 
    Good points Paul and Bruce. Latest version:

"The @xml:lang attribute specifies the language (and optionally the locale) of the element content. The @xml:lang attribute applies to all attributes and content of the element where it is specified, unless it is overridden with @xml:lang on another element within that content.  If the @xml:lang attribute on the document (outermost) element  of a map or of a top-level topic has no value, the processor should assume a default value. The default value of the processor may be either fixed, configurable, or derived from the content itself, such as the @xml:lang attribute on the primary map file. As the default value of a processor may be fixed, it is strongly recommended that the @xml:lang attribute be set on each map and top-level topic."

Cheers,
Su-Laine


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 20.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-29-2010 17:30 
    I like this version of the reworked paragraph.

Cheers,
Gershon



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 21.  RE: [dita] Cascading of xml:lang attribute

    Posted 09-01-2010 15:14 
    Looks good. Thanks! 

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 22.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-27-2010 15:53 
     > The default value of the processor may be fixed, or it may be ...

The challenge with a list is being absolutely certain that it is covers everything that imaginative implementers might come up with.

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 23.  RE: [dita] Cascading of xml:lang attribute

    Posted 08-04-2010 13:31 
    Greetings,

I think perhaps there is a little terminology issue here.

What you are considering is how a processor default might be set by a processor. A good processor default might be the xml:lang on the main map. It could come from a style sheet, or a parameter sent in to a processor, or some other mechanism.  I think those are all great ideas, and any processor of DITA could choose one or more of these to get a good default for processing. Because there will always be the case where what the processor is looking for is not defined, so some fallback assumption needs to be made at some point.

Cascading of attributes is a DITA defined process in the DITA 1.2 spec. By saying that xml:lang should cascade from map to maps and maps to topics is a different mechanism and part of the language standard. That is where the issue arises as the language standard shouldn't need to be changed to accomplish this.

If we changed this topic to "setting a processor default for xml:lang" from "Cascading of xml:lang attribute", I think that might be a better title.

And if you get the processor that automatically changes the language of the topic by just changing the xml:lang attribute, then please sign me up for one too. :-)

Thanks.
- Dave H.
 
Dave Helfinstine
DHelfinstine@ptc.com



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 24.  Re: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 08:40 
      In my opinion the answer should be "No" because it encourages bad 
practice. Let's say you create 200 or so files and rely on the setting 
of xml:lang in 10 or so maps. Then you need to usethe same files with 
different maps having a different setting for xml:lang. Now you discover 
that you have to add the xml:lang setting in hundreds of files. I would 
prefer to discover the bad practice after creating one or two files 
rather than 200.

Different users will prefer different defaults, so whatever choice is 
made, it will not suit everybody - but I think 'erring' on the side of 
encouraging good practice is the correct choice.

Regards,

Doug Morrison
Information Architect
http://dita4all.com


On 03/08/2010 23:07, 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


  • 25.  Re: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 08:58
      |   view attached

    Attachment(s)

    vcf
    azydron.vcf   251 B 1 version


  • 26.  Re: [dita] Cascading of xml:lang attribute

    Posted 08-05-2010 09:20 
    
  
    
  
  
    Hi Andrzej,

    I agree. I was thinking of a phase before automation, where there
    may be a range of languages, and someone who knows only a few of
    them has to make a stab at guessing which language is which because
    the need for xml:lang is discovered rather late in the day. I
    suspect that your assertion about humans being inherently error
    prone and unreliable would be quickly confirmed. One hopes that the
    originator of each document will normally be in a much better
    position to correctly assign xml:lang attribute!
    
    Regards,

Doug Morrison
Information Architect
http://dita4all.com


    On 05/08/2010 09:57, Andrzej Zydron wrote:
    
    4C5A7D16.3090100@xml-intl.com" type="cite"> Hi
      Doug,

      In a proper production system this should be totally automated as
      part of the translation workflow. It should not reply on humans,
      who we know are inherently error prone and unreliable!

      Best Regards,

      AZ

      On 05/08/2010 09:39, Doug Morrison wrote:
      
     In my opinion the answer should be "No"
        because it encourages bad practice. Let's say you create 200 or
        so files and rely on the setting of xml:lang in 10 or so maps.
        Then you need to usethe same files with different maps having a
        different setting for xml:lang. Now you discover that you have
        to add the xml:lang setting in hundreds of files. I would prefer
        to discover the bad practice after creating one or two files
        rather than 200.

        Different users will prefer different defaults, so whatever
        choice is made, it will not suit everybody - but I think
        'erring' on the side of encouraging good practice is the correct
        choice.

        Regards,

        Doug Morrison
        Information Architect
        http://dita4all.com


        On 03/08/2010 23:07, 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
                                                
    
                                                

    
---------------------------------------------------------------------
        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
      

      
    
---------------------------------------------------------------------
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


Related Content