Issue 39017 - Hangul/Hanja conversion doesn't work well in multiple languages .
Summary: Hangul/Hanja conversion doesn't work well in multiple languages .
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: 680m65
Hardware: All All
: P4 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2004-12-15 06:58 UTC by
Modified: 2013-08-07 14:38 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

The test file for this issue . (5.41 KB, application/vnd.sun.xml.writer)
2004-12-15 07:01 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description 2004-12-15 06:58:24 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 .
Comment 1 2004-12-15 07:01:21 UTC
Created attachment 20529 [details]
The test file for this issue .
Comment 2 IngridvdM 2004-12-15 12:47:50 UTC
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.
Comment 3 karl.hong 2004-12-17 00:52:43 UTC
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.
Comment 4 thomas.lange 2005-01-04 15:36:39 UTC
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. 
Comment 5 thomas.lange 2005-01-04 15:37:17 UTC
Adding me and Karl to cc list.
Comment 6 karl.hong 2005-01-04 19:53:57 UTC
Karl->TL: You could use the code in i28900 to detect Korean characters.


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.
Comment 7 falko.tesch 2005-01-05 08:53:56 UTC
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).
Comment 8 falko.tesch 2005-01-05 08:55:04 UTC
FT->TL: Re-assigned to you since Karl posted a fix already.
Comment 9 thomas.lange 2005-01-05 09:01:37 UTC
As agreed with FT prio lowered to 4.
Comment 10 andreas.martens 2005-04-01 14:19:43 UTC
Target changed.
Comment 11 andreas.martens 2005-05-25 09:24:57 UTC
Considering the effort, the priority, the risk and our resource planning I've to
retarget this issue to OOo Later.