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.