|
[
Permalink
| « Hide
]
Robert Weir added a comment - 28/May/09 05:06 PM
per 1/12/09 TC call: Dennis may offer specific proposal for Patrick
Public Comment Registry v18 #193
The situation pointed to in this comment persists in ODF 1.2 Part 1 cd02. I would simplify the recommendation to simply add English text to the titles of sections now identfied with only element tags and attribute names in the TOC and in sections deeper than the TOC goes. The use of element tags and attribute names can remain, in conjunction with an account of the prefixes in section 1.3. The reason for the English text, even though mainly repetitive of the element name, is to provide something translators can work with, since the element names and attribute names must not be translated. Another motivation for translated text is to ensure support for assistive technologies, such as text-to-speech assistance that is able to speak the title in its translated (or even plain-Engish) form as well as providing an English aid with regard to the element tag and the attribute name. Well, but if you look at the prior English text titles in ODF 1.0/1.1, you will find that they are not terribly informative or always accurate. That wasn't a defect of those versions but always the case when one tries to select a term in any language to represent a token from a formal language. Some of us will prefer one term over another or think that it is more accurate. By using the element and attribute names, the section titles become far more precise than is otherwise possible.
There has been no demonstration that assistive technologies cannot read element and attribute names. I assume that anyone working with markup, as markup, would have technologies that can read markup. Use of element/attribute names simply saves the translators the trouble of trying to translate those parts of the standard. Patrick, the whole point of having the natural-language titles along with the formal tag and attribute names is that the natural-languge titles *can* be translated and also can be spoken in the translated-to language by assistive technologies. The formal tag and attribute names must not be translated and their pronunciation will either be spelled or spoken in English. Please note that I am not proposing that the formal tag and attribute names be removed from titles, I am proposing that they be supplemented by natural-language descriptive titling.
I am not recommending what the natural-language titles should be. Presumably one can do better than the ODF 1.0/1.1 ones if that is a problem? (Although similarity might be good in support of those folks who struggle with figuring out where we have moved or lost stuff in the new organization.) It seems to me that we are going around in circles on this one and we need to elevate this to a policy question concerning the value and use of titles in the headings of the specification and in the table of content (and in an index if anyone were ever so bold). [Note: I have a separate concern that the current organization over-emphasizes schema and the XML-level syntax to the exclusion of the model that the XML structure carries, but I think the horse is already out of the barn on that one.] I don't see an issue with English spoken element names. They are English names, regardless whether they spoken or read. Translations of the specification only have to make sure they don't change the language information. I have further seen other specifications of XML bases formats that use element and attribute names as heading. At least XSL-FO does that. I also believe that it is in many cases not trivial to find a good natural language heading that is short enough.
My suggestions would be to close the issue, but to re-open it if we get more complains regarding the headings during a public review. I have set the component to "general" and "fix for" to ODF 1.2 in order to mark the issue as classified. My preference however is to keep the headings as they are.
I spoke to Murata-san about the difficulty for translation and understanding the organization that a TOC consisting of only untranslatable items imposes. This was an informal discussion. However, there was also difficulty in translating the TOC of earlier editions, because they were not necessarily written to be sensible to a translator in an easy way.
So this might be a more complex issue. I don't think I would close it, because it will impact all situations where transposition into a national standard is of a translated version. Element and attribute names are never translated, regardless whether they occur in heading or a description. So, I would think it is absolutely valid to keep them untranslated. This may even be a better approach then translating headings that contain just a few keywords where it may be difficult to translate them without having the context.
However, there is a translation policy at http://www.oasis-open.org/about/translation_policy.php My reading of this policy is that translations may amend the element names and attributes with some descriptive text if that is helpful, because this would be a non substantive change. My suggestion therefore still is to close this issue and to reopen it only if we get specific complains about the element and attribute name headings. Well, on one hand I am not unsympathetic to the concern voiced by Makoto and seconded by Dennis but ease of translation would always be judged relative to some target language. That is to say that some terms would be easier to translate into one target language than another and we would have to favor one language over another in order to judge the fitness of any term for its ease of translation.
My conclusion from that is having non-translatable terms for headings actually puts all target languages on an even footing and in fact allows them to map from one translation to another, insofar as they use supplemental text in addition to the untranslatable headings (mapping between the non-translatable headings). The question then becomes how consistent they are in their translations, something the ODF TC is uniquely not qualified to judge. If we have been inconsistent in our language usage (which would increase or even prevent a meaningful translation into any language), or if we have been unclear, ambiguous, or simply failed to define some case, those are all issues that should be raised for specific cases. The ODF Adoption TC could take on as a project producing versions of the TOC with added foreign language descriptors in various languages. Pick the top ten or so languages. That would make a nice offering along side the final versions of the various parts of ODF 1.2. But I have to agree with Michael here that the TC should close this issue unless we get something specific on a particular part of the text. Do note that in ODF 1.0 we did have prose text for headers that was, at least to me as an English speaker, not terribly descriptive nor intuitive. Nor would it have helped for most translations. The problem is that any terms we choose are going to be closer or farther away for any given person reading the text, depending upon their skill with the language and the technology. That was one of my motivations for suggesting the element/attribute names as headers. If you work with the format, at least those are recognizable across all languages of all developers working with the standard. I was not proposing elimination of the attribute and element names in the headings, nor the notation used for that. I was thinking more of supplemental text after the initial part that would be translatable and might provide something useful to readers of translations..
My understanding of the difficulty with the Japanese translation of the IS 26300 TOC has to do with the noun phrases apparently being very difficult without knowing the subject matter. I like the provisions of the translation policy. The only question for me is whether providing such English supplementary information is more helpful than not having any supplemental information in the titles. Although I am in no position to determine that, my preference, all else considered equal, would be to do something pro-actively helpful in this regard. We can of course wait until public review to see what the response to the titles in ODF 1.2 will be. I would not close this issue; we need a way to keep our eye on it. Perhaps it should be resolved pending public review and not applied until we find out what the future brings. At October 12th meeting the TC agreed to defer this issue to ODF-Next
|
|||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Minor
Public Comment: OpenDocument 1.2v7-02: Table of Contents