To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=89147
------- Additional comments from t...@openoffice.org Tue May 18 08:04:58 +0000 2010 ------- AFAIR everything is according to spec. a) As for why Katakana/Hiragana is only listed under 'Format/Change case' has probably historic reasons. (You need to ask UX about that.) The only real difference I see is that Katakana/Hiragana is implemented via simple calls to the transliteration function of the break-iterator, whereas Hangul/Hanja and Chinese conversion are too complex to be handled that simple and thus each have their own dialog and implementation. Another reason is that without a selection Hiragana/Katakana conversion operates on a single word (like everything else in that submenu), whereas the ones for Korean and Chinese text will operate on the whole document. b) About why Chinese translation is available in the menu even even though the underlying text is Japanese (or even English) and similar issues: The spec for Asian language support defines all of them to be enabled if and only if Asian languages are enable in the 'Options/Language Settings/Languages' dialog. That is because those options being enabled or disabled depending on the current selection is too troublesome if you think about documents with hundreds of pages of text. It would require to iterate over all the text in the selection just too check if the text does contain at least one character of Chinese, Japanese or respectively Korean text. Also if no selection is set the Hangul/Hanja and Chinese translation are to operate on the whole text, that is the whole document hast to be checked for respective occurrences. At lest at the time those conversions were implemented the power of most computers has been considered to be too small to handle this in a reasonable time frame for large documents. And even nowadays I believe some user to have pretty limited hardware. c) About the default language being changed to Chinese after applying Chinese conversion: That should also be part of the spec since even text that gets its language attribute from the default language needs to be Chinese after executing the conversion. The reasoning for this is that if you had e.g. a Chinese document that got the wrong Asian language attribute after calling the conversion all the text should be Chinese, even the text that was not in Chinese! The goal of this is that new typed Chinese text will also always get the Chinese language attribute, which might otherwise not always be the case if a text portion gets extended that might have been left with a non Chinese Asian language attribute (even if that would be only the default Asian language). Consider for example a Western number or space that would have been left with a default Asian language set to Korean. However the changing of the default document language should apply to the current document only. Thus, all in all, I do not see anything stated in this issue that does not work as defined. That is, if anything should be changed because of this issue, at least the issue type should be set to something more appropriate than 'defect'. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org For additional commands, e-mail: issues-h...@framework.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
