I agree with Gershon,
This is not possible. We do not want
translators who don’t know anything about DITA to add XML markup to
anything.
JoAnn
JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joannhackos Skype
www.comtech-serv.com
From: Gershon L Joseph
[mailto:]
Sent: Tuesday, December 18, 2007
9:07 AM
To: Erik Hennum;
Cc: JoAnn Hackos; Andrzej Zydron;
Ogden, Jeff; Kara Warburton
Subject: Re: [dita] Issue for
unifying acronyms and glossary
Hi Erik,
I thought the surface form was intended to be used by the translators when a
straight translation of the acronym is not appropriate for the target language.
I don't think option 2 is viable. It's not only way beyond current translation
software, it's also going to be an issue for content management systems. They
need to maintain a relationship between the source language and each
translation, to identify what's changed in the source since the previous
translation was done. I'm not aware of any CMS today that would support keeping
track of changing markup in addition to the date of the source content.
I suspect we'll need more time to hash this one out. I can't see us getting to
a final proposal today.
Gershon
----- Original Message
----
From: Erik Hennum <>
To:
Cc: JoAnn Hackos <>; Andrzej Zydron
<>; Gershon L Joseph <>;
"Ogden, Jeff" <>; Kara Warburton
<>
Sent: Tuesday, December 18, 2007 12:02:57 AM
Subject: [dita] Issue for unifying acronyms and glossary
Hi,
Terminology Enthusiasts:
JoAnn and I had a useful conversation about the integrated acronym and glossary
proposal:
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/26484/IssueGlossary12026.html
To refresh, the rationale for integrating the acronym and glossary proposals is
to let user declare a term once for all terminology purposes instead of
declaring the same term in different ways for glossary publication, text
analysis dictionaries, and localization. The principle of defining a thing once
and referring to it multiple times (also known as DRY or Don't Repeat Yourself)
is generally accepted as important for good design in XML. In particular, it
would be quite unfortunate if DITA had two different ways to declare and
reference an acronym and its full form.
While JoAnn is still reviewing the integrated proposal, the conversation
identified one issue: how to handle cases where an acronym or abbreviation is
the preferred term in the original language but doesn't exist or isn't the
preferred term in the target language.
The current integrated proposal envisions that the translator will change the
element for the preferred term from <glossAcronym> to <glossterm>
-- in essence, creating an appropriate glossentry for the target language.
Current translation workbench software, however, typically allows a translator
to edit content but not to change elements.
Two ways of handling this case occur to me:
1. Modify the currently specified expectations for linktext resolution behavior
for glossary references to fall back to <glossFullForm> when the
preferred term is empty and to <glossSurfaceForm> is not appropriate.
This behavior would be a lightweight addition for processes that get the
linktext from <glossSurfaceForm> in some contexts.
2. Expect that translation workbench software will distinguish terminology
declaration markup from content and support translators in modifying term
declaration markup to create a glossentry suitable for the locale but not in in
changing the content markup.
The second approach would seem to provide greater flexibility. For instance,
the second approach can handle the case where an abbreviation is the preferred
form in the original language and the abbreviation exists in the target language
but the full form is preferred. Also, the second approach would be required if
the term is included in a published glossary so the appropriate title is
available to topic processing.
However, the second approach does require implementers of translation workbench
software to add full support for markup editing, which is significantly
different from support for content editing. (In passing, a multi-level
<indexterm> provides another case where the number of levels and thus the
markup might be appropriate to change in translation.)
It would be possible to specify both approaches as expectations. A translation
workbench that supports locale-specific terminology declarations won't create
cases that take advantage of the fallback processing; other translation
workbenches will.
Do you see other ways of resolving this problem?
Erik Hennum
