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