i18n Semantics Cheat Sheet

For quite some time when applying formatting in GUI development one either needs to apply directly visual HTML markup or some sort of odd plain text formatting. Thankfully the internationalization system supports more sensible ways of doing this, in particular semantic markup rather than visual markup.

Let me illustrate the difference quickly. Say you have a title in HTML and you want the title to have a special format. The visual way to go about this woud be:

<b><em>This is a Supreme Title</em></b>

the semantic way however looks like:

<h1>This is a Supreme Title</h1>

In a semantics markup you are not defining how something looks, but what it is, the visual appearance of this thing is defined somewhere else. Just like in the example above, if you use the h1 tag you can easily format all primary headers in a unified fashion using CSS, if you use the visual tags and want to change something you will have to manually walk through all your HTML code and change it.

Now, the very same problem applies to strings you might want to use in your code. For instance you might have something like that in your code:

i18n("I deleted <qt><b><em>%1</em></b></qt> muhahaha!", a);

Should you not have a lot to do with i18n or l10n, a translator would get this string in most editors exactly like that (i.e. including your markup). There are multiple reasons why this is bad. For one, the translator could accidentally break the markup (since he needs to copy it into the translated string), for another, the translators do not know the context of this message and will have a hard time translating it properly. Additionally of course the same problem applies as with HTML and changing the appearance.

The awesome i18n/l10n crew hence came up with a very nice system to solve this using semantics markup.

Applying semantics markup the above string could look like this to provide both context for the translators and useful default formatting for the file name that will be inserted at %1:

i18nc("@info", "I deleted <filename>%1</filename> muhahaha!", a);

If you are developing software using the KDE platform then please checkout the detailed semantics page and use semantics to make our translators’ life easier and your formatting more coherent with the rest of the system.

We at Kubuntu certainly endorse i18n semantics and apply it whenever possible in our software, due to that we created a cheat sheet  that helps with remembering the various markups tags .

[Also available as SVG]

KDE MM + Edu Sprint 2010 in XRandr

And what a sprint that was!

To only mention some of the highlights:

Now for the exhausting details… 😉

On Wednesday 19 May I left for one of the most awesome trips ever. Destination was Randa, somewhere in the .ch alps (Marble can show you). After a night without sleep in a very crowded and stuffy train compartment with 5 rather sleepy Hungarian dudes  I arrived in Zurich (which also happens to be somewhere in .ch I have been told) where I met emonkey (from the german Kubuntu team) and had loads of coffee, until I finally departed to Randa itself. Now let me tell you one thing: if you want to see .ch properly, go through it by train. On a day with good weather it is pure awesome.

At some point I actually arrived in Randa and guess what … no Internet!!! OMG!!! … so while we were waiting for supper we did a bit of socalizing outside – community bonding one might say. The rest of the evening I spent worring about how we did not have a schedule and how some people failed to come up with one. The next morning we still didnt have one, so I came up with one which promptly got overpopulated with sessions. Having that tight a schedule I was sort of running around taking part in the most interesting sessions 😉

I have learned about QML, Pulse, distribution problems, Marble’s awesomeness and a lot more…

As a Kubuntu dev  I fortunately  think that I was able to get rid of some myths about Kubuntu and Canonical and Ubuntu. Also we took a look at a proposal from Canonical regarding a central point of management for audio related activites (including volume and music player controls). Resulting from our discussion we already started discussion on how to implement this in a KDE software context.

Additionally Frederik and I started working on a new Linux distribution, called Fluffy. I highly recommend that you like it on Facebook until Ian comes up with a MySpace page for us. Clearly we are going pink and fluffy with it (hence the name). It originated from our desire for a working fluffy bunny Plasma theme, and the fact that I created a Parley theme out of the fluffy sources I had lying around. Fluffy is in a pretty awesome state already and if I knew what distribution to use as a base we would already have released an alpha, therefore I would very much appreciate input on what distribution to use 🙂

It was one awesome sprint, with awesome people, loads of discussion, loads of fun and apachelogger. Can’t wait to see everyone again!

Ooops, we did it again

This is a response to http://soliverez.com.ar/drupal/node/103

To spare you the time for reading: it’s basically about how translations are broken in Kubuntu jaunty even though KDE 4.3* is installed which should have fixed the brokeness and that is no good sign for karmic.

While I like it a lot that actually, for once, someone actually complains in a meaningful way so that stuff gets fixed (though, since I am sure it will be commented, I must also agree that it shouldn’t have been broken to begin with), the spread FUD is a bit worrying.

So, in order to get rid of the FUD, let me explain a bit.
a) in Kubuntu (and Ubuntu for that matter) translations of software with ultimate Canonical support (i.e. what the techies would refer to as packages residing in main, which is this by Canonical supported part) is detached from the source
b) right, in KDE it is as well (meaning translations are in kde-l10n-fb and not kdebase itself)
c) a) actually consists of b)+additonal stuff (e.g. Amarok… it is not part of core KDE so its translations are not in kde-l10n-fb). So what actually happens that leads to Kubuntu’s detachment is that at build time the translations get stripped from all packages in main and imported into launchpad, from where they get exported every once in a while and hopefully work as expected
d) 4.3 for jaunty is deployed via a PPA (i.e. c) does not apply, since there is no stripping+import+export-via-launchpad, but a) is still valid
I hope you can follow…
e) since Kubuntu does not (yet) install kde-l10n-fb by default, deploying that package via the PPA doesn’t make too much of a difference since one would need to manually install it
f) so we have: a) providing a Kubuntu language pack for stock jaunty c) is not applying and e) prevents easy solution.

Since I am pretty sure I lost you, dearest reader, I’ll just explain it a bit more. The translations in your jaunty installation don’t come directly from kde-l10n packages but a package specific to Kubuntu, those packages only get updated via launchpad. Since KDE 4.3 for jaunty is not deployed via Ubuntu directly, those Kubuntu specific packages can not be updated with KDE 4.3 translations. So, when you install KDE 4.3 from the PPA you actually get KDE 4.3 but still stick to the KDE 4.2 translations. The only way to work around this, would be by deploying kde-l10n along the KDE 4.3 packages, but currently those kde-l10n packages are not getting pulled in by default, so that would only help those that know about this particular fix. However, that last point ought to change in 9.10 (according to Riddell) but AFAIK that is not yet the case (Arne to the rescue!). So, it should be possibly to deploy KDE 4.4 for karmic with actually working translations.

At this point you hopefully understand why backport deployments (no matter whether they are done via the Ubuntu backports repository or a Kubuntu PPA) will never ever give any indication as to what the status of translations in the current development series is.
While on jaunty with KDE 4.3 you either get KDE 4.2 translations (via regular language packs as exported from launchpad) or KDE 4.3 without launchpad influence (in case you manually install a kde-l10n package), karmic by default comes with KDE 4.3 translations (via regular language packs as exported from launchpad). So no matter what jaunty l10n != karmic l10n.

Somehow I have a feeling that I didn’t quite explain what I wanted to explain… ah well, at least I explained something 🙂

oh, right, one last note: translations from kde-l10n-* will _always_ override the Kubuntu specific packages (which is also why having kde-l10n installed would help with backport deployments)