OCT
30
2001

KDE Speaks Xhosa Fluently, 10 More .za Translations To Follow

Translate.org.za (partly sponsored by Obsidian Systems) is spearheading an effort to translate KDE -- the complete desktop including Konqueror, KMail, KWord, KSpread -- into the eleven official languages of South Africa. As a first start, the Xhosa translation is already part of KDE 2.2.1.
The Mail & Guardian newspaper has a full article on the project.

KDE was chosen because of its maturity and active translation efforts and it is hoped that the dictionary built through translating KDE will help in translating other non-KDE applications. The next steps in the project are to work on the Mozilla browser to allow users of Windows access to a Xhosa web-browser, a Xhosa dictionary, and OpenOffice for a cross-platform Office suite.

After that the project will be moving on to the Zulu translation of KDE, eventually making computers accessible to people in all of the 11 official languages in South Africa. The languages that have the highest populations will be targeted first, facilitating the highest possible impact of the software. Translate.org.za has received sponsorship from the Shuttleworth Foundation for continuation of the project.
The possible impact of this project is immeasurable, in my opinion.

Comments

>translate KDE into the eleven official languages of South Africa.

Um-Gawwah KDE

Tarzan like! Jane, come see tarzan's kde. Cheeta no touch!


By Tarzan at Mon, 2001/10/29 - 6:00am

So now we know that stupid racists also post their comments here.


By ac at Mon, 2001/10/29 - 6:00am

I thought Tarzan and Jane were white, and Cheetah was a monkey.
Are you accusing Tarzan of racism against his own race, or specism against Cheetah?


By Roberto Alsina at Tue, 2001/10/30 - 6:00am

No,
I accuse someone who associates "the translation of KDE to South African languages"
with stupid phrases ( Um Gawwah KDE ) of racism.

It shows that he thinks people in South Africa have no real language to express themselves - its simply saying blacks are stupid in disguise. It is irrelevant if the person he uses to express his views is a white movie character.


By ac at Tue, 2001/10/30 - 6:00am

Could you all please stop making a full-fledged thread just because of some juvenile remarks?


By AC at Tue, 2001/10/30 - 6:00am

Oh, well. Whatever.


By Roberto Alsina at Tue, 2001/10/30 - 6:00am

It was supposed to be a joke, a play on Tarzans word from the movies. It has nothing do to with black people what so ever.


By Tarzan at Wed, 2001/10/31 - 6:00am

is Um Gawwah a racist word


By Daniel Naber at Thu, 2001/11/01 - 6:00am

we need more KDE 3 related news too and a few screenshots. Are there any plans to have Wizards and configuration tools much like Future Technologies' ones:

http://www.linuxutilities.org/index.html

If KDE can speak African languages, indeed it will make KDE the most used DE and Linux the most used OS! My applause and good wishes!


By Asif Ali Rizwaan at Mon, 2001/10/29 - 6:00am

an unwritten policy of the KDE project is to not announce anything before it is actually ready. so during large devel cycles things can seem quiet around the KDE camp, unless you are right in there reading the mailing lists or following CVS. i am nearly done this week's KC KDE (got slowed down by the weekend's Halloween party... *hic*) which should be out tomorrow and covers KDE3 devel. so, if you call that news, there it is.

as for screenshots, the look really isn't all that much different. IMO KDE3 is very much a usability enhancement in the form of APIs that will be stable for a long time (allowing apps to mature instead of having to be ported as soon as they get to a stable release), better performance, bug fixes, better support for things like BiDi, security certificates, IMAP and ASMTP, etc, etc.. in other words, it will be hard to see 90%+ of the differences without actually using it.


By Aaron J. Seigo at Mon, 2001/10/29 - 6:00am

Well, the look of either KDE2 or 3 (as well as GTK), is done by plugins. This means that the rendering of widgets can be dynamically replaced anytime - you don't need to do a new KDE release. So while KDE3 doesn't include any new styles AFAIK, this doesn't mean people aren't designing new style or theme engines, they most certainly are. Most of the "official" work for KDE3 seems to be in theme and style management, making everything easy to install for the end user, not in new rendering engines themselves. But it *is* being worked on, and in fact things like Liquid and Megagradient originated as just tests for a new theme engine. I wrote the pixmap theme engine for KDE2, and never liked it. It had some cool stuff and a lot of efficency hacks, but is rather primative in dealing with things like alpha masks and window background options. A lot of my current style work is actually just trying ideas out and solving bugs for new theme engines. For example, Liquid looked cool but had a ton of bugs back in 0.1. Now they are almost all fixed and these solutions directly apply to new theme engine designs. While I haven't worked on MegaGradient as much since I personally use Liquid, it too has helped identify many bugs and what needs to be fixed.

QT3 does have a new QStyle as well that expands the number of widget items you can do custom rendering for. I was able to hack around things not supported by the Qt style mechanism before using paint event filters, but this was messy.

My goal is to have a pixmap theme engine that operates just as efficently as Liquid, has improvements for things that are slow in GTK's engine (like custom code for gradients drawn to the window size), support for things that are cool in the GTK engine like good alpha mask handling, more options like mouse hover, and dynamically adjusting HSV that matches the users color scheme - even for pixmap themes. For the last item, this means the person making the theme would just supply a grayscale pixmap and the engine would automatically do HSV adjustments to match the user's colors.

This won't be included in the offical KDE, since I am no longer a core developer and I could already tell that the release schedules will probably conflict yet again, but it will be available as a separate package.


By Mosfet at Tue, 2001/10/30 - 6:00am

> But it *is* being worked on, and in fact things like Liquid and Megagradient
> originated as just tests for a new theme engine.

übercool ...

> This won't be included in the offical KDE, since I am no longer a core
> developer and I could already tell that the release schedules will probably
> conflict yet again, but it will be available as a separate package.

i don't think this is (thankfully) as much of an issue as it was in the past. with kde-look.org and apps.kde.com around there are very public and very easy ways to distribute kde specific code to a very broad audience on one's own schedule. IMO this is a very important step forward for KDE (and those who wish to deveop code for, though not necessarily with, KDE).

that said, it's great to see you back and around mosfet! hope 2002 is a better year for you (starting now ;-) and we all look forward to seeing your next creation(s).

===

and now to try and be slightly on topic: an inexpensive, sane and regionalized operating system (and desktop) is exactly what can make Linux + KDE an international success. leap frogging other systems in those markets can only help in a "surround the castle" sort of way.


By Aaron J. Seigo at Tue, 2001/10/30 - 6:00am

> and now to try and be slightly on topic: an inexpensive, sane and
> regionalized operating system (and desktop) is exactly what can make Linux
> + KDE an international success. leap frogging other systems in those markets
> can only help in a "surround the castle" sort of way.

The translation issue is one we are using to sway Governement to better support/adopt Opensource software. Supporting hundreds of small regional languages is something that only Opensource software will be able to do, because often there is very little commercial motivation.

I hope that projects like this will appear in other developing nations and help create the groundswell we need.


By Dwayne Bailey at Tue, 2001/10/30 - 6:00am

>The translation issue is one we are using to sway Governement to better
>support/adopt Opensource software. Supporting hundreds of small
>regional languages is something that only Opensource software will be
>able to do, because often there is very little commercial motivation.

So, I take it many/most/all of the 11 official languages are not supported by Windows or MacOS?

This is a terrific project, the kind of thing that shows why large, international, collaborative hacker projects like KDE are special. I'm glad to see it's already produced one finished product.


By Otter at Tue, 2001/10/30 - 6:00am

> So, I take it many/most/all of the 11 official languages are not supported
> by Windows or MacOS?

The 11 includes English so that doesn't really count (we do help out on the en_GB project). There might be support in Windows for Afrikaans not too sure.

There definately isn't support for the other 9 languages, although I have seen some mention of dictionary support for Xhosa and Zulu in applications like Word and WordPerfect.


By Dwayne Bailey at Tue, 2001/10/30 - 6:00am

> So, I take it many/most/all of the 11 official languages are not supported
> by Windows or MacOS?

The 11 includes English so that doesn't really count (we do help out on the en_GB project). There might be support in Windows for Afrikaans not too sure.

There definately isn't support for the other 9 languages, although I have seen some mention of dictionary support for Xhosa and Zulu in applications like Word and WordPerfect.


By Dwayne Bailey at Tue, 2001/10/30 - 6:00am

Great! I also hope that pixie makes it's way back into KDE (might be wishful thinking). I grew quite accostomed to it, and then, poof, it was gone :(.


By FO at Tue, 2001/10/30 - 6:00am

Not very likely since it's no longer a KDE app, but runs just with Qt in order to support both Unix and Windows ;-) Pixie on Windows is one of the things I'm getting paid to work on these days, but it will still be free and integrate well with KDE. The thing has been completely rewritten and is much easier to use and even faster than before. It's been split into two parts: browser and effects, with the browser as the main interface. The Unix browser is done, but the effects are not.


By Mosfet at Tue, 2001/10/30 - 6:00am

Nice to see you back.

You should see how impressed people are with high performance liquid. I have had windows users ask me how they could get this look, and when I told them that they could not because it is not for windows they were really perplexed.

What do you think about replacing X by something like DirectFB? Will this simplify writing real transparent menus, and most importantly are there significant performance gains when dropping X? I think you are in the best position to know this :-)

best regards,

Androgynous Howard


By Androgynous Howard at Tue, 2001/10/30 - 6:00am

These effects seem to be the most sought after visual improvement these days. I did some looking into it recently, and summed up the situation in a post to kde-devel:

http://lists.kde.org/?l=kde-devel&m=100324780628509&w=2

I don't know much about the DirectFB side of things, but my reading tells me it would take longer to get qt ported over than to implement this properly into X.

Here's the summary. This is possible to implement, but requires changes to X. Many of the basic required features are already in X (hardware accelleration being the most important). It seems all that is needed is a proper "translucent window extension" protocol, some internal reorganisation of X, and of course, XFree86 developer support. Keith Packard (of Render fame) is working on such an extension and predicts a 6-month time frame for early prototypes.

This would enable more than just translucent menus - think colour, alpha-blended mouse cursors; translucent applications (including translucent Noatun skins...!); transparent on-screen displays... the possibilities are huge.

I am interested in seeing if I can get my skills up to work on X, we'll see.


By Hamish Rodda at Tue, 2001/10/30 - 6:00am

Yep, Keith's translucent window server is something I've been hankering after for a long time ;-) He's a busy man, tho, and this is probably low on his priority list. The guy is very good and has a lot of tasks. I don't think it will support cursors - that's not a X11 Pixmap but a bitmap, (although I don't know), but real translucent window support in the server would be quite cool in itself.


By Mosfet at Tue, 2001/10/30 - 6:00am

From what I've seen, implementing colour/alpha mouse cursors would be basically for free if tackled with the translucent window extension, as there would be an easy way for the extension to fall back to software rendering should hardware acceleration not be available.

Other effects which could be tackled at the same time are window-level graphics filters, anything the hardware supports or your CPU can afford (focus/blur, maybe even refraction maps... think of cool effects with a glass theme...)

If anyone is interested in helping speed up the implementation, drop me an email (XFree86 is written in C). I'm not sure if I will be tackling it or not, my holidays are filling up with projects pretty quickly as it is.


By Hamish Rodda at Tue, 2001/10/30 - 6:00am

There is already software cursors in X11. That doesn't help change all the code that relies on it being a bitmap ;-) Making it a XRender drawable isn't going to make it any easier at all, the reverse is true.


By Mosfet at Tue, 2001/10/30 - 6:00am

No, not a good idea. I'm writing up a user-oriented X11 graphics FAQ for mosfet.org, which will explain in detail X graphics. The quick answer is X11 is rather modular these days, has many more accelerated drivers than the framebuffer, supports multi-layered channels (XRender), and has got a direct rendering interface for apps that need it. So while having QT Embedded, etc... is cool for most end users X11 is better IMO. Not to mention virtually every GUI toolkit in the Unix world supports it.


By Mosfet at Tue, 2001/10/30 - 6:00am

I think the long term goal should be to use the 3D accelerator functions of modern graphics cards for everything including two-dimensional drawing. With the huge performance and nice features of 3D cards there should be some really nice possibilities. If this is possible without dropping X it is very nice.

One thing that annoys me about X is that since drawing and user feedback happens in a separate process, there is some unnessecary latency in the user feedback. But I guess that this problem will go away when the linux kernel switches to a decent scheduler and a higher scheduling frequency, so it is not X's fault.

Another thing that sucks about X is font handling. But I guess the problem is that there are not enough good scalable unicode fonts available and that most distributions come with ugly bitmap fonts as defaults.

regards,

Androgynous Howard


By Androgynous Howard at Tue, 2001/10/30 - 6:00am

Hi Mosfet,

nice to hear from you again :-)
I (and probably many many others) were more or less concerned about your, how to put it, circumstances, mosfet.org sounds quite frustrated.

Looking forward nice things on kde-look.org :-)

Bye
Alex


By aleXXX at Tue, 2001/10/30 - 6:00am

small correction "mosfet.org sounded quite frustrated".

Well, I'm wondering, this ain't a picture of you ???

Alex


By aleXXX at Tue, 2001/10/30 - 6:00am

Are you talking about the logo? Yeah, that's me in a picture from a goth club, modified to look more techno and demonic. It's one of my more normal pictures >:)


By Mosfet at Tue, 2001/10/30 - 6:00am

How much coffee did you have to drink for the glowing eyes? :-)


By Carbon at Tue, 2001/10/30 - 6:00am

The glowing eyes were one of the modifications ;-) The other one was HSV modification in order to make the hair more green and better match the circuit background.


By Mosfet at Wed, 2001/10/31 - 6:00am

Anyway, we will se that KDE improvements will be less with new versions, because the whole of the core kde has been programed. I mean, is the same with Windows95. From 95, to XP, the improvements have been less than 3.11 to 95-98. KDE will be the same. Dont be waiting for greatests news with the KDE core and the apps. Is normal. The progression will be with the documentation for example, or somethings like that. Is my opinion.


By Daniel at Mon, 2001/10/29 - 6:00am

Err, the facts you based your opinion on are wrong.
Windows:
Win3.11 = Dos( 6?, 16 bit ?? IIRC )
Win95/98 = Dos( 8 ? 32 bit ?? new Fat32 IIRC )
WinXP = WindowsNT ( built with WindowsNT new Technology )
The step from Win95 to WindowsXP is actually no "step" regarding development,
but a completely different system. Different kernel, driver model, filesystem,

KDE changed ( + bidi just to get more on topic ).
Main features ( = the API ) will not change, since KDE is already very modular and extensible ( Kparts, IOSLaves ) but still, new interfaces are added to the core and these will bring an even thighter integration/interaction between applications.
Now KDE will have standardised SQL database support, which brings up a whole new way of doing things if the KDE developers will take the jump and make
a SQL Database a requirement for KDE.

And to think that better documentation is not as big an improvement as a new "core" once again perpetuates the myth of programming alchemy. A program is useless if people dont know how to use is, and documentation is very important, both for users and developers.


By ac at Mon, 2001/10/29 - 6:00am

I believe he meant Windows as in the Windows desktop, not the Windows operating system.

Just like people use the word ¨Linux¨ to describe a kernel called Linux together with hundreds of other software packages. Yes, it´s wrong, but it´s easier and people are lazy. ;)


By Carg at Tue, 2001/10/30 - 6:00am

Please use XML databases for KDE, not SQL.
SQL is obsolete. Please forget it.

Start by using XML as the native file-format for all KDE applications, and go on with good XML databases like LivingXML.


By Philipp Gühring at Tue, 2001/10/30 - 6:00am

Only someone with no real-life programming experience could say something like this.

I'd like to see your XML "database" handle a load of 5 million transactions in 3 hours...I'd like to see the XML "database" handle a monthly report that summarizes 40 million transactions...I'd probably retire before it completes.

If you say SQL is obsolete it's probably because your only experience with it was Access.

XML is great for passing small amounts of data, SOAP, config files, etc.
Storing any serious amounts of data in it and then retrieving it (which requires parsing it, etc.) would be a total dog compared to a much more efficient SQL-based RDBMS implementation.

You need to use the best tool for each job. I wouldn't store small config files in SQL and I wouldn't store any large amounts of data in XML.

When Wal-Mart (100 million transactions per week from what I last read) switches to an XML database, I will change my mind. Until then, I believe they are still running mainframes (which were also supposed to be obsolete...yeah, right).

The only people pushing XML for data storage are...storage vendors (EMC, etc.) For them the size bloat introduced by XML is a boon to their business.


By Jacek at Tue, 2001/10/30 - 6:00am

Well, I have a 3 GB (250000 records) XML database running on my Pentium 100 ...

Mainframes? Yes, the style of Cobol is more XML than SQL.
XML Overhead? I don't care about some percents overhead, if I can create applications much faster and better than I ever imagined. I reengineered an application with XML in one week, where the original developers (~ 10 developers) were working for 5 years.
I agree that XML might not be the best at the moment when it comes to databases which are bigger than 100 GB. But how many KDE applications want to work on that big databases?

Size bloat? I delivered one of my XML applications one one 3,5" floppy disk, which included the whole database, application, and even some test data.
Just show me a commercially graded SQL database that fits on one floppy disk.


By Philipp Gühring at Tue, 2001/10/30 - 6:00am

Well, I have a 3 GB (250000 records) XML database running on my Pentium 100 ...

Mainframes? Yes, the style of Cobol is more XML than SQL.
XML Overhead? I don't care about some percents overhead, if I can create applications much faster and better than I ever imagined. I reengineered an application with XML in one week, where the original developers (~ 10 developers) were working for 5 years.
I agree that XML might not be the best at the moment when it comes to databases which are bigger than 100 GB. But how many KDE applications want to work on that big databases?

Size bloat? I delivered one of my XML applications one one 3,5" floppy disk, which included the whole database, application, and even some test data.
Just show me a commercially graded SQL database that fits on one floppy disk.


By Philipp Gühring at Tue, 2001/10/30 - 6:00am

3 GB...?
How about 3 terabytes?

I'm sorry, but when you get to really huge data sets, nothing but the most intense optimizations will work. SQL has proven itself over the last 20 years ...if you managed to re-engineer in XML in 1 week an app that took 5 years to build in SQL...well, I congratulate you on your skill...and recommend you immediately fire the previous developers, 'cause they obviously didn't know what they're doing.

The reason you managed to fit your app on a floppy is because your XML DB offers a lot less than what an RDBMS DB can. Stored procedures? Triggers? Foregin keys on master (i.e. non-data) tables? Optimization hints? Statistics-based query plans? Parallel query processing? Data partitioning (i.e. transparent partitioning of tables based on key values for drastic query speed improvements)? Indices (to avoid a table scan...I've seen when an index made a difference of a report cutting down from 2 hours to 4 minutes of retrieval time).

I'm sure I could strip all of that out from let's say MySQL (which doesn't have half of these features anyway) and fit just a bare-bones RDBMS storage system
on a floppy.

XML might be fine for maybe smaller databases, but you'd be surprised how often these small projects blossom into something larger...and then you will regret not going with a solution that emphasizes flexibility and speed.


By Jacek at Tue, 2001/10/30 - 6:00am

That is not to say that an XML database might be the best choice for storing KDE config files...you could be 100% correct there...

I just in general strongly disagree with your statement that SQL is obsolete and XML is the manna from heaven that is the perfect solution for everything.


By Jacek at Tue, 2001/10/30 - 6:00am

Uh, it shouldn't matter at all. With QT's database middle-man, you could code any sort of QT Db interface you wanted to, and every app using QT's database support would use that w/o complaint. AIRC?


By Carbon at Tue, 2001/10/30 - 6:00am

Maybe yes, maybe not.
I recall my friend who closely monitored the Qt3 beta period telling me that many users accessing DBs via the Qt middle-man instead of native APIs reported a noticeable hit in performance.

The extra added layer of abstraction (on top of ODBC for example, which in itself is already a layer of abstraction) really can add up when you are retrieving 15,000 rows of data.

But then, I'm sure the Qt guys can optimize it as the time goes by.
Just don't expect for the first version to be just as fast as native access (e.g. calling the Oracle OCI APIs directly).

Just wondering though...with Qt providing a lot of server-side X-platform code (DB access, multi-threading, XML, HTTP/FTP/file access, and soon a component model, etc.) I was wondering if someone had ever thought of coding server-side apps (i.e. no GUI) in Qt instead of let's say Java.

It seems Qt has provided a lot of the platform abstraction for key server-side modules, so don't be surprised if Trolltech releases a server version of Qt soon...all it needs is some middleware and Java better look out.


By Jacek at Wed, 2001/10/31 - 6:00am

I can see no reason why a good database engine should not be able to support many interfaces, including XML and SQL. There's absolutely no reason to alienate yourself from milions of SQL knowledgable users by supplying an XLM-only interface to your database.
KDE is built on standards. Well, make a standard database interface that can plug into anything, from text-files over MySQL to Oracle or DB2. That way you'll never get caught with your pants down. When small UI configurations might be saved faster in flat-files, a 500 user server might benefit from a central database, possibly even running on another machine?
Don't get me wrong, I like XML as the next geek, but it's the possibility to choose depending on your situation that makes Unix strong.

Just my 2 Euro cents.

Cheers,

Matt

P.S. To prove my point, Oracle 8i offers many interfaces to it's database, including SQL, XLM, Java and PL/SQL. And the engine is always the same.


By matt at Wed, 2001/10/31 - 6:00am

HUH??

SQL and XML
Apples and oranges


By [Bad-Knees] at Thu, 2001/11/01 - 6:00am

I think ac is looking for an argument.


By [Bad-Knees] at Thu, 2001/11/01 - 6:00am

...again!


By Billy Nopants at Thu, 2001/11/01 - 6:00am

Reminds me much of our own efforts to translate KDE and other open-source software into Norwegian Nynorsk. Nynorsk is the smaller of the two official Norwegian languages, which means that practically no commercial software is available in Nynorsk.

There is some more information in this year-old KDE News article: http://dot.kde.org/972035764/ (And of course, a *lot* has happened since then!)


By Gaute Hvoslef K... at Tue, 2001/10/30 - 6:00am