dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Groups - Issue #12038 - Proposal: Acronyms and other AbbreviatedForms (IssueNumbe12038.html) uploaded
- From: Deborah_Pickett@moldflow.com
- To: dita@lists.oasis-open.org
- Date: Mon, 10 Dec 2007 16:18:13 +1000
gljoseph@yahoo.com wrote on 09/12/2007 07:07:45 PM:
> http://www.oasis-open.org/apps/org/workgroup/dita/download.php/
> 26361/IssueNumbe12038.html
<lq>
The <expanded> form will be a specialization
of the <keyword> element, while the <short> element will be
a specialization of the <data> element. This means that the expanded
term is a normal phrase, while the short form is metadata that is hidden
when processes do not know what to do with it.
</lq>
I question the usefulness of this when the expanded
and surface forms both inherit from <keyword>. A processor
which is not aware of the abbreviated form specialization will generalize
the keywords and display the WMD example as "Weapons of Mass Destruction
Weapons of Mass Destruction (WMD)". (Also, I don't think that
<keyword> inside <keyword> quite survived; do some of those
need to specialize from <text> instead?)
The problems raised in the Translation Issues worry
me greatly. First, I doubt that the list is complete, and I suspect
that there exists some language where even more sinister problems lurk.
Second, this happens even for topics that are not translated: witness
an indefinite article in front of "HTML" when you spell out out
("An HTML document", "A Hypertext Markup Language document").
Obviously the solution is "then don't do that", but since
our documentation is translated to 9 languages, I don't want my authors
(and outsourced translators) to have to know nine sets of things not to
do.
--
Deborah Pickett
Information Architect, Moldflow Pty Ltd, Melbourne
Deborah_Pickett@moldflow.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]