OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-translation message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: Revisions to Acronym proposal




JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joann.hackos@comtech-serv.com
joannhackos Skype
www.comtech-serv.com

-----Original Message-----
From: Kara Warburton [mailto:KARA@CA.IBM.COM] 
Sent: Tuesday, January 22, 2008 7:22 AM
To: Bruce Esrig
Cc: bhertz@sdl.com; Bryan Schnabel; christian.lieske@sap.com;
dpooley@sdl.com; Erik Hennum; fsasaki@w3.org; ishida@w3.org; JoAnn
Hackos; jogden@ptc.com; Michael Priestley; rfletcher@sdl.com;
rmraya@maxprograms.com; Robert D Anderson;
tony.jewtushenko@productinnovator.com; ysavourel@translate.com
Subject: Re: Revisions to Acronym proposal

Hi Bruce,

I think I can comment on the last 2 points. My understanding is that the
glossary XML file is not a reflection of the published format. During
transform processing, the headword ('title' -- <glossTerm>) of the
glossary
entry would be given a published glossary entry with the definition.
Other
items such as part of speech and usage note, etc., would normally be
omitted from the published  glossary.  All the <glossAlt> terms would
also
have an entry in the published glossary, but instead of a definition,
there
would be a "see" reference to the full entry represented by <glossTerm>.
This style is according to industry practice and should be handled by
transform processing.

If one of the <glossAlt> terms has a "preferred" status value, it would
assume the role of the so-called main term and would therefore get the
full
entry and in this case <glossTerm> would have a "see" reference pointing
to
it.

Therefore, in the DITA glossary source, one should not have to
"duplicate"
entries in order to get a headword for each term in a DITA glossentry.

For the people on the list, I would like to just clarify the role of the
"glossStatus" element. It provides two useful functions:
1. Enabling content authors to indicate, among synonyms and variants,
the
term which is preferred and terms which should be avoided. This data can
be
pulled into both controlled authoring software and terminology databases
to
enable controlled authoring, which improves content and benefits
translation.
2. It enables authors to indicate when an abbreviation or an acronym is
actually the preferred term for use. In general domains this is not very
frequent but it does occur. Take for example an abbreviation such as
"ping"
in the computing field. How many people would recognize this concept if
I
used the full form "packet internet groper"? Similarly, in a banking
glossary, if I put the definition of  ATM  under the headword
"Automated
Teller Machine", with a "see" reference from ATM to "Automated Teller
Machine", I would be doing my readership a disservice because I can
almost
guarantee that they will be searching in the glossary for ATM (if there
is
anyone left on this earth who doesn't know this concept) and not the
full
form. They would reach the definition they are looking for in 2 steps
instead of 1 step.
Also in some vertical industries such as telecommunications and
aerospace,
etc., abbreviations are very common and there may be a need to establish
precedence of these terms over their corresponding full forms in content
authoring and translation.

In the case of ping and ATM, simply marking the <glossAcronym> with a
"preferred" status value solves these issues.

Kara Warburton
IBM Terminology
905-413-2170

IBM Intranet links:
Terminology WIKI: https://w3.webahead.ibm.com/w3ki/display/IBMterm/Home
IBM terminology: http://w3.ibm.com/standards/terminology
Terminology blog: http://blogs.tap.ibm.com/weblogs/page/kara@ca.ibm.com


 

             Bruce Esrig

             <esrig-ia@esrig.c

             om>
To 
                                       Robert D Anderson

             22/01/2008 04:01          <robander@us.ibm.com>, "JoAnn

             AM                        Hackos"

                                       <joann.hackos@comtech-serv.com>

 
cc 
                                       <bhertz@sdl.com>, "Bryan
Schnabel"  
                                       <bryan.s.schnabel@tek.com>,

                                       <christian.lieske@sap.com>,

                                       <dpooley@sdl.com>,

                                       <fsasaki@w3.org>,

                                       <rfletcher@sdl.com>,

                                       <ishida@w3.org>,

                                       <rmraya@maxprograms.com>,

 
<tony.jewtushenko@productinnovator. 
                                       com>, Kara

                                       Warburton/Toronto/IBM@IBMCA,

                                       <ysavourel@translate.com>, Erik

                                       Hennum <ehennum@us.ibm.com>,

                                       Michael

                                       Priestley/Toronto/IBM@IBMCA,

                                       jogden@ptc.com

 
Subject 
                                       Re: Revisions to Acronym proposal

 

 

 

 

 

 





Thanks again for the copy ... I have four remarks.

3a. Is there an enumeration value in order to instruct that the first
occurrence be of the form "expansion (acronym)"? If not, authors who
want
this format will have to know which occurrence is the first. If they
must
explicitly write "<abbreviated-form> (<abbreviated-form>)", then they
must
do so at the first occurrence.

3b. Translators should not fill in the expanded form where the acronym
is
requested if my suggestion in 3a is implemented. Otherwise, "expansion
(expansion)" will result at the first occurrence in the translation.
There
seems to be a process issue, which is that translators need a way to
indicate that they have completed translating a glossary entry,
including
the acronym. An alternate way of supporting that need would be to
provide
an explicit attribute that the translator sets to indicate that the
acronym

has been left empty deliberately. Then an empty attribute is
consistently a

sign that the expanded form should be used.

1. Are there controls to permit alternate titles (aside from the
expanded
form) for the glossary topics in the generated glossary? These would
indicate that in the generated glossary, the topic should appear under
the
expanded form, under the abbreviated form, or both. If the abbreviated
form

is not unique, the control could be on that element so that multiple
instances could be generated. This mechanism assumes that there is a
capability to sort the generated glossary topics by title.

6. Is there a see/see-also/compare mechanism for glossary entries as was
discussed for index entries?

Best wishes,

Bruce

At 07:14 PM 1/21/2008, Robert D Anderson wrote:

>Hi,
>
>As we agreed at today's call, I had a follow-up meeting with Erik
Hennum
to
>discuss the translation group's suggestions. As a result, there are now
>several concrete suggestions as changes to the original proposal (
>http://lists.oasis-open.org/archives/dita-translation/200801/msg00003.h
tml
>). I'll list the specifics below, and then send a more general note to
the
>main TC list.
>
>1. The group suggested that expanded forms should come first. So, the
>proposal can remove glossAcronym and glossAbbreviation as options for
the
>main 'title' of the glossary topic. Instead, the expanded term will be
>located first, using the glossterm markup that is used for every
glossary
>entry. The glossAcronym or glossAbbreviation are listed after that as
>alternate versions of the expanded term.
>
>2. The glossFullForm (also called glossExpandedForm) element can be
>removed, because the expanded form of the term is already encoded as
the
>term.
>
>3. When authors reference an acronym inline with the <abbreviated-form>
>element, the rules will follow those defined by the translation
>subcommittee:
>- The first instance in one context will pull text from the
>glossSurfaceForm
>- Future instances will pull from the first glossAcronym (similar to
>today's discussion, in that we cannot prevent many but users should
only
>have one)
>- The consensus on today's call was that if an acronym is not available
in
>a target language, the expanded value should be specified. However, if
the
>acronym is empty because a translator removed it, the primary term (the
>expanded form) should be used.
>
>4. The existing <glossStatus> element has a new value of "preferred" in
the
>enumeration. This can be used to indicate that an alternate form (such
as
>an acronym) is the preferred representation of a term. This is still
not a
>required element for acronym processing. If a <term> element is used to
>reference a glossary entry, the following rules will be used when
>retrieving the term:
>- As a first choice, the form of the term marked "preferred" will be
>retrieved
>- If no term is marked preferred, or if the preferred term is empty
>(possibly because it does not exist in a target language), the primary
term
>will be retrieved
>- NOTE: using <abbreviated-form> will always use the processing rules
>defined in #3, regardless of what is marked "preferred"
>
>5. As mentioned at the call, the language in the proposal about
acronyms
>needs to be cleaned up to include all of the translation issues
described
>in the original proposal.
>
>Please send any comments back to the list. Unfortunately Erik hasn't
had
>time to review this, so if I mis-characterized something he may be
speaking
>up soon.
>
>Robert D Anderson
>IBM Authoring Tools Development
>Chief Architect, DITA Open Toolkit
>(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]