Call for distros: Patch cups for better internationalization

If you're reading this and use cups to print (almost certainly you do if you're on Linux), you may want to contact your distribution and ask them to add this patch.

It adds translation support for a few keyword found in some printers PPD files. The CUPS upstream project has rejected with not much reason other than "PPD is old", without really taking into account it's really the only way you can get access to some advanced printer features (see comments in the same thread)

Anyhow they're free to not want that code upstream but i really think all distros should add it since it's very simple and improves the usability for some users.

RFC: i18n extraction of desktop-like files

This is a RFC for an idea I want to implement in l10n trunk. I think it will make it easier for us i18n dudes and should not affect (or maybe even should help) the developers.

At the moment if you want to have translations in a file that is ".desktop like" but does not have one of the extensions we extract by default (that is *.directory *.desktop *.desktop.cmake *.kimap *.themerc *.kcsrc *.setdlg index.theme *.notifyrc *.protocol *.profile *.actions) you need to go to l10n-kde4/scripts/findfiles and add a line like
find $BASEDIR/`get_path kdebase_kde-workspace`/khotkeys -name \*.khotkeys -print >> $filelist

My suggestion is move the responsibility of listing those files from l10n-kde4/scripts/findfiles to a file in the program itself (that is, a file in similar fashion to Messages.sh). This serves various purposes:
* Make the developer know there is something he needs to keep updated (it's not the first time people move or delete files and the l10n-kde4/scripts/findfiles get outdated)
* Make it easier for l10n maintainers to move things between l10n trunk and l10n stable, since the things are more autocontained and we do not need to worry about what in findfiles will get outdated or not, or might be reintroduced later if someone decides they need a stable branch

So all in all seems a win/win situation for me. What do you guys think?

Okular website translatable

In the past few days I've been working on using the existing i18n functionality in the KDE website framework (AKA capacity) in the Okular website.

The functionality was added ages ago but it needed some tweaking to support all the Okular website needs.

I've also worked in making scripty extract the messages automatically to .po files so each day the contents of the website are extracted to the trunk/l10n-kde4/templates/messages/www folder.

Of course this can be added to any of the KDE websites. I've added some documentation to the Capacity techbase page, if you find you need more help do not hesitate to ping me on IRC.

Join the KDE translation team

This is a reminder that the various KDE Translation teams are always looking for new contributors, so if you always wanted to contribute to KDE but did not know how to do it, this is your chance, join the KDE Translation team!

This is actually a good moment to join, since the KDE software sources that will end up in 4.6 release are frozen for new messages so no new messages are going to be introduced before the release. A second reason is that the release date is close enough (2 month approx until tagging) so you will see your effort released really soon.

You can have a look at the statistics in the l10n web page, but remember that even if the statistics say a team has 100% of the stuff translated, there is always room for reviewing so your help will for sure still be welcome.

So start your e-mail client and contact me at aacid@kde.org so I can redirect you to the proper people that will help you making KDE rock even more :-)

How to run a Messages.sh file to create your .pot file

Some people regularly ask me how to create the .pot file of their program. They know the Messages.sh file is the key for it but they also realize that doing

cd /path/to/my/project
bash Messages.sh

Does not really work and then they are a bit stalled.

The answer is quite simple, but you need to know it ;-) You have to run the extract-messages.sh script that lives in the l10n-kde4/scripts

That still will fail as the script tries to save the .pot files in a folder called "po", so all in all these are the commands to get the .pot file of your project

cd /path/to/my/project
mkdir po
bash /path/to/l10n-kde4/scripts/extract-messages.sh

And that's it :-)

Join the translation crew

Hi, this is a reminder that the KDE Translation teams are always looking for new contributors, so even if you do not know how code you can help translating the KDE Software to your mother tongue or some other language you are fluent in and make a difference.

This is actually a good moment to join, since the KDE Software Compilation 4.5 sources are frozen for new messages so new messages are going to be introduced before the release and also the release date is close enough (1 month approx until tagging) that you will see your effort be released really soon.

One of the teams specially looking for contributors is the Gujarati team, that met the essential requirements to be shipped with KDE SC for 4.4 but does not to 4.5

And remember, even if the statistics say a team has 100% of the stuff translated, there is always room for reviewing so your help will still be welcome.

So start your e-mail client and contact me at aacid@kde.org so i can redirect you to the proper people that will help you making KDE rock even more :-)

KDE in Interlingua

If you are interested in Interlingua, Giovanni Sora just started the translation of KDE to Interlingua, i'm sure he'll welcome any help. Just comment here or drop me a mail at aacid@kde.org if you want to contact him.

i18n as second citizen in KDE

Sadly it seems that i18n (short for internationalization), that is, making your program available for non english speakers is a second citizen between KDE developers.

Programmers are treating bugs reported against i18n as non critical when effectively they are making their program unavailable for lots of users.

You may think this is a personal perception, but let's mention some examples:
* Plasma: Category names ("Application Launchers", "Astronomy") in the drop down box of the "Add Widget" dialog are untranslatable. Plasma developers excuse themselves saying i18n is not their best aptitude
* Places names are set after first use and don't follow the user locale https://bugs.kde.org/show_bug.cgi?id=177536
* KMail view names have a similar problem, can't find the bug number right now
* Places names for devices are not translatable http://lists.kde.org/?t=123937583500004&r=1&w=2
* Amarok: Items in the playlist layout editor are not translated https://bugs.kde.org/show_bug.cgi?id=189750
* Amarok: Default layout names are not translatable https://bugs.kde.org/show_bug.cgi?id=189751

These are just some examples, don't feel finger pointed if your app is here.

You'll notice that some of this bugs/reports have patches or suggestions on how to fix it, yet nothing has been done to fix them.

So please, don't treat i18n as second citizen, you *really* don't want to alienate so much users from your program.

Translate!

Hello, this is Albert speaking from my new KDE 4 i18n/l10n coordinator position.

If you have always wanted to help KDE and you have knowledge of a language different than english you can do it! Join today your local Translation team and you will improve your english but also your native language skills :-)

Translations for KDE4.0 are closing in about 12 days but there will be a 4.0.1 so don't worry of being late!

And congrats to Portuguese team that has a 100% translation!