Conférence à Marseille

En bref, j’ai participé au wordcamp de Marseille le 15 septembre dernier. Durant l’évènement j’ai donné une conférence pour présenter une technique que j’utilise abondement : «coder sans navigateur»


source

Et voici le petit bout de code que je présentais, rien de très sophistiqué, juste du PHP bas niveau, mais que permet de faire tant de chose !

WordPress en plusieurs langues

Solution 1 : Traduction partielle

L’interface est traduit de base, et seule une page est traduite pour renseigner les utilisateurs
Défaut : partielle
Avantage : facile à mettre en place

Solution 2 : Langues mêlées

Les billets sont écrits en plusieurs langue successives
Défaut : adapté uniquement pour peu de textes et peu de langues.
Avantage : facile à mettre en place

Solution 3 : Langues entrecroisées

Chaque billet est dans une seule langue. Si une traduction a lieu, elle est faite dans un autre billet qui sera éventuellement lié à l’original. Les langues s’entrecroisent. Un système de catégorie peut faciliter la lecture.
Défaut : les deux traductions d’un même texte ne seront pas nécessairement liées, ou sinon il faudra le faire à la main en ajoutant une phrase « accéder à la version anglaise du billet »
Avantage : facile à mettre en place. Pratique si l’on s’autorise un « délais » de traduction. Pratique si l’on ne veut pas tout traduire.
exemple :
* http://blogs.lexpress.fr/attali/
* http://ploum.net/ -> http://ploum.net/post/im-a-pirate « Traduction française »

Solution 4 : multi-blogues, ou blogues séparés

Même idée que la solution précédente, mais en séparant complètement les langues sur deux domaines ou sous domaines différents.
Avantage : personnaliser en fonction de la cible… nécessairement différente (une différence de langue entraîne souvent une différence de culture)
exemple :
* http://boilingfrogs.info/ + http://www.tetedequenelle.fr/ -> même auteur, même sujet

Solution 5 : les plugins

… et bien d’autres. La plupart des plugins permettent d’améliorer les solutions précédentes en automatisant et harmonisant le fonctionnement.

En bref, la question n’est pas tellement de savoir comment procéder pour configurer WordPress, mais plutôt comment va fonctionner l’équipe de rédaction, comment vont interagir les auteurs-traducteurs.

créer un site web

En réponse à un échange sur liste de diffusion Ubuntu disponible à l’adresse suivante : http://www.nabble.com/cr%C3%A9ation-de-site-to20837231.html. L’échange a commencé par la question toute simple de créer un site web et des solutions existantes.

l1010859.jpg
Lézard, île Lavezzi, Corse

Je suis développeur web et j’ai eu l’occasion de faire des sites avec toutes sorte d’outils allant de Nvu à symfony en passant par WordPress et Jumla.

Pour moi les outils du type Nvu, dreamweaver ou komposer ne permettent pas de réaliser des sites de qualités car, comme ils ne séparent pas suffisement le contenue de la présentation, toutes mises à jour doit se faire en prenant extrêmement garde aux règles d’accessibilité et d’ergonomie que la personne responsable de ligne éditoriale ne connait pas et n’a pas le temps de prendre en compte. Très vite les sites se retrouve « cassé » (non fonctionnel sur un ou plusieurs navigateurs) ou « mort » (son contenu n’évolu pas).

Par ailleurs, les framework du type symfony, ezPublish ou Drupal s’adresse à des développeurs uniquement pour réaliser des fonctionnalités particulière dans un contexte particulier. Bien sûr, il n’est pas exclut qu’un développeur utilise ces outils pour réaliser un simple site, mais ce sera pour lui un choix dicté par son expérience et non par la logique : on préfère toujours utilisé les outils que l’on maîtrise plutôt que les outils que l’on utilise trop rarement pour bien les connaître quite à utiliser un marteau piqueur pour tuer un mouche car quand on maîtrise l’outil en question, ce n’est pas un problèmes !

Entre les deux, la famille des CMS : WordPress, Dotclear, Jumla, Spip… et bien d’autre ! Je les trouve assez décevant : il ne sont pas à la hauteur du public pour lequel il s’adresse car ils tentent de faire trop de choses et se perdent alors en complexités. C’est en tout cas ce que je pense de Jumla. Certain s’en tire mieux que d’autre, c’est pour cela que je conseil WordPress ou Dotclear dont toutes les fonctionnalités autre que l’écriture de contenu est rejeté dans les nombreux plugin, laissant l’outil simple à prendre en main, tout en lui garantissant des évolutions futures pouvant être complexe. Ma préférence actuelle de WordPress sur Dotclear est sujette à évolution et provient de test réaliser en juin dernier (WordPress vs Dotclear).

Cette retrospective serait incomplète si je n’évoquait pas les outils « en ligne » tel bloger, Google site… Certe ceci on l’avantage sur le groupe précédent de se rapprocher de leur public, notament en supprimant toute la problématique de l’ébergement. Cependant attention ! Ils sont parfois très limité : bloger ne permettra jamais de faire autre chose, qu’un blog. Ceci dit en liant ces outils vous pourrez obtenir des résultats interessant : imaginez quelques pages de présentation réalisé sur Google site, un blog d’actualité sur Bloger, une gallerie photo sur PicasaWeb…. regardez par exemple le site de l’association Sud Rando 34 zéro compétence technique, ça ne paye pas de mine mais toute les informations voulu y sont et c’est l’essentiel ! Le danger et que l’évolutivité n’est pas garantie et l’image n’est pas au rendez vous.

Conclusion : Je laisse aux développeurs le soin de choisir les outils qu’il veulent, mais je conseil à toute personne non technique voulant réaliser un site de petite entreprise ou d’association de le faire avec WordPress pour commencer. Par la suite, il y aura possibilité d’évoluer graphiquement et de créer une « image » par des graphistes professionnels sans rien remettre en cause. De même, le site pourra évoluer sur les fonctionnalités « classiques » grâce au nombreux plugins disponible. Enfin, si l’entreprise à des besoins particuliers elle devra trouver les compétences nécessaires en interne ou en externe.