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.
Notes on the acronym proposal June 27 2007
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.