Apache OpenOffice (AOO) Bugzilla – Issue 53593
Implement an "Asian Language Auto detection" for Language coversion
Last modified: 2013-02-07 21:54:29 UTC
Reproduce Steps：1. Choose Tools --> Language --> Hangul/Hanja conversion Expected Result：Language conversion should be successful Actual Result：Language coversion is failed.
Reassigned to SBA.
Created attachment 35536 [details] example where it won't work
Created attachment 35537 [details] example where it will work
I suspect that this problems describes the problem in the first attachment. If the hangul text is not actually set to language Korean, then it's not detected as Hangul when an attempt to trigger the conversion dialog is made. If Korean is set on some text, then it'll appear. Don't know if this is a bug, a feature or an unavoidable situation. But hopefully relevent information.
I can't find "Hangul/Hanja conversion" in the dialogues of my "2.0.2 German version WIN XP: [680m5(Build9011)]". What steps will be required to reproduce that problem starting with a normal englisch language OOo build?
Use: tools->options->language settings->languages->enable asian languages and then the menu mentioned at the top of this issue becomes available in a non-asian locale
I checked with "2.0.2 German version WIN XP: [680m5(Build9011)]" and found out 1. open 'hanguldemo-koreanlangset.odt' 2. Menu "Tools - Options - Language Settings - Languages" Check "Support of Asian languages" <ok> 3. Back to document, Mouseclick to place caret between first 2 cahracters 4. press <cntrl>+<shift>+<F7> dialogue to convert Hangul/Hanja will appear 11. Now open 'hanguldemo-nolangset.odt' 12. Menu "Tools - Options - Language Settings - Languages" and see that "Support of Asian languages" still is checked 13. Back to document, Mouseclick to place caret between first 2 cahracters 14. press <cntrl>+<shift>+<F7> dialogue to convert Hangul/Hanja will NOT appear You can heal this malfunction with "Tools - Options - Language Settings - Languages" setting 'Standard Language of documents "Asian"' to "Korean" I transferred the korean text to a CALC cell with the same result after <cntrl>+<shift>+<F7>. The reason for all that is that in 'hanguldemo-koreanlangset.odt' the language is set to "Korean" (in menu 'Format - Charakters - Fontset for Asian language / Language'), in 'hanguldemo-nolangset.odt' "none" is selected as language. I also checked with "2.1.0 German version WIN XP: [680m6(Build9095)]" (on an other PC) and found very similar behaviour, but here the word itself and proposals for replacement are visible (pls see attached screenshots)! Currently I see this as a 'lingucomponent'-issue (or, may be, 'l10n?). @cmc: can you please contribute a brief explication why it should be expected that the dialogue should appear although no Asian language is selected in character format? Any idea why the panes in the dialogue remain empty in 2.0.2 (screenshots!)?
Lingucomponent
Created attachment 42311 [details] differences in view (and functionality) between 2.0.2 and 2.1
"Don't know if this is a bug, a feature or an unavoidable situation." but I had some CJK users who found this unexpected behavior, and it would seem theoretically possible at least to detect that that text in question is in the CJK range and appear in that case rather than from the language attribute. I don't know if this is reasonable or not to restrict the feature to korean language text and not korean language code points, I'm not a domain expert here, but my korean co-workers were somewhat baffled... as for 2.0.2 vs 2.1.0, seeing as 2.1.0 works (once the language is set) I wouldn't worry about the 2.0.2 results :-)
Currently I see this only P5, because it seems to be big plight for only little benefit of comfort. May be the implementation of a warning box, that appears after <cntrl>+<shift>+<F7> if no Asian language is selected, can be a compromise? May be it could also be helpful to have a hint in HELP that currently that all only can work if a correct language is selected for the document contents. @lingucomponent: any comments before we reassign to '@requirements'
SBA: Confirming issue. I think P4 is appropriate, but enhancements and features follow different rules than defects anyway :-) SBA->TL: Please comment on a possible "fix along the way" once "language guessing" (for western languages) sees the light. Apart from that I believe that "language guessing" for script types that use a unique Unicode area is far from rocket science.
TL->FL: I think this problem would be equally solved by your idea for further improved use of language guessing: That is the language should be determined and automatically applied while typing the text.