[g11n-ko-discuss] [i18n-discuss] Please review the onepager for "Korean Input Method Enhancement" project

[Ienup Sung]

Since the project is going to remove KOLE from Nevada, you will have to
announce EOF at S10UR as soon as possible and do EOF execution (in other
words, the removal of KOLE) at Nevada.

The EOF process we have mandates that before we remove software feature,
we must announce our intention at least one year before and that bodes
well with S10UR schedule and Nevada or whatever we will be calling it for
the next minor release. Also, normally, the EOF execution is done in minor
releases unless exception approvals are made in places.

If HangulLE is 100% compatible, then, the replacement is transparent
and there is no reason to do EOF announcement since there is no removal of
software feature. Based on your answers to my questions and also 1-pager
contents, that's not really so and hence the project team need to follow
the EOF process.

I don't have any particular opinion about the Hanja Tool vs. libhangul
community user-defined (Hanja?) dictionary support feature. The fact is
that, with the project, if Hanja Tool is a goner then the project team
need to EOF it too.

The project team can always do another project for the new user-defined
dictionary support as needed with a new case if the proper timeline cannot
be aligned with this project for now.

Ienup

Aijin Kim wrote at 01/24/08 00:32:
> Hi Ienup,
> 
> I have a few questions.
> 
> Ienup Sung wrote:
>> Thanks for your answers.
>>
>> Based on the answers you provided, it appears to me that the one pager
>> and project should explicitly mention about and include the EOF of 
>> KOLE and
>> Hanja Tool and also add proper interface stability definitions for the 
>> EOF.
>> (EOF announcement at a S10UR and EOF execution at Nevada.)
>>   
> 
> - In terms of S10UR, the existing KOLE won't be removed. Then we don't 
> have to go with EOF process, do we?
> - If HangulLE replace all the feature of KOLE, don't we have to apply 
> EOF of KOLE?
>> If Hanja Tool's EOF is definite and if there is no other replacement or
>> user data migration path planned, then, there should be a justifiable
>> argument why those are not needed as part of EOF statement and also
>> explanation.
>>   
> 
> Currently, there are community discussions how to support user-defined 
> dictionary in libhangul. If a new feature is provided by libhangul, 
> libhangul will also be able to replace Hanja Tool in future.
> I think we'd better to wait for new version of libhangul and leverage 
> community's work. However, in this case, we need to apply EOF of Hanja 
> Tool in Nevada.
> 
>> Please send me the current Hanja image file or source of the aux 
>> window and
>> I'll be happy to update and send it back to you.
>>   
> 
> Thanks for your help!
> I'm going to send the source to you.
> 
> Thanks again,
> Aijin
> 
>> Ienup
>>
>> Aijin Kim wrote at 01/22/08 20:17:
>>  
>>> Hi Ienup,
>>>
>>> Thanks a lot for your comments.
>>> Please see my reply below.
>>>
>>> Ienup Sung 쓴 글:
>>>    
>>>> Hi Kim, Aijin-si,
>>>>
>>>> Thanks first of all for doing this good project. I've also cc'd
>>>> g11n-ko-discuss mailing list at OpenSolaris.org.
>>>>
>>>> I have a few questions to ask on the project:
>>>>
>>>> It appears to me that this project will replace the existing so-called
>>>> KOLE with HangulLE at Nevada while supply both at S10UR, correct?
>>>>       
>>> Yes, we plan to leave KOLE as a secondary LE in S10UR according to 
>>> GTO-core's advice. We think that It'd be safer to have a transition 
>>> stage of  the replacement.
>>>
>>>    
>>>> What are the compatibility issues in terms of user's usage 
>>>> perspecitive?
>>>> Are all existing input modes and key sequences and so on be the same 
>>>> and
>>>> supported with new HangulLE?
>>>>       
>>> All the features of existing KOLE will be covered by HangulLE or 
>>> alternative ways. However, there is a few changes with user's usage.
>>>
>>> As you know, there are four input mode in KOLE:
>>> - Hangul
>>> - Hex(KS X 1001)
>>> - Hex(UTF-8)
>>> - Symbol
>>>
>>> Among them, Hex(UTF-8) mode will be covered by UNICODE engine of IIIMF.
>>> For Symbol input, instead of symbol input mode, HangulLE provides a 
>>> feature symbol input with virtual keyboard. User can input hangul and 
>>> symbols without switching input modes. And also 'consonant+Hanja key' 
>>> is supported for symbol input just like Windows IME and SCIM-hangul.
>>>
>>> And some key sequences especially for Hanja conversion are changed. 
>>> It is mainly because of the reported issue:
>>> CR6267800    shortkey for hanja convertion can not work in some gnome 
>>> application, such as gedit
>>>
>>> KOLE is using several shortcut keys which are already defined in some 
>>> applications such as 'Ctrl+W','Ctrl+N','Ctrl+P'. HangulLE doesn't use 
>>> 'Ctrl+' key sequences and defines shortcut keys to be similar with 
>>> Windows IME and SCIM.
>>>
>>>    
>>>> With HangulLE, would you or how do you support user-defined characters?
>>>>       
>>> I'm not so sure of this question. Is this question related the below 
>>> question regarding the five characters of EUC locale?
>>>
>>>    
>>>> How the Hanja Tool and existing user Hangul-Hanja dictionary plays 
>>>> their
>>>> roles with new HangulLE?
>>>>       
>>> HangulLE uses the Hanja dictionary in libhangul. Existing Hanja 
>>> dictionary won't be used.
>>>
>>>    
>>>> In Korean EUC locale with KS C 5601-1987 fonts, as you know, there 
>>>> are five
>>>> characters that are not in the KS C 5601-1987 character set while in
>>>> the course of composition of Hangul syllables, do required to be
>>>> present/visible at preedit window as visual feedback. They are 뢔, 
>>>> 쌰, 쎼,
>>>> 쓔, and 쬬 (in UTF-8) and in our Korean EUC fonts, the glyphs for 
>>>> them are
>>>> intentionally added at user-defined area between 0x497a and 0x497e 
>>>> so that
>>>> during preedit, those glyphs will be shown as user visual feedback.
>>>> Would such characters also be supported at the new HangulLE for
>>>> the Korean EUC locale?
>>>>       
>>> Thanks for the good point. I didn't consider the issue. I think 
>>> HangulLE should support the characters as well. I'll think of how to 
>>> support them in HangulLE.
>>>
>>>    
>>>> In the section 4.1.4. (1), the one pager describes the auto 
>>>> composition when
>>>> vowel starts a syllable. Would such auto auto composition a feature 
>>>> that can
>>>> be turned on and off and if so what would be the switch?       
>>> All the hangul processing include auto composition is handled by 
>>> libhangul, not HangulLE codes. I'm afraid that on/off is not 
>>> currently available.
>>>    
>>>> In the (2),
>>>> would step Hangul-to-Hanja conversion still be supported using 
>>>> Ctrl+N and P?
>>>>       
>>> As explained above regarding shortcut key, HangulLE doesn't use 
>>> 'Ctrl+' key to avoid conflict with applications.
>>> Ctrl+N and P is for page up and down. HangulLE uses page Up/Down key 
>>> and also can move candidate pages clicking arrow icon on the 
>>> candidate list window.
>>>
>>>    
>>>> In the section 4.1.5, the aux window layout is shown as:
>>>>
>>>> +-------------------------------------------------------------------+
>>>> | Mode Switch | Hanja | Full/Half  | Virtual Keyboard | Properties  |
>>>> +-------------------------------------------------------------------+
>>>>
>>>> which appears reversed "Hanja" and "Full/Half" of the current aux 
>>>> window.
>>>> Is there any specific reason why that has to be that way possibly 
>>>> increasing
>>>> confusion among users? Also, would it be possible to change the "Hanja"
>>>> image at the aux window? (If necessary, I could supply a better image
>>>> too. Please let me know.)
>>>>       
>>> As you pointed, it'd be better to keep the current order of buttons. 
>>> I'll revise the onepager.
>>> And it'd be appreciated if you could provide a better Hanja image. :)
>>>
>>>    
>>>> Would you please specify OSR numbers for Sun internal reviewers?
>>>>       
>>> Sure, I'll revise the onepager.
>>>    
>>>> It appears to me that this project will require an ARC approval as
>>>> a fast track mainly due to imported interface of libhangul. For that,
>>>> the section 4.5 would need a little bit of update also possibly 
>>>> based on
>>>> the answers to the questions above.
>>>>       
>>> I'll update the onepager soon.
>>>
>>> Thanks again for your valuable advices.
>>>
>>> Regards,
>>> Aijin
>>>
>>>     
>>
>> _______________________________________________
>> g11n-ko-discuss mailing list
>> g11n-ko-discuss at opensolaris.org
>>   
>