Language Learning Discussion: Some food for thought before the meeting

[Inge Wallin]

On Sunday, March 02, 2014 17:37:20 Andreas Cord-Landwehr wrote:
>...

Ok in a weak moment CoLa took advantage of me and made me promise to write 
something that we could discuss around in this meeting.  :)

The main topic of this dicussion is C: Planning of Application Scopes and 
Integration in this page: 
https://community.kde.org/KDEEdu/Language/Projects/LearnerCentricApplications

Let's start to look at what a person learning a new language needs to learn in 
general:

1. Characters. Sometimes you get this for free if you are learning a new 
language that uses the same alphabet or script system as the ones you already 
know.  But some languages have new characters (Swedish åäö compared to 
English, for instance), more accents (French or Spanish) or use even 
completely different script systems (Asian languages compared to European and 
the other way around).

2. Words. This is the most fundamental knowledge of all languages. In this 
case I am grouping learning to read the words and learning to understand 
spoken words together. 

3. Grammar.  How to put the words together to create meaning. At present KDE 
Edu doesn't have anything to support this.

4. Pronounciation.  You need to know how to say the words and phrases.

In KDE Edu we have applications that cover most of these needs:
1: KLettres, Kiten(?)
2: Parley, KWordQuiz
3: -
4: Artikulate (since a week ago)

But not all aspects of all the cases are covered.  For instance KLettres is 
mostly for kids learning to read for the first time. If you want to study Thai, 
Hindi, Chinese or Japanese as an adult you don't really get a very good 
experience from these applications. Also Kiten is only for Japanese and I 
think it's even retired although I'm not sure there.

So the scopes of the applications and their role in the language learning 
process are pretty clear. But how the code is organized is perhaps not optimal 
right now. Also the usage patterns seem to be a bit ad hoc.

For instance Parley is only usable for training at this point, but the 
terminology in many places seems to be geared towards testing. I suggest that 
we try to limit ourselves to support the *learning* of languages only for the 
foreseeable future. Adding a test mode to the applications is probably 
worthwhile, but we need to add other types of workflows and features for those 
usecases before they are viable. For example you cannot show the answer when 
you are done with a question. :)  Also you need to be able to go back and 
forth in the set of questions and correct your answer if you want to.

When it comes to creating training data I know that Parley uses kvtml and has 
an Ok editor in it.  But I don't know much about the other applications. I 
think some other applications use Kvtml too and artikulate does have it's own 
editor. Discussing file formats and editing is not in scope for this upcoming 
meeting but it's an important topic that we will need to address soon. For the 
moment I suggest that we keep things as they are, i.e. an editor in each app 
that need it and the rest can use Parley for kvtml editing. The exception 
could be KWordQuiz that has a very simple kvtml editor in it now with lots 
fewer features than parley's but it's also a lot simpler.

And in addition to that, there is a Google Summer of Code project proposal[1] 
to create a more advanced editor for large data files.

Finally, we have discussed creating an integrated application á la Kontact 
where each of the aspects above and maybe more (advanced statistics?) could be 
components. This would be some sort of "Language Lab" application with the 
individual applications integrated into a whole. The most reasonable technique 
to do this would be to use KParts which is very simple.

Under the hood, there is the question of what to break out into libraries and 
what to keep in each application. We have a library in libkdeedu called 
keduvocdocument which reads, stores, and writes kvtml. I would be thrilled to 
have an advanced flashcard (including multiple choice, written training, etc)  
library that uses Qt Quick too. That would make it easier to create 
specialized versions of the apps and also package them for mobile/touch use.

Regarding new features for individual applications I am not going into that 
here. This mail is only about scope and integration.

	-Inge


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140303/3dfed778/attachment-0001.html>