Translations of Acronyms

Here is a page for the acronyms proposals.

.

Notes on the Translation Subcommittee meeting of 20070618

Discussion of the Acronym Proposal
//I've added additional comments to Gershon's meeting minutes, JoAnn//

4)  Returning business:
 
    4.1 Vote on the final version of A and R's acronym proposal.

        K: Our primary concerns have still not been addressed. The markup is
        not suitable for downstream processing of the content. Issue is the
        extended term is part of the term, which gets in the way of extraction.

        K suggested to work towards finding a new markup that meets both auto
        needs as well as translation needs. Putting the long element in the short
        element because there is no short element will cause downstream processing
        problems. Rather leave the short element empty, then processing will take
        the long form.

        J: Recommendation is when there is no short form, omit the short form
        element and the long form will be used.//J:If the short form is omitted,
 then the long form must be used.//

 //Language-by-language rules
 We have tried to avoided creating language-by-language rules because the
 processing overhead is not trivial. K'srecommendation would require a
 language-by-language rule.//

        2nd bullet in "Translation Issues":

            Discussion back and forth...

            K suggests 3 elements instead of 2, where the third is for
            presentation, which incudes the formatting/punctuation etc. and
            still preserves the short and expanded forms for automated
            processing.

     //Problem with adding an element is the complexity of the decision-making
  for the transltor. Quality of localization is an issue.//
           
            J: We can't decide this without Aand R. Asked K            to take a look at the current proposal and consider the suggestion
            of adding a third element for presentation, or B's suggestion
            of adding an attribute order="short-first | expanded-first" and the
            idea is to have a default setting for the language and allow the
            translator to override the default in specific cases by setting this
            attribute value. We need to note that the translator is trying to
            control the presentation via this attribute (or via the third
            presentation element).

  //Again here, we are concerned with leaving all of this in the hands
  of the translator. Ge and Nboth alluded to quality control
  issues.//

        3rd bullet:
     //Issue (question for R)-- punctuation of the expanded form as
  the first word in a sentence if
  no acronym is available. See the Spanish example in the proposal. What would
  happen if this phrase began a sentence. Would there usually/always be an
  article before the first word of the expanded form?//

            K This problem would normally not occur, but may occur in list
            where you would not normally put an article before the acronym.

     //Here is Bs Note on this issue:
  The <acronym> proposal raises some questions about how to handle
  linguistic phenomena (articles and capitalization).

  The last use case shows an expanded form for SIDA, the Spanish acronym for AIDS.

  We have no way of indicating whether this is ordinarily preceded by an
  article (the, or a declined form of it). I don't know whether one is needed.

  Also, the example mentions the difficulty that in Romance languages such as
  Spanish, the expansion would ordinarily not be capitalized.
  However, at the beginning of a sentence, it would be.
  This is a more general problem about conref-ing terminology into a context
  that requires capitalization.

  As DITA becomes more sophisticated about both terminology and translation,
  it becomes increasingly tempting to provide support for phenomena
  such as capitalization. Any capitalization requirements in the context
  performing a conref might need to be handled in conref processing.


           
 4th issue
     B and K asked to make readers aware that the ID values need
            to be a unique identifier.

            J suggested adding a note that there's no mandate for the ID
            value to match the short term.

            B: We've carefully avoided making language-specific problems.
            What about the issue when a person wants to conref to the beginning
            of a sentence?

            ACTION: B to send email to J about the linguistic issue.

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I