[gcompris-devel] i18n falling letters

[Bruno Coudoin]

What you are proposing is going to be too complex. This is going too
far. I want to restrict gcompris to teach simple concept. More advanced
concept often need dedicated tools. For example, gcompris should not
replace a real typing tutor like ktouch. 
In your example, I believe there are tools dedicated to learn kanji.
Won't it be more appropriate than gcompris ?

Now, more specificaly on your question, I don't think gletters uses the
sublevel concept. It's up to each board to manage (increment and check
boundaries) of the level/sublevel. No mysteries here.

I had a busy week-end and failed to look at your code. I have to make a
new release to fix the major bugs we have and prepare the freeedem. I am
not sure of when i will have time to take care of your code :( Sorry for
that.

Bruno.

Le dim 15/02/2004 à 13:32, Yan Seiner a écrit :
> Bruno:
> 
> Some more observations on i18n of falling letters/gcompris in general.
> 
> We need more levels than 6.  We should have a progressive level of 
> difficulty by grade level if the locale requires it. For ja_JP, for 
> example, we should have about 18 levels, starting with caps, then adding 
> digits, lower case, hiragana, katakana, and then 12 levels of Kanji.
> 
> We really want to have sublevel dynamically assigned based on no. of 
> chars at current level since in alternate alphabets the nubmer of 
> characters can get very large. I'm thinking grade level Kanji, where by 
> 12th grade there are 1800 +/- chars we should be dropping.
> 
> I've tried the line below, but doesn't seen to have any effect. I'm 
> guessing that sublevel is hardcoded somewhere:
>  
> gcomprisBoard->number_of_sublevel=max(8,g_utf8_strlen(letters_array[gcomprisBoard->level-1],-1));
> 
> 10 dropped chars is not a sufficient number with 1800 characters in the 
> set.  However, before we get there, we need to make gcompris compatible 
> with alternate input methods.  I've tried kinput2 - the japanese 
> character input method - and it doesn't work.  There's no response from 
> gcompris.
> 
> Someone really has to look at how alternate input systems work; that's 
> beyond my time availability.  I think there has to be an edit window 
> open to enter the char/word, so we're looking at adding an alternate 
> input system compatible editor into gcompris.  Probably not a trivial task.
> 
> --Yan