Apache OpenOffice (AOO) Bugzilla – Issue 89147
Wrong Language in Tools/Language
Last modified: 2014-02-04 19:22:29 UTC
I selected Japanese as the asian language I want - I'm studying Japanese at the moment. In Tools/Language, you get the options for "Hangul/Hanji Conversion" and "Chinese Translation", whereas I should be getting Kana/Kanji Conversion and Japanese Translation (or nothing). Under Format/Change Case, Hiragana and Katakana appear as expected. NOTE: This issue also appears in 2.4
I get the same issue (I'm also learning Japanese). I also notice when you end up selecting the "Chinese Translation", under "Tools --> Options --> Language Settings --> Language" the "Default Languages for Documents" for "Asian" is reset from "Japanese" to "Chinese(simplified)" and the Format --> Change Case options are still Hiragana and Katakana, even though the default Asian language has been reset to Chinese. I'm using a recent build of OpenOffice (v 3.0.0) Writer on Vista, although I believe the latest version is now 3.0.1, I haven't tested it there. Since this feature doesn't really affect the overall functionality and robustness of OpenOffice writer and seeing how most people who use OpenOffice probably speak and write in english, this probably wouldn't be considered a very high priority issue unfortunately. Nonetheless, it's still an ideal feature if OpenOffice products are to be used by anyone. Perhaps Japanese is yet to be fully implemented and OpenOffices assumes Chinese is the Default Language for Asian or this is a serious bug. Ideas for future testing would be to try to see if other Asian languages are fully implemented or even common European languages like Italian or French.
Thomas, any opinion about this one?
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'.
It seems that at least everything works as designed. This doesn't mean that the design is correct. But the design isn't what is made in development only. Thus I reassign this issue to someone from the ux team. Frank, please either handle this issue or forward it to the ux discussion list.