[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: FW: DITA Proposed Feature # 05
-----Original Message-----
From: Kara Warburton [mailto:KARA@CA.IBM.COM]
Sent: Sunday, April 15, 2007 6:53 PM
To: JoAnn Hackos
Cc: bhertz@sdl.com; Bryan Schnabel; charles_pau@us.ibm.com;
christian.lieske@sap.com; dita-translation@lists.oasis-open.org;
dpooley@sdl.com; dschell@us.ibm.com; esrig-ia@esrig.com; fsasaki@w3.org;
Howard.Schwartz; ishida@w3.org; mambrose@sdl.com; rfletcher@sdl.com;
tony.jewtushenko@productinnovator.com; ysavourel@translate.com
Subject: Re: FW: DITA Proposed Feature # 05
Hello,
I can't attend tomorrow's meeting. I have a few comments below.
You have used the word "definition" to refer to the expansion of an
acronym. Please use "expansion" instead, since "definition" already has
a
specific meaning when talking about acronyms and other term types.
I disagree with this part of Robert Andersson's proposal, and I do not
understand its motivation.
<expanded>International Business Machines (IBM)</expanded>
The comment is "This provides more control over how the text is rendered
to
translators and has much merit. " but there is no explanation of the
merit.
This proposal combines the acronym and expanded form in one element,
against the principles of XML for discreet data types. I do not see what
advantage this brings against the original (Andrzej) proposal from a
processing perspective. For display purposes it would be
programmatically
simple to generate the surface text "International Business Machines
(IBM)"
from the two elements of the original proposal. On the other hand,
having
both a full form and acronym in the <expanded> element is
counter-intuitive
because only the first part is the actual expanded form, and this would
cause problems for downstream terminology data processes. In summary I
support the original proposal for:
<expanded>International Business Machines</expanded>
Regarding the reverse order suggested for inflected languages:
ABS (Anti-lock Brake System)
I suggest we use this order for all languages. It is quite common in any
language and so, if acceptable, it would mean we have the same order for
all languages rather than having to define an exception for inflected
languages.
Kara Warburton
IBM LanguageWare & Terminology
Team Lead, Language & Data Integration
905-413-2170
IBM terminology: http://w3.ibm.com/standards/terminology
LanguageWare: http://languageware.redirect.webahead.ibm.com/
My blog: http://blogs.tap.ibm.com/weblogs/page/kara@ca.ibm.com
"JoAnn Hackos"
<joann.hackos@com
tech-serv.com>
To
<dita-translation@lists.oasis-open.
15/04/2007 06:29 org>, <mambrose@sdl.com>,
PM <bhertz@sdl.com>, "Bryan
Schnabel"
<bryan.s.schnabel@tek.com>,
<charles_pau@us.ibm.com>,
<christian.lieske@sap.com>,
<dpooley@sdl.com>,
<dschell@us.ibm.com>,
<esrig-ia@esrig.com>,
<fsasaki@w3.org>,
<rfletcher@sdl.com>,
"Howard.Schwartz"
<Howard.Schwartz@trados.com>,
<ishida@w3.org>,
<tony.jewtushenko@productinnovator.
com>, Kara
Warburton/Toronto/IBM@IBMCA,
<ysavourel@translate.com>
cc
Subject
FW: DITA Proposed Feature # 05
Here is the complete Acronym proposal from Andrzej.
For tomorrow's meeting.
JoAnn
JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215
303-232-7586
joann.hackos@comtech-serv.com
-----Original Message-----
From: Andrzej Zydron [mailto:azydron@xml-intl.com]
Sent: Sunday, April 15, 2007 2:44 PM
To: JoAnn Hackos
Subject: Re: DITA Proposed Feature # 05
Hi JoAnn,
Please find attached - I was not sure what number to allocate to it.
Best Regards,
AZ
JoAnn Hackos wrote:
> http://www.oasis-open.org/apps/org/workgroup/dita/download.php/15057/I
> ss
> ueNu
>
> Here's one that Chris Kravogel put together JoAnn
>
>
--
email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
PO Box 2167
Gerrards Cross
Bucks SL9 8XF
United Kingdom
Mobile +(44) 7966 477 181
FAX +(44) 1753 480 465
www - http://www.xml-intl.com
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you may not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission. If verification
is required please request a hard-copy version. Unless explicitly stated
otherwise this message is provided for informational purposes only and
should not be construed as a solicitation or offer.
DITA Proposed new acronym element
Add a new 'acronym' element based on an expansion of the extant DITA
'data'
to assist in the resolution and handling of acronyms in source and
target
text within DITA documents.
Longer description
Acronyms are ubiquitous in technical documentation. Although there are
similarities between acronyms and the glossaries, from the localization
and
presentation point of view acronyms are a special case. Acronyms need to
be
expanded in the first encounter within a printed document. In electronic
published documents acronym definitions can also be made available in
the
form of a hyper link or 'tool tip' mechanism.
For translation, acronym definitions need to be presented in the
nominative
case, without any inflection. The best way of doing this using an
automated
mechanism is to place the definition of the acronym in parentheses
immediately following the first occurrence of the acronym, e.g.
Your vehicle is fitted with an ABS (Anti-lock Braking System) and 4WD
(Four
Wheel Drive).
Scope
The proposal is to create an <acronym> element which would be a
specialized
form of the '<data/>' element. The acronym resolution will be via the
conref attribute to the acronym text short and expanded forms, e.g.
<acronym conref="aconyms.dita#abs"/>
The entry in the aconyms.dita file will be:
<acronym id="abs">
<expanded>Anti-lock Break System</expanded>
<short>ABS</short>
</acronym>
This allows for a different acronym for the target languages if
required.
An alternative suggestion from Robert Anderson is to include in the
expanded form the short form declaration, e.g.:
<acronym id="ibm">
<expanded>International Business Machines (IBM)</expanded>
<short>IBM</short>
</acronym>
This provides more control over how the text is rendered to translators
and
has much merit.
Use Case
The authors will enter the <acronym> element for every occurrence of a
given acronym
At compose time, when you are putting together the publication you can
print the full form the first time around, but in parentheses to get
around
any potential problems when translating into inflected languages:
<p>The <acronym conref="aconyms.dita#abs"/> facility will
prevent the car from skidding.</p>
The first occurrence in the publication can be published as:
The Anti-lock Brake System (ABS) system will prevent the car from
skidding in adverse weather conditions.
Subsequent instances can then be rendered as:
The ABS system will provide the driver with feedback via the brake
pedal.
Acronyms can cause problems for inflected languages. In these instances
for
inflected languages the publishing software may use the reverse form for
the first instance:
The ABS (Anti-lock Brake System) system.....
This is perfectly acceptable for inflected languages and gets around
having
a case neutral nominative rendition of the acronym definition in
parentheses.
Technical Requirements
A new <acronym> element needs to be created which a specialization of
the
<data> element.
Costs
Benefits
Acronyms will be handled in a uniform and consistent manner. The
handling
of the acronym will be under the control of the composition software.
The
first occurrence of the acronym can show the fully expanded form. The
text
for both source and target languages will be consistent as it will be
resolved via the conref attribute from a single source.
The resolution of the acronym can be totally under the control of the
composition software so that glossary, tooltip and expanded forms can be
provided as required to meet the end user requirements.
Time required
The addition of the <acronym> element as a specialization of the <data>
element does not require much work..
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]