[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Notes on the acronym proposal
Hello Friends, I've added more notes to Gershon's meeting minutes. Andrzej and Rodolfo in particular, please review the notes. I've also asked Kara W to review the entire proposal since she had not yet read it. We have two proposals in the notes that we need to consider next week. Each Involves adding a third element to our plan. Kara's primary concern seems to be with the post-processing for term extraction. I also wonder if that processing could not be revised to account for the acronym in the expanded form rather than adding complexity to this proposal. 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 joannhackos Skype www.comtech-serv.com
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 Andrzej and Rodolfo's acronym proposal. Kara: 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. Kara 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. JoAnn: Recommendation is when there is no short form, omit the short form element and the long form will be used.//JTH: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. Kara's recommendation would require a language-by-language rule.// 2nd bullet in "Translation Issues": Discussion back and forth... Kara 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.// JoAnn: We can't decide this without Andrzej and Rodolfo. Asked Kara to take a look at the current proposal and consider the suggestion of adding a third element for presentation, or Bruce'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. Gershon and Nick both alluded to quality control issues.// 3rd bullet: //Issue (question for Rodolfo)-- 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?// Kara: This problem would normally not occur, but may occur in list where you would not normally put an article before the acronym. //Here is Bruce's 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 Bruce and Kara asked to make readers aware that the ID values need to be a unique identifier. JoAnn suggested adding a note that there's no mandate for the ID value to match the short term. Bruce: 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: Bruce to send email to JoAnn about the linguistic issue.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]