Avant de me lancer dans la conception d’un thème j’ai voulu essayer de voir comment Drupal fonctionnait au niveau de la gestion des extensions. Tout d’abord les thèmes et les modules sont séparés ce qui permet d’intégrer plus facilement un concepteur graphique dans un projet. Les thèmes sont à rajouter dans ‘sites/all/themes‘ et les modules dans ‘sites/all/modules‘.

Je cours chercher un premier module à intégrer dans mon site: FCKeditor. J’utilise déjà cet éditeur en ligne dans Plone, cela me permettra de comparer la difficulté d’installation dans les deux cas.
Pas de chance, ce module est relativement complexe à installer. Une fois l’archive décompressée dans votre arborescence il faut encore aller chercher une version de fckeditor sur son site officiel et la déposer dans le module. J’espère que la dernière version de FCKeditor est compatible avec cette version du module.
Ensuite, pour avoir la possibilité d’utiliser un navigateur de fichier lors de l’édition des pages il faut encore suivre une procédure pour l’activer. Le fichier README est là pour me guider, mais la procédure est pour Drupal 5.2. Je croise les doigts.
Au final, de retour dans l’interface de configuration des modules le menu FCKeditor est bien présent, mais il me demande d’aller configurer les permissions pour savoir si les anonymes et les utilisateurs authentifiés peuvent utiliser ce module… beaucoup de chose à faire pour avoir une installation fonctionnelle par défaut.

Les autres modules présents par défaut dans Drupal 6 présentent un niveau de complexité moins élevés dans le sens où il faut les activer (forum, blog, sondage,…) puis gérer les permissions.

Pour installer FCKeditor dans Plone il faut décompresser l’archive, redémarrer le serveur puis appuyer sur le bouton ‘installer’ dans l’interface de configuration. L’installation est fonctionnelle immédiatement sans même avoir lu le README.

Pour moi c’est un mauvais point pour drupal : mes modules n’intègre aucune procédure d’installation automatique qui les rend fonctionnel
 immédiatement pour un débutant. Cela me ramène 4 ans en arrière pour le monde Zope.

Maintenant que je peux créer un peu de contenu je vais pouvoir m’atteler à la création d’un thème.

En tant que salarié du groupe Alterway nous avons eu compte d’essai chez Nexen services pour hébergé un site en PHP/MySQL. En temps que développeur Python nous nous sommes posé la question: « C’est bien gentil, mais à quoi cela va-t-il nous servir ? ». Pourquoi ne pas tester un framework LAMP en reprenant un site fait de bric et de broc pour en faire un site professionnel… pour l’instant le nom du site restera secret.

Après investigation auprès de mes camarades de Nexen c’est sur Drupal que je vais faire mes armes. Cela fait 5 ans que je n’ai pas touché à du PHP, j’ai un brin de nostalgie. La première chose à faire est de trouver de la documentation. Un coup d’œil dur le site de la communauté drupal française et me voilà avec un tutorial un peu court mais suffisant pour commencer.

Viens la question fatidique de la gestion du projet. Je serai seul pour le moment, mais le développeur de la version précédente du site viendra sans doute me donner un coup de main durant la phase de migration. De plus, je voyage beaucoup, un système centralisé n’est pas envisageable.

Il me reste bazaar, darcs, mercurial et git. J’ai déjà testé les trois premiers avec un penchant pour darcs mais c’est un bonne occasion pour tester git qui semble avoir le vent en poupe. un coup de ‘man
gittutorial’ pour démarrer :

Préparation des sources en local

$ tar zxf /home/encolpe/Desktop/drupal-6.4.tar.gz
$ mv drupal-6.4/ drupal-nexen
$ cd drupal-nexen/
drupal-nexen$ git init

Initialized empty Git repository in /…/drupal-nexen/.git/

drupal-nexen$ git config –global user.name “Encolpe Degoute”
drupal-nexen$ git config –global user.email encolpe@gmail.com

drupal-nexen$ git add .
drupal-nexen$ git commit
…
drupal-nexen$ tar zxf /home/encolpe/Desktop/fr-6.x-1.x-dev.tar.gz

drupal-nexen$ git status
…
drupal-nexen$ git add */*/translations *.fr.txt
drupal-nexen$ git commit
…

La prise en main de git semble simple jusque là.
Faire un ‘git add .’ est beaucoup plus explicite que la commande ’svn import’: c’est le dossier courant qui est importé, pas de doute possible.

Il faut ensuite configurer un client FTP pour déposer vos fichiers sur votre compte hébergé. Je choisi le logiciel en ligne de commande ‘ncftp‘ dans l’espoir de pouvoir le coupler avec les commits dans la branche principale de git pour gagner un peu de temps.
Ce couplage devra être asynchrone…

J’ai maintenant un beau site qui me montre sa page d’installation sans me demander de mot de
passe (sic). D’ailleurs il ne semble pas très content. Soit disant il faut que je copie ‘sites/default/default.settings.php‘  dans ‘sites/default/settings.php‘ . Pas de panique.

drupal-nexen$ git mv sites/default/default.settings.php sites/default/settings.php
drupal-nexen$ git commit sites/default

Ensuite vous pouvez modifier le paramètre db_url pour les accès à votre base (notez la triple présence de username) :

$db_url = ‘mysql://username:********@mysql.username.nexenservices.com/username’;

Après un nouveau commit et le transfert du fichier vers votre compte hébergé vous pouvez maintenant terminer l’installation en choisissant la langue de votre site et en laissant faire l’installeur… ou non.

Erreur en installant Drupal

Vu d’ici cette histoire de ‘register_globals‘ à désactiver semble un brin complexe. Est-il possible de configurer ce genre de paramètre avec mon compte Nexen ?

Il faut aller voir sur la page d’accueil du compte http://www.nexenservices.com/webmestres/index.php pour aller chercher la solution. Une fois connecté il faut choisir votre site mutualisé en bas de la colonne de gauche puis cliquer sur ‘Configuration avancée‘ à nouveau en bas de la colonne de gauche.

Il faut configurer la racine du site, soit le dossier ‘/‘ et désactiver ‘register_globals‘, ce qui se fait en deux étapes et en image :

Choisir php et / pour le dossier racine

Il suffit de laisser les choix par défaut et de valider

Maintenant il faut reprendre l’installation en allant sur la page http://mysite.nexenservices.com/install.php et en recommençant la procédure complète. L’installation se termine bien cette fois.

La prochaine étape sera de créer un thème pour le site. Nom de code: Opération Zèbre.

Aujourd’hui un client m’a demandé comment rajouter un sous domaine chez gandi. Pas de problème, j’en profite pour en créer un aussi pour mon prochain billet.

1. se connecter
2. cliquer sur l’onglet « Administration »
3. cliquer sur le nom de domaine choisi
4. en bas de la page, dans les « Paramètres techniques », il faut choisir « Gérer les zones »
5. choisir « Ajouter un enregistrement » en bas de la page
6. Type: A ou CNAME
7. Nom: sous domaine à créer
8. Valeur: adresse IP (type A) ou nom réel de la machine (type CNAME)

La page « Gérer les zones » est mis à jour.

Mais une heure plus tard le nouvel enregistrement à disparu. Tiens, un fantôme dans la machine…
Je recommence la même série de manipulation et je cherche ce que j’ai pu raté.
En fait la constatation finale n’est qu’une étape car un bouton est apparu en haut de la page, à l’opposé des autres boutons. Très bien intégré dans la charte il passe inaperçu au premier coup d’œil. Le bouton dit « Valider les changements ».

Outre le fait que lors de l’ajout du nouvel enregistrement rien ne disait explicitement qu’il était temporaire, le fait que ce bouton apparaisse en haut et soit noyé dans la charte alors que les autres boutons sont en bas de la page est un bon exemple de ce qu’il ne faut pas faire : seule une personne connaissant déjà cette interface va remarquer cette nouvelle zone ou des boutons sont apparus comme par magie. Dans un cas pareil il faudrait avoir un décrochement de la charte graphique pour mettre en avant ces nouveaux boutons et mettre en avant leur importance pour la suite des opérations.

Pour l’instant, nos attendons notre sous-domaine pour tester un nouveau site en conditions réelles.
C’est long d’attendre…

Limi m’a posé la question pourquoi en français nous rajoutions des espaces avant certains signes de ponctuation. Pour lui répondre j’ai effectué quelques recherches qui m’ont permises de m’apercevoir que je me trompais sur certains points.

Espaces en usage avant et après les signes de ponctuation

1. Point et virgule sont suivis d’un blanc.
2. Point d’interrogation, point d’exclamation, point-virgule et deux-points sont suivis d’un blanc et précédés d’une “espace fine insécable” ou ½ cadratin.
3. Les guillemets ouvrants ou fermants sont, respectivement, précédés ou suivis d’un blanc.
4. Les parenthèses ou crochets ouvrants sont précédés d’un blanc.
5. Les parenthèses ou crochets fermants sont suivis d’un blanc.
6. Les apostrophes et traits d’union ne sont ni précédés ni suivis de blanc.
7. Le tiret est précédé et suivi d’un blanc.
8. Les points de suspension sont suivis d’un blanc.

Selon le deuxième point l’espace insécable classique n’est pas le bon caractère dans bien des cas où nous l’utilisons actuellement.

Nos moyens d’action

1. THIN SPACE (&​#8201; / &​#x2009;)

   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

2. ZERO WIDTH SPACE (&​#8203; / &​#x200b;)

   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa​bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

3. ZERO WIDTH NO-BREAK SPACE (&​#65279; / &​#xFEFF;)

   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

4. NARROW NO-BREAK SPACE (&​#8239; / &​#x202f;)

   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa  bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

5. NO-BREAK SPACE ( )

   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa  bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Le premier est convenable pour remplacer le  

Le deuxième est surtout intéressant pour ajouter une coupure naturelle dans un mot un peu long

Le troisième me laisse un peu perplexe ! Je ne vois pas dans quel cas il faut l’utiliser

Le quatrième est convenable pour remplacer le  

Le problème avec tout ça reste la compatibilité des navigateurs… ça va me faire une soirée sympathique. Selon les retours des prochains mois nous changerons peut être de stratégie. En attendant je vais me documenter à la source :

Lexique des règles typographiques en usage à l’Imprimerie nationale

Bibliographie de cette article :

HTML authoring in French

Règles de typographie française

Typographie : ponctuation

Je vais ici parler de la traduction de Plone au complet qui est maintenue par une équipe de traducteurs venant de milieus professionels et de pays divers.

1. La difficulté de la langue

Il y a deux difficultés majeurs dans cette exercice de traduction :

1. la personne ayant écrit la version original inclus forcément des imprécisions voir des erreurs
2. le personne traduisant doit trouver un compromis entre respect du texte original et respect de l’esprit original

En dehors des personnes qui traduisent avec des logiciels de traduction automatique, les traducteurs se trouvent régulièrement avec des mots ou des expressions qui ne veulent rien dire dans leur propre langue ou qui sont difficilement traduisible selon le contexte. Alors que faire ? Laisser le mot original en fermant les yeux ? Trouver une périphrase toujours trop lourde et trop longue pour l’affichage dans un menu déroulant ? Et comment trouver un consensus entre tous les traducteurs ?

J’avais lancé ce wiki lors de la traduction de Plone 3.0: Glossaire Zope

Le résultat fut assez bon au départ car les personnes impliquées s’étaient mise d’accord sur les termes les plus problématiques…

Puis un acteur seul s’est lancé dans la modification de certaines expressions sans en parler, sans même répondre aux courriels qui lui ont été envoyé. Résultat: il nous faut parcourir de longues pages de traduction pour vérifier toutes les modifications apportées par une seule personne pour supprimer les contre sens et les erreurs.

2. Mais quel français parlez-vous ?

Le français c’est compliqué. Moins que le chinois, mais quand même… Que dites-vous de la francophonie ?

Actuellement il n’existe qu’une seule traduction pour Plone c’est la traduction fr-fr qui sert de traduction pour fr-be, fr-ch, fr-ca, etc. Mais voilà, il y a un mois quelqu’un d’outre Altantique s’est manifesté pour dire qu’ils avaient besoin d’un traduction plus spécifique et qu’ils avaient déjà commencé le travail.

Où mettre leurs modifications ?

La première réponse qui leur a été faites étaient: mettez-ça dans les fichiers fr de vos instances Plone et ça suffira bien. J’aimerai bien voir la tête de leurs clients après la migration en Plone 3.1…

La deuxième réponse a été de partir des fichiers fr pour créer des fichiers fr-ca et de mettre leur modifications dedans. Que se passera-t-il lors de la mise-à-jour pour Plone 3.1 ? Il faudra faire du travail en doublon avec la version fr. Avoir une version spécifique impose un travail régulier et parfois de grande ampleur pour chaque mise-à-jour. C’est plus facile de faire ça en équipe que seul dans son coin.

Pour l’instant, je n’ai pas vu de suite à cette naissance de traduction fr-ca.

Les distributions GNU/Linux usent et parfois abusent de python comme langage de script pour la configuration du système. En contrepartie il devient difficile d’utiliser easy_install sans casser le système. Il se peut aussi que certains logiciels python est une liste de dépendances tellement longue qu’il soit impossible de les installer tel quel dans le système avec easy_install. Pour éviter ces écueils, plusieurs parades ont été mises au point et la plus aboutis est sûrement virtualenv.

Les eggs des modules comme python-ldap ou Python Imaging Library sont très dépendants du systèmes et demandent des installations particulières selon les plateformes (PILwoTK ne fonctionne pas sous win32 par exemple). D’autres eggs comme gaphor ou i18ndude demandent quasiment une installation séparée. Pour ces derniers il est possible de sans toucher au Python du système.

Pour commencer il vous faudra choisir sur quelle version de python vous souhaitez travailler :

# easy_install-2.5 virtualenv

ou

# easy_install-2.4 virtualenv

Ensuite vous aller créer une boîte pour votre python :

$ virtualenv --no-site-packages monprojet cd monprojet$ ls

bin         lib

# voici une commande toute prête pour modifier le PATH

$ source ./bin/activate

(monprojet)$ which easy_install

/home/encolpe/monprojet/bin/easy_install

(monprojet)$ which easy_install-2.4

/home/encolpe/monprojet/bin/easy_install-2.4

(monprojet)$ which python2.4

/home/encolpe/monprojet/bin/python2.4

(monprojet)$ which python

/usr/bin/python

À partir de maintenant vous pouvez utiliser easy_install dans votre répertoire sans craindre d’interaction avec le système.

L’installation des modules python demande une précaution: être sur d’utiliser les version 64bits des bibliothèques C sous peine d’avoir de drôles d’erreurs absolument intraçables.

La solution est de déclarer le chemin vers /usr/lib64 explicitement pour lors des l’édition des liens:
export LD_LIBRARY_PATH=/usr/lib64

Exemple avec PIL

Version installé avec libjpeg-devel_32, zlib-devel_64 et freetype-devel_64. A la fin de l’installation on vous dit ça:

--------------------------------------------------------------------
version 1.1.6
platform linux2 2.4.4 (#2, Jul 17 2007, 10:05:5
[GCC 4.1.2 20070115 (prerelease) (SUSE Linux)]
——————————————————————–
*** TKINTER support not available
— JPEG support ok
*** ZLIB (PNG/ZIP) support not available
*** FREETYPE2 support not available
——————————————————————–

Le support jpeg est le seul installé… du coup l’intervenant installe les versions devel_32 pour les autres.