A reason to keep KHTML

I have read that people are not happy about KHTML. As one who spoke once against KHTML, and pro QtWebKit (or QWebKit?). This is why I want to keep KHTML:

Native widgets. Not emulated like WebKit/Gecko, but real Qt widgets. This means that I can have a text widget which fully supports BiDi (not gecko, not webkit, only IE has one... and KHTML).

Also, widgets get drawed funky if the direction of the page is opposite to the direction of your desktop on WebKit (you can see it in chrome, Arora and Safari). For example see the combo boxes in http://www.aljazeera.net/Portal.

Still, I think that KHTML is not something we can handle today. Sorry, even tough KHTML is great, WebKit is what the market needs, it's what we as a community need.

QDevelop 0.27 is out

Get it while it's hot! QDevelop 0.27 has been released!

Sources and builds for Linux/Windows are avialable at the GoogleCode project, as always: http://code.google.com/p/qdevelop/downloads/list

Removed Hebrew translations of Plasma 4.2.1

I just removed the Hebrew translation of plasma from the 4.2 branch, which means only plasma will not be translated to Hebrew. The reason, is that QGraphicsScene does not support RTL interfaces in Qt 4.4, and it's still not sure if KDE 4.2 does support Qt 4.5. Even if it does, it's still not tested.

If KDE 4.2 will work with Qt 4.5, the translation will get pulled from trunk again.

I hope that no more files need to be remove, otherwise I am afraid of going bellow 85% and in theory Hebrew will not be a supported language.

Freeze in KDE4.2 - now lets check out the strings

KDE's trunk is now frozen and no new features can be added, nor visual strings can be modified or added, we are in release mode. Lets see some of those strings:

Inactive contrast effect type, taken from colorsettings.ui:830 in kdebase, the string is found somewhere in kcmcolors.pot. I understand this as the non-active contrast of a type of an effect or the type of the effect for the contrast of non-active (something).  This is how it will sound when translating to my language, it might sound ok in English but it does not always sound good enough in other languages. Looking at the spanish translation it seems the second translation is what the original developer meant.... you see? I need to look into another translation to understand the original string. How can a user understand it?

You have a Logitech Mouse connected, and libusb was found at compile time, but it was not possible to access this mouse. This is probably caused by a permissions problem - you should consult the manual on how to fix this. This one comes from kcminput.pot, and my question is: which manual? ... are you sure it will have information about something like "chmod a+rw /dev/usb-mouse-blabla"?

And then are the giziliion-gazillion technology names we use: plasma, akonadi, strigi, phonon, dbus and more. What am I speaking about this? since some languages leave those names in english even though the langauge is not latin based (for example the Hebrew team is doing this) and others do try to translate the latin letters to the alphabet (the Arabic team does this for example). This is fine, until we start talking about "plasmoids"... and then things get funky. I might need to re-think my policy and translating plasmoid to פלסמואיד and also plasma to פלסמה or פלסמא (the latter sounds more Aramic then Hebrew so I might keep the first one). 

Again, why mumbeling about local decitinos? Because when choosing technology names developers do not think about i18n and l10n (1), what happens when the technology name cannot be transcribed into a specific language? I once heard that CocaCola cannot be transcribed exactly to Chinese and when localizing the trade mark CocaCola used the closes sounds they could find to write the name of the product (2).

Don't get me wrong, KDE 4.2 will kick ass, and the next Mandriva distribution will come with it will get in my laptop (3). But still, as a contributor I am not happy about some decitions, and that's OK.  Since I am using Gnome at work (4) and I see the applications on the other side, and I like the ones KDE is shipping/developing.

(1)  lazy... write the full words!
(2)  any chinese reading this? can you confirm this?

kate and Konsole. Just because the kubuntu-desktop is not stable enough.

(3)  yes, I am still using KDE 3.5.something. Stable and usable, I need to do work and not fight my own system.

(4)  Ubuntu 8.10 (64 bit) with kubuntu-desktop installed, running a GNome session with Dolphin. Dolphin kicked mc's ass.

QTextEdit and QTextCursor fun

My problem is simple: when I open lokalize, it's using the RTL interface and I see the original English text in RTL mode. This just looks bad, as it always needs to be LTR. Should be simple, not?

So I started writing some small tests (yes David, I do small scale tests!). In this test I am doing the exact opposite: I am forcing an RTL paragraph on an LTR interface.

First test:

QTextEdit *e1 = new QTextEdit;
QTextOption o;

o = e1->document()->defaultTextOption();
o.setAlignment(Qt::AlignLeft);
o.setTextDirection(Qt::RightToLeft);
e1->document()->setDefaultTextOption(o);
e1->setText( QLatin1String("1) Currect direction on QTextEdit, wanted RTL!") );

This seems to work fine. However, lokalize creates a QTextCursor and inserts text to that cursor. Ok, second test:

QTextEdit *e2 = new QTextEdit;
QTextCursor tc = e2->textCursor();
QTextCharFormat tcf = tc.blockCharFormat();

tcf.setLayoutDirection( Qt::RightToLeft );
tc.insertText( QLatin1String("2) Wrong direction on QTextEdit, wanted RTL!"), tcf );
e2->setTextCursor(tc);

This does not work. The text is still LTR, even tough I modified the text char format of this text cursor. I sent a bug to Nokia with this mini-application, and it's marked there as N229677.

I talked with a fellow hacker here, and he sent me this piece of code (which does work), third test:

QTextEdit *e3 = new QTextEdit;
QTextCursor tc = e3->textCursor();
QTextBlockFormat tbf = tc.blockFormat();

tbf.setLayoutDirection( Qt::RightToLeft );
tc.setBlockFormat(tbf);
tc.insertText( QLatin1String("3) Correct direction on QTextEdit, wanted RTL!") );
e3->setTextCursor(tc);

Now, I don't really understand why the second test does not work. IMHO, the higher level API used in the second test should work, but I assume that using this low level (which is used in the third test) is fine as well... I will commit this to lokalize as soon as I test on a live lokalize, but it's just crashing on startup since 3 days ago (yes, I am using runk). Is this a known issue?

lokalize goodies!

I just upgraded my SVN, and I saw that lokalize got lot's of new bling-blings in trunk (KDE 4.2)! Now by default it loads the project in the main window, and when you need to edit a PO file it gets opened in a tab. SWEET, way to go to the usability guys! Way to go Nick!

BTW:
I decided to move my English writing to this blog, and keep the old one for Hebrew posts.