Et oui, vous ne rêvez pas, malgré le fait que le mois de février soit ridiculement court, je trouve tout de même le temps d’écrire mon billet de l’app django du mois. Comme quoi, tout arrive.

Bon il faut dire, que j’ai du coup sélectionné une app assez petite, que j’ai découvert grâce à #django-fr (merci les gars) et avec une doc très bien conçu que je vais donc pouvoir honteusement recopier en parti pour vous expliquer comment cela fonctionne.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Sur la page qui lui est dédiée sur google code. Et pour l’installer, point de tar.gz, de easy_install ou de pip. Le seul moyen de l’installer consistera à faire un bon vieux svn checkout des familles.

Au niveau de la doc, il n’y a que la page du project home du google code. Mais par contre, elle est super bien foutue.

Rendre heureux aussi, ceux qui ne parlent pas français (personne n’est parfait 🙂 ).

Django-transmeta tente de répondre à un besoin tout con, comment traduire efficacement son contenu, lorsqu’on a un site multi langue. Parmi tout les moyens imaginables pour faire cela (j’en reparlerais en fin de billet), transmeta a choisi de modifier directement les tables des modeles à contenu traduisible.

2- Comment ça marche ?

Je vais reprendre, texto, les exemples donnés par la page web de transmeta, parce qu’ils très clairs. Prenons l’exemple d’un model qui décrit un bouquin.

Tel que :

Là, rien n’est traduisible. Imaginons que l’on veuille traduire la description et le body. Rien de plus simple, le code du model devient alors :

On rajoute une metaclass et on défini dans la classe méta, les champs que l’on veut traduire.

Il faut ensuite, dans le settings.py, définir les langues que l’on veut gérer, par exemple :

Et qu’est ce que cela fait ?
Un petit manage.py sqlall va vous le dire :

apparaît ici la solution utilisé pour transmeta. Chaque champ qui est défini comme traduisible donne lieu à n champs en bd, pour n langues.

Là vous allez me dire : ‘Ok, bien cool, mais comment on fait quand on rajouter une langue ou que l’on veut faire en sorte qu’un champ existant qui n’était pas traduisible le soit ?’
Forcément, c’est prévu. Sinon, je n’aurais pas osé faire de billet. Donc il y des commandes manage.py spécial pour altérer les tables déjà existantes et permettre de rajouter soit des langues, soit des champs traduisibles.
Dernière chose, il y a tout ce qu’il faut de prévu pour pouvoir gérer ses champs dans l’admin.

3- Retour sur la méthode

Le principe de fonctionnement de transmeta implique de devoir utiliser des alter table à chaque fois que l’on veut rajouter une langue ou un champ. J’avoue que je n’ai jamais aimé les alter table sur du sql. Est ce un tort que j’ai ? Je ne sais pas.
Vous me direz que si l’on utilise pas d’alter table, on se retrouve presque les mains liées et qu’il ne reste que peu de solution, à part des grosses tables sous la forme ‘langue code’, ‘field name’, ‘trad’. Il est vrai. Mais bon, j’aime pas les alter table.

4- Retour sur le titre du billet :

Tout le monde aura compris, bien entendu, le jeux de mot. C’est une référence directe à transmeta, l’entreprise américaine qui faisait des processeurs ni ne chauffaient que très peu et qui donc n’avait pas besoin de ventilo. D’où le sans suer. C’est nul, je sais.