[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] Fwd: Re: Fwd: Re: [kde-edu]: Re: kdeedu
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2002-04-25 8:06:43
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday, 24. April 2002 23:12, Anne-Marie MAHFOUF wrote:

> Please read the following carefully.
> I don't know what to think. I feel he mixes internationalization with data.

He does, but he also wrote in his last paragraph that he has not yet looked 
at the apps in question, so I guess he has just a wrong view at the moment.

> I don't feel like carrying on without asking kde-core whether the kdeedu
> module should go on or what.
> I invested a lot of time in this project and if it is to hear that it does
> not fit in KDE then I better stop now.

No, the project is absolutely needed and all of you are doing a great job!

> I think that given 6 more months we'll reach a common look and feel and
> we'll share data, we'll unify progs. This just needs a bit of time. I know
> that all the developers do their best and I am really proud of what we
> achieved so far.

Fully agree. Waldo already wrote on kde-edu that open source development is 
an evolutionary process.

> ----------  Forwarded Message  ----------
>
> Subject: Re: Fwd: Re: [kde-edu]: Re: kdeedu
> Date: Wed, 24 Apr 2002 21:43:03 +0200
> From: Thomas Diehl <thd@kde.org>
> To: kde-devel@kde.org
> Cc: Anne-Marie MAHFOUF <a-m.mahfouf@lineone.net>
>
> Am Mittwoch, 24. April 2002 20:16 schrieb Anne-Marie MAHFOUF:
> > > > On Wednesday 24 April 2002 14:03, Erik Kjær Pedersen wrote:
> make sense to confront foreign users (and translators) with anything they
> absolutely cannot use without a lot of 3rd-party material.

I think some kdeedu apps, the one that depend on external data, can be seen 
as some kind of interactive viewers.
And usually you don't distribute media with viewer software (with the 
exception of one or two smal examples maybe)

> programs. KDE core mostly tries to only include programs which hopefully
> meet the needs of somewhat bigger international target groups (yes, I know
> this is not an exact science).
> //kids are not a big international target group?

I think he meant the apps that were not properly i18n-ed.
Applications should be usable by anyone with the same goal.
So the interface should be i18n-able.

My guess is: its ok to have an app with a specialized goal but it is not ok 
to have an app which's GUI is locked to only one language.

So, whatever the program is for, put hardcoded strings into i18n functions 
and use English for their values so they can be translated properly.

> specialized apps or things of regional interest. (On the contrary!) But if
> they cannot be i18n-ed properly they shouldn't be included with the
> international core distribution of KDE.
> //annma: what does he mean by i18n-ed properly?

See above.

> You don't have to. They can be provided by translation teams just the way
> as in KTuberling. If they don't do it it's their own fault. The important
> thing is that it must be _possible_ to internationalize the program.
> //annma: he does not get it with data. An English set of words with a
> common //grammar rule cannot be translated into German, it will mean
> nothing. As in //KLettres "me" is a basic syllable in French but not in
> some other languages.

i don't know how KLettres works, but as you wrote that it can already do 
French and Dutch, I think it would be possible to have data sets in other 
languages too.

Of course this example sets cannot be translated but the transaltion teams 
could create their own example set.

This is the difference between KTuberling, which has a limited set of data 
files, and programs like KLettres, were the number of media files depends on 
the number of syllables.

That's like the difference between compiletime dependency and runtime 
dependency.

(I hope this wasn't too confusing)

> above guidelines. _If_ they cannot be used with lots of additional training
> material or are only of regional interest they should not be in KDE.
> You cannot compare this to an editor which gets translated to 50
> languages and can be used worldwide by everybody in need of such
> a program.

I think the basic idea is, to start appls somewhere else, be it on 
sourceforge or in kdenonbeta and move them to kdeedu when they reached a 
certain level.

That's the way it works for kdegames. New games appear in kdenonbeta or have 
their own sites and sometimes they are moved over to kdegames before a 
release when they meet KDE's quality criteria.

Cheers,
Kevin
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Krammer <kevin.krammer@gmx.at>
Developer at the Kmud Project http://www.kmud.de/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8x7kYnKMhG6pzZJIRApH8AJ4qQ6UlYE8DslHoBypD9EZ6PQzCpACfSKqi
KlXi5mn/s1V4SesbnkUiJfM=
=XVzP
-----END PGP SIGNATURE-----
_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-edu-devel
[prev in list] [next in list] [prev in thread] [next in thread]