autohibernate, zenity and cron

I have been trying to make a script that should put my laptop into hibernate, run automatically from cron, so it forces me to get to sleep.

I had managed to make it work from a console (tty1), but it seemed as if it refused to work from cron.

During the tests my local mailbox was getting the output of the command, and I stood and watched at this error message for more than an hour trying to figure out what was wrong. I couldn't understand what was wrong:


This option is not available. Please see --help for all possible usages.

This was from zenity and I was starting to suspect that it was failing to expad properly the text variable since it worked with a fixed text.

This was failing:

(...) | /usr/bin/zenity --progress --auto-close --text "'$NOTIFICATION$XMSG'"

And this was working:

(...) | /usr/bin/zenity --progress --auto-close --text "OH!MY!GOD!"


I couldn't figure it out. Until I tried this:

(...) | /usr/bin/zenity --progress --auto-close --text "OH!MY!GOD!îîăăîăî"


And it failed.


God damn! Setting LANG in the script fixed the issue right away!


So, if you ever want zenity to show up from cron dont forget to:

• set DISPLAY
• set LANG

zenity is a pice of shit when it doesn't work. It could have printed the "option which wasn't available".

Coordinating localization via git

Note: this is quite long and might not be interesting for people not involved with /in either of: debian i18n, debian l10n, git, shell scripting.


For some time now I have been the de-facto coordinator of the Romanian localization team. During this time I was faced multiple times with problems related to motivation of the team members, setting goals for a release, coordination of the changes inside the team, integration of new translators in the team, loosing team members, my lack of time on some occasions and other problems.

I thought a lot about how to improve on those points and I was never satisfied with the answers I got. What I think was the worst problem in the team was the inability to set clear goals, especially during lenny's development cycle.

During sarge's and etch's development cycles we were in an infancy state and setting as the goal to have a fully translated installation process was really enough to keep people motivated. For sarge we missed by a small margin, but the translations were of poor quality, while for etch we worked more on improving the translations.


But during lenny it was bad, really bad. My free time had been shrinking for a while, starting with etch's release, and we were unable to set clear goal, since for etch we managed to have the installation process fully translated and a few other translations. There was no way for us to reach 100% translations during lenny's development cycle, so setting that as a goal was really unrealistic. Percents by themselves don't mean anything for people, and as long as there's no substance to those numbers, there's no motivation to reach for one arbitrary percent.

I tried to set as a goal translating the packages installed by default in a new installation, but that hit the eternal question How do we know easily which are those packages?. This remained sometimes unanswered or got an unsatisfying answer. Also, there was a goal to have correct diacritics for Romanian in lenny, to have aspell-ro that uses the correct diacritics.

I even got to a point that I, myself, lost my motivation and set myself a personal goal of overrunning the level the translations that the language just above Romanian had in the po-debconf l10n statistics (ranking between languages). This was nice way for me to keep myself motivated, but I had my reserves in making this motivation public out of fear of being misinterpreted, because, by a strange coincidence, that next language was Hungarian, and in Romania's history there was some friction between Hungaria and Romania, while there are still some tensions with the Hungarian minority in Romania, in areas where they represent the local majority.

I managed to reach my personal goal, but this wasn't addressing the big picture.



So, sometime around the start of this year I started thinking about ways to coordinate the Romanian localization team in order to have:

• a clear goal at any given time
• a way to always be able to change that goal as we go
• a way to sync with eventual calls for translations, or the current sid translations
  
• stats immediately available
• automated checks for spelling, correct diacritics usage and other checks that might be useful (e.g. translation completeness)
• an easy way to assign somebody else as a language coordinator (I would appreciate some help or I might even consider stepping down)
• easy integration of new translators (by providing immediate answer to the question "What can I do to help with the translations?")
  

For short, a tool that would allow the team to work more efficiently while having the possibility to set clear goals in order to keep people motivated.



So after some pondering, I thought that creating a repository with the translations and the helper tools that would do the funky sync, checks, stats would be the best way to do that. So I started hacking on that somewhere around July-August and I published the result, but without much publicity, since it is still incomplete.

Some of the technical details are still in a haze, but I have a general idea and I got some basic functionality.


Today I decided that I should announce this semi-officially though my blog, maybe I get some input, ideas, or even contributions (I really should write a TODO).




I give you the Debian L10n Romanian coordination repository.

This is a git repository that has some tools to facilitate translation coordination and the translations that are current in the distro for the team.


Can be cloned with:

git clone git://git.debian.org/git/users/eddyp-guest/debian-ro-repo.git

or, if you're behind a restrictive firewall:

git clone http://git.debian.org/git/users/eddyp-guest/debian-ro-repo.git



Currently the work flow for updating a translation is as follows:

1. source _bin/polibs (. _bin/polibs)
2. cd foo
3. po_refresh
4. complete the translation
5. po_rearrange "ro.po"
6. git add "ro.po" && git commit -m "updated translation for foo"
7. send the translation ("git format-patch origin" and send the patches by mail, or, alternatively, just "git push")
   

Features:

• provides a po_refresh function that can import material directly from http://i18n.debian.net/material, but can also allow manual imports (template.pot from a call from translation)
• for a new translation: source _bin/polibs (. _bin/polibs), make a directory with the name of the source package, cd into it, and run po_refresh
  
• po_rearrange - beautify and unify the layout of PO files (facilitating compact and sane diff-ing for PO files)
• po_merge uses compendium, if present
  

Planned features:

• sync translations/templates from package VCS-es (Vcs-* headers and debcheckout should be the means to the end)
• po_rearrange should be called as a pre-commit hook; should either reject the commit if the po file was not rearranged, or automatically rearranged before the commit
• generate stats
• add commands for "what's outdated", "what needs review", "submit translation", and maybe "reserve translation for offline use"
• conflict merges should be done via po_merge (.gitattributes is key here)
• support other file types (?) - does this make any sense?
• periodic and automated sync with sid for all translations
  

Problems:

• security - running tests automatically from files within the repo doesn't seem too wise, but looks like the only way to get automated testing on any translator machine; maybe keeping the code in a submodule might address this issue?
• entry level translators still have a hard time - UI sucks now; there should be a wrapper command that should use the library functions and should provide a useful help
  
• is git too difficult ? - git backend usage maybe should be cloaked?
• still in development/alpha stage - I still haven't figured some of the issues
• central repo or really distributed - should there be a central git repo where the coordinator(s) do the pushes? it seems the central repo with a small pushers team for new translators (which can't commit directly) might actually facilitate interactions between experienced and new translators to instruct/bring up to speed the rookies

I was hoping that the release notes for lenny would facilitate from this infrastructure, but unfortunately I was lately in a really inactive period wrt Debian.



Questions, suggestions, ideas are welcome.

signing packages heads-up

When trying to sign some Debian packages fails, you might think that temporally changing LANG to find similar errors on the web is a good idea.

But when you see that the expired key is not the default one and you made sure that the GPG agent environment info is correct, while signing still fails, you might start to consider that bad rendering of the "s comma below" character in your name might be worth taking into account.


gpg: skipped "Eddy Petrișor ": secret key not available


Also, remembering that LC_MESSAGES=C is the right way to have English messages, while preserving all the rest of the localization info, is also useful.

fast translation bug report via icedove

Here's a quick way to report po-debconf transalations:



Courtesy of Quicktext

---

Update: the image above is an animated gif and some viewers might not be able to render such images correctly. Apparently even on the blog the animation isn't visible unless you click on the image itself.

mistranslations - how to deal with it

Aigars, you could use what I already made for the compedia creation. The code is available on i18n.debian.net in my home dir (I thought I exposed it on alioth, too, but I just checked and is not).

The results for latvian are also present.

pbuilder - /etc/pbuilderrc no longer a conffile (333294)

I have just finished a completely functional patch for pbuilder's bug #333294. I started this during debconf7, to be more precise, just after Junichi's talk about pbuilder. This patch makes pbuilder smarter smarter about the information it places in the MIRRORSITE variable of the /etc/pbuilderrc.

And now that file is no longer a conffile[1], and it asks some questions via debconf. And since debconf is translatable, there is a Romanian translation, too.

I have published my changes in my pbuilder git repo on alioth.

Anyone interested in the changes can pull from that repo:

git://git.debian.org/git/users/eddyp-guest/pbuilder.git
or
http://git.debian.org/git/users/eddyp-guest/pbuilder.git


[1] this was the main reason the patch wasn't good enough, since modifying a conffile is RC.

dpkg i18n going backwards?

Now in dpkg I found this:

dpkg: no, cannot proceed with %s (--auto-deconfigure will help):\n
%s

Before there was something like:

dpkg: no, cannot remove %s (--auto-deconfigure will help):\n
%s


This is going backwards wrt to i18n since one of the basic rules of i18n is to have complete sentences, while keeping the verb covered behind some parameter is not a good way of doing that.

My small contribution to pbuilder...

... is a patch that allows a decent default mirror selection via some heuristic and a debconf question.
This is bug number 333294.

The patch is part of the git repo at http://users.alioth.debian.org/~eddyp-guest/git/pbuilder/.git. Since it uses debconf it has po-debconf support and a Romanian translation. The language should be in line with the one used in other templates, but I don't mind if anyone from Project Smith suggests some changes.

PO compendium, next step, use it :-)

I have just enabled creation of "LATEST" links for PO compendiums. The result is that now you can use an automated tool or kbabel to get the latest compendium made from po-debconf translations of packages in unstable.

So your compendium will be in the place like http://i18n.debian.net/~eddyp/compendiums/po/$LANG/compendium-$LANG-LATEST.po

I have took a series of screenshots that show how to configure kbabel in order to use the compendium, but I didn't managed to write some explanations, too.

Screenshots are here (just pick them in order, and you'll probably understand).

The most important are the first 3.

An explanation about step 3, if you defined the language code properly, then you can use the flexible approach:




Otherwise, you need to use a hard coded URL.

Compendiums - enabled for all languages (po-debconf)

I just enabled compendium creation for all languages which had po-debconf translations in Debian.

See (a little) more details in the announce.

po compendiums, just wait a little

It seems that my idea caught Javier's attention and he is already asking to use the scripts for Spanish.

As I have said before, those scripts will work for all languages in due time. Currently, as a test, they are running (or they should starting from tomorrow morning) only for the po material for the languages fr, de, ro and vi.

I intent to make compendiums for po-debconf material, po material[*] separately and another one made from all of them.

Stay tuned. Of course, a proper annoucement on debian-i18n@l.d.o will be done when I'll have something pretty ok.

Meanwhile, unpatient souls can take a peak at the current results

(I just enabled es, just for fun; es is broken, too?!? - or maybe the scripts are doing something wrong :-P - curious people can check, the logs are available.)


[*] which is more tricky since there is a need to merge fr_FR with fr/fr_CA with fr, de_DE with de, de_AT with de... and so on, but zh_TW does not have a zh to be merged with. Also the ll_CC strings should have higher precedence than ll strings.

PO compendiums, 1st step

This is just a proof of concept. And I think those are simple po files not po-debconf files. Anyway, I'll polish the scripts a little more and then migrate it on i18n.debian.net[*]. Of course, this will be done for all languages when the scripts are more stable.

[*] thanks to Christan Perrier, I have access to that machine now

gettext: lesson 2

The first lesson was about wrong assumptions that people do when it comes to i18n. This article is mostly targeted at developers which want to support i18n properly, in particular, plural forms.

This is my second n?getetxt lesson.
This is about making your update-po target to include all the strings you want localized in the pot file.

Probably, at some point you, as a developer have written something like:

print("You won %d point%s", points, points>1?"s":"" ) ;


Well, is nice and dandy that you want to make the proper choice of words when you have more than one point. I appreciate that, but you are doing it wrong. There is a tool for that, as I explained before.

Now, lesson 2.

You have understood what you have to do, but you just hate typing ngettext/gettext all over the place, so you probably defined something like:

#define _(X) gettext(X)
#define _n(sg,pl,n) getext(sg,pl,num)

So now you can write trhis piece of code:

print(_n("You won %d point", "You won %d points", points), points ) ;

The problem: how to convince xgettext to add those strings to the pot file?

Nothing simpler... just add _n as an additional keyword when invoking xgettext... but you have to specify that this is a definition for ngetetxt, so, you will end up having in your update-po target something like this:

xgettext ../src/*.c --keyword=_ --keyword=_n:1,2


TADA!

Thanks...

The answer to my previous question is "to be". That happened thanks to a bunch of people, in no particular order:

• Jens Sidel, for committing and suggesting early activation and advices about switching to PO format
• Christian Perrier, for being a really nice guy and for being the person that made me click and start contributing to Debian
• Kobayashi Noritada, for magic po4a related commands
  
• Frans Pop, for actually activating the thing and for advices
• Andrei Popescu, for the multiple patches sent and the late hours sacrificed on the Romanian localization altar
  
• Stan Ioan Eugen, for the work done on the translation done for 1.119, multiple comments and comments done at really late hours last night
• Dan Damian, for being the first person to translate the Release Notes in Romanian, at my suggestion
• Ruşeţ Zeno, for comments and suggestions
• Denis Barbier and Martin Quinson for creating po4a
• Nicolas François (aka nekral) for maintaining po4a
• Javier Fernández-Sanguino Peña, for making calls to translations and sacrificing the Spanish translation while working on the English text to bringing it in shape
  
• anyone that I forgot or don't know about and had a role in making this possible
• silent reviewers on the debian-l10n-romanian list - I wish you started speaking instead of unsubscribing

Updates:

• David Roundy, for creating darcs with its nice darcs send feature which allowed parallel work
  

"To be or not to be on the first CD?"

That is the question. Well, not personally[0], the Romanian translation of the Release notes.

If you would have asked me yesterday, I would have said the plan is "to be".

Plan: make sure that a decent enough text is committed in CVS at all times.


What happened? Let me see...

(Time stamps are for EET - UTC+3 now - unless specified otherwise)

- pack in the morning
- take luggage to work
- buy train ticket before going to work
- ask on list to take action if I don't act by 03:00am EET (00:00 UTC)
- send the translation as is (25u), maybe the connection at my parents is broken
- leave from work directly to the station
- meet a pair of lovers in the train
- he is so into her
- she plays him like the fool he is
- translate on the train
- 5u and the battery is at 8%
- no "darcs rec", hdd consumes battery
- close lid instead of hibernating
- mini-panic, mini-panic[1]
- resume and hibernate - those percentages seem to change sooo slowly
- arrive home
- Internet connection works, good
- continue updates
- reach 100%
- send first complete draft of the translation for inclusion
- parallel review gathering up to 4 people on #debian-ro for review
- joke seriously about me not being able to send the translation
- ask again for action from the team, if needed
- 02:30 - translation seems to be mature, less an less problems are found, should be committed
- 02:40 forgot to ask activation, new mail
- ??? - turning point?
- send mail... error
- can't send mail with the request to activate Romanian
- provider's network seems to be isolated
- realize I don't know if the commit request reached its target
- frustration eased up by the already made requests to take action, if needed
- 04:30 - power goes out
- no ping from GW either
- 04:30:01 - decide to write a blog about this day
- start in zim
- write a first nice draft - with some exciting writing style
- zim looses my article when trying to remove a link-ified timestamp
- start gedit
- break the plug of the network cable[2]
- 09:09 not even the GW is reachable
- 05:10 sleep
- (expected) 06:30 wake up
- (expected) check the network connection
- translations committed ???
- thank to people / take action yourself ???
- 07:00 (04:00 UTC) Romanian translation and CD images status: ???
- sometime during the day - publish article


[0] pure unintentional rhyme
[1] I never lost files with a Linux FS, but I have the mandatory fear
[2] is not fixed in the socket

TDebs - still brainstorming

This is about TDebs.

Raphael Hertzog raised an important point about tdebs and mirror usage. Not sure how to deal with that yet.

OTOH, silent tdebs' selection doesn't sound bad at all. Thanks Filipus.


More info on TDebs issues: http://wiki.debian.org/I18n/TranslationDataDistribution

I wonder ...

... if these stats do something special about those acceleration keys. Of course, these don't make much sense in Debian context, but maybe these stats and others (KDE, Debian, GNOME etc.) could be integrated into a gettext-devel-tools package upstream so we avoid redundant work.

http://tortoisesvn.net/translation_devel_gui

tdebs - archive layout (updated)

(Some updates, see at the bottom).

Today I have moved the wiki page for TranslationDebs under i18n/TranslationDebs, since it seemed to be a more proper place.

I also read again my proposal, made some corrections and gave the layout proposal some thought. I realised that both compatible layout proposal and the incompatible layout proposal have disadvantages and/or are somewhat inconsistent with the current way the archive and apt work.

So I went on and added yet another proposal which should be some middle ground between the previous ones. Now I am not sure if this new one has any real benefits as opposed to the previous ones and I am not sure if I am still on the right track.

Now I need some help. I suggest interested people to look at the proposals and their advantages before answering the questions below.


So the questions are:

1. which of the following archive layouts seems to be the "right" format?
• f.d.o/debian/dists/DIST/SECT/l10n/LANG/
• f.d.o/debian/dists/l10n/DIST/SECT/LANG/
• f.d.o/debian/dists/DIST/l10n/LANG/SECT/
3. Do we want a binary-$ARCH level at the end of this path? Is the lack of it an inconsistency? Do we want l10n material to be treated so differently? Do we consider the LANG some kind of replacement for $ARCH? Is there any or a significant part of l10n material that is arch dependent?
   
4. Do we want to have a compatibility layer for older dpkg/apt, i.e do we want both an empty Packages and a Translations file in there?
5. Which of the following looks the best for translation selection ? (note that the change of format leads one way or the other to incompatibilities)

• deb-tdeb-$LANG http://ftp.debian.org/debian/ etch main

• tdeb-$LANG http://ftp.debian.org/debian/ etch main

• deb http://ftp.debian.org/debian/ etch main/l10n/$LANG

• deb http://ftp.debian.org/debian/ etch l10n/$LANG/main/

6. Does the package naming needs some rethinking since the current proposal doesn't allow translation installations to be installed via current dpkg implementation?

Update (20070221-1): Filipus Klutiero suggested that it would be nice not to need to add something in /etc/apt/sources.list . I agree, this is a very good idea. There was no suggestion how to do this, but I thought maybe /etc/default/locale can be used for translation selection via a new variable in there. I'll add this to the wiki page, too.

n?gettext usuall assumptions and problems

For those who care about i18n and especially to those that don't care, a mail that I wrote to the Wormux-dev mailing list might provide some insight on the regular issues that plague badly i18n-ed applications.

This is mostly not developers' fault, but the fact that many don't know the real capabilities of gettext.

The post is here.

TDebs - some hours later

... and some brainstorming to think/rethink/remember ideas discussed in Extremadura, and now there is another proposal for tdeb implemenation on the wiki.

Comments, ideas are welcome.

Now I am off to bed.