Apache OpenOffice (AOO) Bugzilla – Issue 39017
Hangul/Hanja conversion doesn't work well in multiple languages .
Last modified: 2013-08-07 14:38:26 UTC
[Reproduce steps] 1. Open attached file 2. Set focus in the head of the file 3. Tools/Language/Hangul-Hanja-Conversion The Japanese character is selected now . [Expected result] The Korean character should be selected . It is last 2nd character . BTW , in 645m51 build 8820 , it works fine .
Created attachment 20529 [details] The test file for this issue .
The attached document is somehow wrong because the japanese characters have the wrong language assigned. They are indicated as 'Korean' and not as 'Japanese'. If you do assign the language 'Japanese' instead (Format/Character/Font/Asian etxt font) than all works as expected. IHA->Karl: I am not sure wether the current behaviour is the most correct one or not. Is it possible that you do a more complex detection here and should there be a more complex detection? If so please take over otherwise set this bug to WONTFIX or INVALID maybe. Thanks.
We could detect kana as Japanese and Hangul as Korean. But since we have three big category, Latin, Asinan and Complex, how to handle these small language category will be a big change in language setting. Back to behaviour this issue described, it is not correct. Since those Japanese characters do not exist in Korean dictionary, they should be skipped. Karl->TL: From m64, the skip function is broken, could you take a look? getConversions() does return no-found status, but writer still picks up empty list and brings up dialog box.
TL->FT: It was our latest feature to stop at the first Korean character even if that one has no conversion in order to open the dialog and allow the user to change the conversion direction there. Also note that this happens only for the very first encountered character that is formated Korean. Any Japanese text formated Korean following later does not show that problem Please take over. TL->Karl: Maybe we just need another method / flag provided by you that could be used to check if it really was Korean text when we are about to open the dialog in order to just skip that.
Adding me and Karl to cc list.
Karl->TL: You could use the code in i28900 to detect Korean characters. Korean: USCRIPT_HAN + USCRIPT_HANGUAL Chinese: USCRIPT_HAN Japanese: USCRIPT_HAN + USCRIPT_HIRAGANA + USCRIPT_KATAKANA USCRIPT_HAN is the overlap part for CJK languages, it is called Hanja in Korean, Hanzi in Chinese and Kanji in Japanese. You could not tell what CJK language it is from glyphs. Hangual is for Korean only while Kana (Hiragana+Katakana) is for Japanese only. So if you exclude Kana, or only include Han and Hangual when popup the dialog, people could not complain it does Korean conversion on other languages.
FT: Here's the comment from the user Experience side: Culturally there is a long-standing animosity between Korean and Japan. So from a UX (and cultural) point of view it does not make a good impression if StarOffice would consider Japanese characters as Korean Hangul/Hanja (even that this is based on an ill-formatted document; see Ingrid's comment above). On the other hand it is very unlikely that a Korean document starts with Japanese characters in real life. So the above issue will only occure very seldom. Nevertheless I vote for fixing this behaviour the way, that we only(!) stop at "real" Korean characters (and not on Asian characters that wrongly carry the Korean language attribute).
FT->TL: Re-assigned to you since Karl posted a fix already.
As agreed with FT prio lowered to 4.
Target changed.
Considering the effort, the priority, the risk and our resource planning I've to retarget this issue to OOo Later.