Issue for unifying acronyms and glossary

[Erik Hennum <ehennum@us.ibm.com>]

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
ehennum@us.ibm.com