All your language are belong to mini18n

Mini18n is a tiny i18n library that was original designed to handle translations in Yabause and that is now available on some Linux distribution (well... at least Debian and Ubuntu) as a dependency of the emulator.

When I started working on translation support for Yabause, the obvious solution, as a Linux user, would have been to use gettext. But this solution had a number of shortcomings:

• gettext is painful to include/maintain in a project: we're using it to translate the glade port of DeSmuME and I still don't understand how it works and/or how to fix it when it
  breaks;


• we needed a portable solution, something that could be easily built on different platforms Yabause supports;


• we also wanted to be able to staticaly link it into Yabause binary, so we didn't had to ship some extra DLL.

(btw... I can be wrong on some/all of these points, I'm not a gettext expert)

So I ended up writing a small translation library and make it live in the Yabause CVS, so every Yabause developer could fix it, if he needed to.

This was two years ago, and not much changed since that time: CVS is now a SVN ; Gtk+, Qt and Windows ports of Yabause can use mini18n for their translations ; I also started to work on gettext format support for mini18n but didn't finished it; all in all, there wasn't much interest in the library until recently.

Some friend asked me if mini18n could be updated to include multiple language support... at once. He's working on some server software and thought about using mini18n to translate
strings sent to the client. Problem is if you got some french, german and italian users at once, you only have two choices: fork a process for each different language or load those three languages in the same process with a multi-language library.

After taking a quick look at mini18n codebase (yeah... it was a while I didn't worked on it...), I realized it wouldn't be hard to add the feature. On the other hand, the project sounded quite fun and would double the number of programs using mini18n! In fact, the change took me longer than I expected, mostly because I wanted to keep old single-language interface intact and also the two interfaces to play nicely with each other. So, mini18n has now a new API and the old API was rewrote on top on the new one. There shouldn't be problems for a program to use both APIs at the same time.

Next step will be to make sure I didn't broke ABI compatibilty with previous release and if that's ok, we may see another mini18n release soon!

C'est l'histoire d'un make

Il n'y a pas d'alternative viable aux autotools.

Tel est le point de vue sur les moteurs de production (heu... c'est quoi ce terme ? ils ont fumé quoi chez Wikipédia ?) que j'ai défendu ces dix dernières années, depuis le début du développement de Yabause. Cela n'a pas été facile tous les jours, il a fallu que réfute les arguments contraires de toutes les manières possibles : soit en argumentant, soit en jouant de mauvaise foi, soit en éliminant mes adversaires (heu...) ; bref, il a fallu que je bataille durement... mais voila, toutes les bonnes choses ont une fin et aujourd'hui Yabause est en train de quitter les autotools pour CMake.

Les opposants aux autotools ont donc remporté la bataille et leur victoire s'appuie sur quelques points :

• les autotools sont prévus pour un environnement Unix, leurs dépendances ne sont raisonnables que dans ce cadre ; demander à un utilisateur Windows d'installer une couche d'émulation de l'environnement Unix pour compiler un logiciel n'a aucun sens ;
• de plus, Yabause nécessitait des autotools récents ; par exemple les versions par défaut de MinGW ou celles installées sur Mac OS X n'étaient pas suffisantes, il fallait donc les installer à la main (avec leur dépendances aussi, pendant qu'on y est) ;
• les scripts autotools sont difficilement maintenables et ceci pour plusieurs raisons, notamment la séparation entre configuration (autoconf) et construction (automake) ou encore le fait qu'autoconf ne soit qu'un système de macros, etc. ;
  
• les autotools ne sont pas réellement des outils, mais plutôt une quête mystique : il faut être initié, lire de vieux grimoires et admettre qu'au final, on ne peut pas tout comprendre ; par exemple dans le manuel d'automake : « The reason for this is a bit hard to explain, but suffice to say that it simply won't work. »
• Sûrement plein d'autres raisons... il faudrait demander aux purs anti-autotools :)

Au final, le point qui m'a permis de tenir aussi longtemps sans changer de système était que, d'accord, on change de système... mais qui s'occupe de réécrire le biniou ?

Et la, je dois avouer que mes adversaires ont été forts, très fort ; parce que c'est moi qui ai lancé le mouvement ! Bon, par contre, j'ai rapidement été rejoint par le reste de l'équipe et c'est à ce moment que j'ai compris que j'avais fait le bon choix : je n'allais plus être seul à maintenir ces saletés de scripts de construction !

À l'heure actuelle, nous sommes toujours en train de travailler sur les nouveaux scripts (on ne rattrape pas une dizaine d'années en deux semaines...), mais dans l'ensemble les choses se passent bien : les principaux ports (cross-) compilent et CMake a clairement une syntaxe et une utilisation plus agréable que les autotools. J'ai d'ailleurs un peu peur d'avoir été converti... je ne suis pas sur que je réutiliserais les autotools pour un projet un jour ; il va falloir que je trouve un nouveau titre à mon blog :)

Grosse Fatigue

Les lecteurs attentifs l'auront noté : ce blog, après l'effervescence des débuts, est retombé dans une léthargie profonde ; mais ce n'est que la partie visible de l'iceberg. Depuis un mois environ, j'ai eu une phase à vide, ou je n'avais plus aucun courage pour maintenir quoi que ce soit ; ce qui s'est plus ou moins ressenti sur mes projets personnels. Mais bon, je ne m'excuserais pas plus longtemps pour le manque de billets, je ne voudrais pas passer pour l'homme le plus ennuyeux du monde ;)

Récemment, j'ai repris une activité timide, notamment sur DeSmuME et Yabause (enfin, sur mini18n, en fait), mais surtout sur respire (ma bibliothèque de manipulation de fichiers resources) qui devrait bientôt être assez développée pour réécrire le fichier resource de Yabause à l'identique. Et oui ! Incroyable ! Elle sera capable de faire rien, ce qu'on appelle un point fixe en mathématiques :) Mais heu... bon... ensuite, je pourrais ajouter des trucs super intéressants dedans :p

Pour finir, un peu de musique avec un truc sur lequel je bloque depuis un moment déja : L'hymne à la joie de The CNK ; c'est très très bon et en plus, c'est français, unbelibubble, non ?

Trad' en trois actes

ACTE I : innocence

Il y a quelques temps, suite à une idée de Romanito, je m'étais lancé dans l'écriture d'une extension MediaWiki pour gérer des traductions. Le principe était simple, les chaînes à traduire et les traductions étaient stockées dans des pages wiki, l'extension ne fournissant qu'une manière simplifiée d'éditer les pages. Les traductions pouvaient ensuite être récupérée par un script Python pour être incluse dans le logiciel à traduire. Le système était simpl(ist)e, fonctionnel et je l'ai d'ailleurs mis en production et testé sur le wiki de Yabause.

Cette partie de l'histoire s'achève là, ou presque... je me suis ensuite rendu compte que pour pouvoir traduire le port Windows de Yabause, il me faudrait des outils qui n'existaient pas encore et je me suis alors lancé dans leur développement. Et je n'ai pas fini.

ACTE II : révélation

Une bonne partie de mon temps de travail est consacrée au développement d'Okawix, un navigateur hors-ligne pour les contenus de Wikipédia. Un des points fort du logiciel est qu'il permet de récupérer facilement le contenu de tous les wikis géré par la fondation (oui, même Wikipédia en normand, dé diou). Pour faire bonne mesure, il fallait pouvoir proposer aux utilisateurs une traduction de l'interface dans un maximum de langues.

Tout ceci nous a amené à découvrir un projet absolument fabuleux: translatewiki.net (TWN). En gros, l'idée est la même : amener des gens à traduire en passant par une extension de MediaWiki ; par contre, le projet est beaucoup plus avancé : l'extension est stable, gère plusieurs projets, plusieurs formats de fichier et les contributeurs sont nombreux.

Après avoir fourni un patch pour le support des DTD, Okawix est venu s'ajouter à la liste des projets gérés par TWN. Et la, je dois dire que j'ai été impressioné par la vitesse à laquelle le logiciel a été traduit dans des langues plus ou moins exotiques. De plus, TWN est configuré pour accéder directement à notre dépôt : en lecture, pour récupérer les nouvelles chaînes à traduire, et en écriture, pour nous envoyer les traductions. Un vrai bonheur.

ACTE III : tentation

Avec d'un coté un mini-projet que je suis seul à (ne pas) maintenir et de l'autre un projet maintenu, actif, en évolution et qui a réuni autour de lui une communauté de traducteurs, je pense que le choix va être rapidement fait :)

Bien sur, tout n'est pas encore prêt à fonctionner et le ne le sera pas demain : il faut déja postuler sur TWN et être accepté ; mais même avant cela, il faut terminer la bibliothèque Respire pour que le port Windows soit complétement traductible, écrire un patch pour TWN pour gérer le fichiers de traduction de mini18n et surement d'autres détails à régler.

Bref... encore pas mal de choses à faire en perspective, mais l'idée d'avoir un système de traduction fonctionnant de manière autonome est séduisante, très séduisante et mérite surement le détour.

Quand Yabause rencontre Haiku

Il y a quelques jours (le 14 septembre, pour être précis) le projet Haiku sortait une version alpha de son système d'exploitation. Il m'était arrivé de tester cet OS par le passé, mais sans jamais réussir à en faire grand chose, cette version alpha semblait le bon moment de refaire un essai ; hop, c'est parti, j'installe le truc dans Qemu.

Ma première impression est qu'ils ont du demander à Biff de passer du polish et deux couches plutot qu'une, il se dégage du truc une impression de finition assez agréable. Une fois l'impression passée, je me suis demandé ce que je pourrais tester... bon ok, je lance le navigateur, je poste un truc sur identi.ca, ok ok, ça fonctionne. C'est bien tout ça, mais est ce qu'on peut vraiment utiliser ce truc ? genre développer ? ah mais oui... essayons de compiler Yabause ! :)

Et la, deuxième surprise, tout se passe à merveille, tout ce dont j'ai besoin pour compiler est installé par défaut : subversion, les autotools, gcc, etc. Pire encore, la compilation passe du premier coup et génère le moteur d'émulation ; bon bien sur, il n'y a pas d'interface pour tester et il manque deux, trois bricoles comme le son, par exemple. Mais OpenGL est bien detecté et toute la partie graphique devrait donc être fonctionnelle.

Au final, j'arrive à deux conclusions : le système de compilation de Yabause est assez intelligent pour se débrouiller sur un système inconnu ; comme quoi, les autotools c'est pas si mal. D'un autre coté, Haiku est assez avancé pour pouvoir compiler un Yabause fonctionnel et je pense que quelqu'un de courageux pourrait créer facilement un port Haiku de Yabause.

Messieurs les courageux, c'est donc à vous de jouer ! :p (au passage, si vous avez un copain courageux qui s'ennuie, j'ai une version Mac qui prend la poussière...)

Début de la fin

Après avoir longtemps attendu que ma partie développeur arrive à pondre un moteur de blog assez fonctionnel pour pouvoir poster un billet, ma partie utilisateur en a eu marre et a créé un compte sur blogger ; au final, tout le monde est content, je peux poster facilement des trucs et j'ai du temps pour coder d'autres trucs.

"Quels autres trucs ?" me diraient vous... hé bien, principalement respire, qui devrait au final être une bibliothèque pour gérer des fichiers resources windows. L'idée au final étant de coupler respire et mini18n pour permettre de traduire les interfaces des différents ports de Yabause (et surement de DeSmuME aussi) en n'ayant à maintenir qu'une seule traduction par langue ; et non pas, une traduction pour la version Gtk+, une pour la version Windows, etc.

Au début, je comptais gérer ça avec un simple grep, mais dans un fichier resource les tailles des éléments sont en dur, il faut donc redimenssioner les éléments que l'on vient de traduire, et ceux qui les contiennent aussi, hu... donc voila, je me suis lancé dans un compilateur de fichiers resources et histoire de rendre le sport intéressant, je suis parti from scratch, en C pur, mode guerrier assoifé de sang.

De la à ce que mon coté utilisateur s'impatiente et demande un truc vite fait avec lex et yacc...