Je vous anonce donc la sortie de la version française. Le package, les thèmes et les messages sont maintenant disponibles au téléchargement.

Voici les liens :

• Package Version Française
• Les thèmes de base en VF
• Le fichier de traduction po et mo en UTF-8

Retrouvez toutes les informations sur le blog de la traduction française et le codex

A installer sans modération…

Je viens de retrouver tout à fait par hasard un billet sur la traduction de WordPress en français à laquelle j’ai participé. Bien évidemment, je ne me souvenais plus du tout de cette contribution.

A l’époque, je cherchais à traduire WordPress en Français et je suis tombé sur le site de Xavier Broderie et son site de démo de la VF. En croisant, avec d’autres weblog, j’étais tombé sur le projet de traduction sur la plate-forme Rosetta . J’avais tant bien que mal utilisé l’outil pour donner un coup de main. Mais au moment d’extraire le fichier pour le tester chez moi, la fonctionnalité d’extraction ne voulait obstinément pas fonctionner, je m’étais donc résigné à utiliser poEdit pour achever le travail.

Je suis très content que le projet soit sorti, même si je ne m’en suis pas rendu compte… Je vais voir le résultat pour le comparer à « ma version » française. En tout cas, ça donne en vie de s’investir et surtout cela donne un cadre pour le faire.

Point d’entrés dans la communauté français de WordPress :

• Accueil Français du Codex WordPress
• Liste de diffusion WP-Polygots

Ma page sur le codex

• Relooker la balise select : comment faire pour modiifer l’aspect des select dans les formulaires
• Relooker la balise select le retour : La suite de l’article précédent qui se penche sur les problèmes d’accessibilités
• Top 50 des sites francophones non-conforme : Petite étude lancée par Denis Boudreau il y a quelques jours.

Traduction de l’article JavaScript Triggers.
Translated with the permission of A List Apart Magazine (http://alistapart.com) and the author[s].

L’affichage d’une page web consiste en 3 couches. Le fichier XHTML représentent la couche structurelle qui contient la structure, la sémantique et le contenu du site. À cette couche, il est possible de joindre une couche de mise en page (CSS) et une couche comportementale (JavaScript) afin de rendre le site plus beau et plus facile à utiliser. Ces trois couches doivent rester strictement séparées. On peut de cette façon changer toute la mise en page sans toucher ni à la structure ni aux comportements.

En dépit de la stricte séparation, les couches de présentation et de comportement ont besoin d’instructions de la couche structurelle. Elles en ont besoin pour savoir où ajouter cette jolie touche de style, quand initier cette petite action qui fait la différence. Elles ont besoin de déclencheurs

Les déclencheurs CSS sont bien connus. Les attributs class et id vous permettent de contrôler totalement la présentation de vos sites web. Bien qu’il soit possible de travailler sans ces déclencheurs, en plaçant les instructions en ligne dans l’attribut style, cette méthode de codage est à proscrire. Si vous voulez redéfinir la présentation de votre site avec cette méthode, vous allez devoir modifier la couche structurelle en même temps, il s’agit d’une entorse à la régle de séparation de la présentation et de la structure.

Déclencheurs JavaScript

La couche comportementale doit fonctionner de la même manière. Il faut séparer le comportement de la structure en vous séparant des gestionnaires d’évenements en ligne comme celui-ci : onmouseover="switchImages('fearful',6,false)". À la place, comme en CSS, nous allons utiliser des déclencheurs pour informer le script permettant la mise en oeuvre du comportement adéquate.

Le déclencheur JavaScript le plus simple est l’attribut id :

<div id="navigation">
 <ul>
  <li><a href="#">Link 1</a></li>
  <li><a href="#">Link 2</a></li>
  <li><a href="#">Link 3</a></li>
 </ul>
</div>

var x = document.getElementById('navigation');
if (!x) return;
var y = x.getElementsByTagName('a');
for (var i=0;i<y.length;i++)
 y[i].onmouseover = addBehavior;

Avec ce code, le comportement est déclenché par la présence ou l’absence de id="navigation". S’il est absent, il ne se passe rien (if (!x) return), mais s’il est présent tous les éléments liens qui en descendent auront un comportement au survol. Cette solution est simple et élégante, et elle fonctionne dans tous les navigateurs. Si l’id permet de couvrir vos besoins, vous n’avez pas besoin de lire la suite de cet article.

Déclencheurs avancés

Malheureusement, dans certaines situations il est impossible d’utiliser l’attribut id comme déclencheur:

1. Un id doit être unique dans tout le document et vous pouvez avoir besoin d’un même comportement pour plusieurs (un groupe) éléments.
2. Parfois un script a besoin de plus d’information que simplement “exécutez-moi ici.”

Prenons pour ces 2 problèmes l’exemple d’un script de gestion de formulaire. Il serait pratique d’ajouter un déclencheur permettant d’indiquer qu’un champ est obligatoire. Si nous avions un tel déclencheur, nous pourrions utiliser un script aussi simple que le suivant.

function validateForm()
{
 var x = document.forms[0].elements;
 for (var i=0;i<x.length;i++)
 {
  if ([ce champ est obligatoire] && !x[i].value)
    // Informer l'utilisateur de l'anomalie
 }
}

Mais comment créer un déclencheur XHTML permettant d’indiquer au script que certains champs sont obligatoires ? Utilisez un id n’est pas envisageable : car nous avons besoin d’une solution qui puisse fonctionner sur plusieurs champs. Il serait possible d’utiliser l’attribut class pour piloter ce comportement :

<input name="name" class="required" />

if (x[i].className == 'required' && !x[i].value)
  // Informer l'utilisateur de l'anomalie

Pourtant, l’attribut class est plutôt dédié à la définition de styles CSS. Mélanger des déclencheurs CSS et JavaScript n’est pas impossible mais peut mener rapidement à un amas de code confus:

<input name="name" class="largefield required" />

if (
  x[i].className.indexOf('required') != -1 &&
  !x[i].value
)

À mon avis, l’attribut class ne devrait être utilisé que pour le CSS. Les classes sont les premiers déclencheurs XHTML pour la couche de présentation et les utiliser aussi pour porter une information de comportement complique les choses. Déclencher la couche de présentation et de comportement avec le même attribut class représente aussi une entorse à la stricte séparation du comportement et de la présentation , bien qu’en fin de compte c’est à vous de choisir ce qui est acceptable à ce sujet.

Déclencheurs porteurs d’information

De plus ces déclencheurs peuvent prendre plus d’importance et être plus compliqués que la simple commande “déployez ce comportement ici”. Vous aurez certainement besoin de joindre une valeur à un déclencheur. Une valeur de déclenchement rendrait la couche comportementale beaucoup plus souple, puisqu’elle pourrait répondre à différentes conditions d’exécution pour chaque élément XHTML au lieu d’exécuter bêtement le même script.

Prenez un formulaire dans lequel des zones de texte ont des tailles maximum pour paramètre. Le vieil attribut MAXLENGTH ne fonctionne pas avec les zones de texte, nous devons donc ecrire un petit script pour cela. De plus toutes les zones de textes n’ont pas la même longueur maximum, nous allons donc avoir à renseigner cette information quelque part de façon individuelle pour chaque zone de texte.

Nous voulons avoir quelquechose de la forme :

var x = document.getElementsByTagName('textarea');
for (var i=0;i<x.length;i++)
{
 if ([cette zone de texte a une longueur max])
  x[i].onkeypress = checkLength;
}

function checkLength()
{
 var max = [Lecture de la longueur max];
 if (this.value.length > max)
  // Informer l'utilisateur de l'anomalie
}

Ce script a besoin de 2 paramètres :

1. Est-ce que cette zone de texte a une longueur maximum? Il s’agit ici du déclencheur qui informe le script qu’il y a un comportement à gérer.
2. Quelle est la longueur max? C’est la valeur que le script doit vérifier pour valider la saisie utilisateur.

Et c’est typiquement dans ce cas que la solution basée sur les classes montre ses limites. C’est toujours techniquement possible, mais le code à implémenter devient trop compliqué. Prenez une zone de texte avec la classe CSS « large » qui soit aussi obligatoire et dont la longueur max. est de 300 caractères:

<textarea class="large required maxlength=300">
</textarea>

Non seulement cet exemple mélange de la présentation et 2 types de comportement, mais cela rend la longueur maximum de la zone de texte plus difficile à lire:

var max = this.className.substring(this.className.indexOf('maxlength')+10);
if (this.value.length > max)
 // Informer l'utilisateur de l'anomalie

À noter que ce bout de code ne fonctionne que si le paramètre longueur max. est placé en fin de valeur de classe. Si on veut placer la longueur max. n’importe où dans la valeur de classe (au cas où on voudrait ajouter un autre déclencheur après celui-ci) le code devient bien plus compliqué.

Le problème

C’est bien notre problème du jour. Comment ajouter de bon déclencheurs JavaScript qui nous permettent à la fois de couvrir le cas d’un simple déclenchement d’action (“exécutez-moi ici”) et celui du passage de valeur spécifique à l’éléments ?

Techniquement, nous avons vu qu’il était possible de gérer ces cas avec l’attribut class, mais avons-nous le droit de détourner la fonction l’usage de cet attribut pour porter des informations pour lequel il n’est pas fait ? Est ce une entorse à la règle de séparation de la présentation et du comportement ? Et même si vous ne voyez pas d’obstacle à cette solution, elle reste tout de même compliquée à mettre en oeuvre et requiert un code JavaScript assez ardu.

Il est tout de fois possible d’utiliser d’ajouter des déclencheurs sur d’autres attributs comme lang ou dir, mais , encore une fois, ce serait une utilisation détournée d’attributs.

Attributs personnalisées

Je vos propose une autre solution. Reprenons l’exemple de la longueur max. de la zone de texte. Nous avons besoin de 2 informations:

1. Est-ce que la zone de texte a une limite de taille ?
2. Quelle est cette limite ?

La manière naturelle et sémantique d’exprimer cette information serait d’ajouter un attribut à la zone de texte:

<textarea  class="large" maxlength="300" >
</textarea>

La présence de l’attribut maxlength informe le script qu’il faut vérifier la saisie utilisateur dans cette zone de texte et il peut trouver la taille limite pour cette zone dans la valeur de l’attribut. De la même manière, pour le contrôle d’obligation de saisie, nous pouvons aussi créer un attribut personnalisé. required="true", par exemple, même si n’importe quelle valeur permet de déclencher le contrôle.

<textarea class="large" maxlength="300" required="true">
</textarea>

Techniquement ce n’est pas un problème. La méthode DOM du W3C getAttribute() permet de lire n’importe quel attribut d’une balise. Seul Opera jusqu’à sa version 7.54 ne permet pas de lire un attribut existant sur la mauvaise balise (comme src sur la balise <h2>). Heureusement les version ultérieur assure un support complet de la méthode getAttribute().

Voici donc ma solution :

function validateForm()
{
 var x = document.forms[0].elements;
 for (var i=0;i<x.length;i++)
 {
  if (x[i].getAttribute('required') && !x[i].value)
    // Informer l'utilisateur que le champ est obligatoire
 }
}

var x = document.getElementsByTagName('textarea');

for (var i=0;i<x.length;i++)
{
 if (x[i].getAttribute('maxlength'))
  x[i].onkeypress = checkLength;
}

function checkLength()
{
 var max = this.getAttribute('maxlength');
 if (this.value.length > max)
  // Informer l'utilisateur que la longueur max est atteinte
}

À mon avis cette solution est simple à implémenter et cohérente avec la forme que les déclencheurs JavaScript peuvent prendre: une paire clé/valeur à l’endroit où la clé déclenche l’action et la valeur permet de conditionner l’action en fonction de chaque élément. Finalement, ajouter ces déclencheurs au code XHTML est très simple même pour des webmaster débutants.

DTDs personnalisées

Après l’implémentation de cette solution vous pourrez noter que la page résultante n’est pas valide. À la validation les attributs required et maxlength sont rejetés car il ne sont pas autorisées dans le document. C’est bien sur complètement vrai : le premier attribut ne fait pas partie des spécifications XHTML, tandis que le second n’est valide que sur un élément <input>.

Pour résoudre ce problème, il suffit de les rendre valides; en créant une Définition de Type de Document (DTD) personnalisée qui étend XHTML pour inclure ces attributs déclencheurs. Cette DTD personnalisée définit nos attributs spéciaux et leur place dans le document, l’outil de validation permet de confronter la structure du document à notre version personnalisée de XHTML Si la DTD déclare les attributs valides, c’est qu’ils le sont.

Si vous ne savez pas créer de DTD personnalisée, vous pouvez lire l’article de J. David Eisenberg’s intitulé Creating Custom DTDs (NDT: ou la traduction français Valider une DTD personnalisée) pour tout savoir sur le sujet.

À mon avis, utiliser des attributs personnalisés pour contrôler la couche comportementale et écrire des DTD personnalisées pour définir ces attributs correctement contribue à séparer comportement et structure et à écrire des scripts simples et efficaces. De plus une fois ces attributs déclarés et les scripts rédigés, même un webmaster débutant est capable d’ajouter facilement des comportements complexes dans les documents XHTML.

Version originale par Peter-Paul Koch

Peter-Paul Koch est développeur web indépendant à Amsterdam en Hollande. Il écrit et maintient www.quirksmode.org, un condensé d’environ 180 articles, trucs et astuces CSS et JavaScript, ainsi qu’un système de rapport de bogue et un blog

Traduction de l’article Validating a Custom DTD. Translated with the permission of A List Apart Magazine (http://alistapart.com) and the author[s].

Dans son article de cette même édition (NDT : sur A List Apart – Edition N°194), Peter-Paul Koch propose l’ajout d’attributs personnalisés dans les éléments de formulaire pour déclencher des évènements spéciaux. Le valideur du W3C ne validera pas un document avec de tels attributs, parce qu’ils ne font pas partie des spécifications XHTML.

Cet article va vous permettre :

• de développer des DTD sur mesure afin de déclarer des attributs personnalisés
• de valider des documents utilisant ces attributs.

Voici un exemple de balisage HTML personnalisé qui nous permettra :

• de spécifier la longueur maximale de la zone de texte
• de déterminer si un élément du formulaire est obligatoire ou non :

<form action="http://example.com/cgi-bin/example.cgi">
<p>
  Name:
  <input type="text" name="yourName" size="40" />

</p>
<p>
  Email:
  <input type="text" name="email" size="40"
  required="true" />

</p>
<p>
  Comments:<br />
  <textarea maxlength="300" required="false"
  rows="7" cols="50"></textarea>

</p>
<p>
  <input type="submit" value="Send Data" />
</p>
</form>

Qu’est ce qu’une DTD ?

La Définition du Type de Document (DTD) est un fichier qui spécifie quels éléments et attributs existent dans un langage balisé et comment ils apparaissent. Ainsi la DTD XHTML précise que <p> est un élément valide et qu’il peut apparaître dans une balise <div> mais pas dans <b>. L’adresse URL, à la fin de la déclaration DOCTYPE, pointe à l’endroit où l’on va trouver le fichier de DTD pour la version HTML que l’on va utiliser. Ni votre navigateur, ni le valideur du W3C ne parcourt le web pour récupérer la DTD – Ils ont une liste des DOCTYPEs valides en mémoire et utilisent l’URL pour les identifier uniquement. Comme nous le verrons plus loin, ce comportement change en cas de DTD personnalisée.

Spécifier les attributs

Ajouter des attributs dans une DTD existante est facile. Pour chaque attribut, vous devez spécifier à quel élément il est associé, quel est son nom, quel type de données il peut contenir et s’il est obligatoire ou facultatif. Ces informations sont spécifiées suivant le modèle :

<!ATTLIST
  elementName attributeName type optionalStatus
>

Pour ajouter l’attribut maxlength à l’élément <textarea>, il suffit d’écrire :

<!ATTLIST textarea maxlength CDATA #IMPLIED>

La spécification CDATA signifie que la valeur de l’attribut peut contenir n’importe quels caractères; ainsi maxlength= »300″ ou maxlength= »ten » seront tous les deux valides. Pour les données « ouvertes », les DTD ne nous permettent pas d’être plus précis. La spécification #IMPLIED signifie que l’attribut est optionnel. Un attribut obligatoire serait spécifié par #REQUIRED.
Quand un attribut peut contenir une liste de valeurs, vous pouvez les spécifier dans la DTD. C’est le cas pour notre attribut required, qui ne peut contenir que true ou false. Les valeurs sont sensibles à la casse; dans notre exemple seule les valeurs en minuscules sont spécifiées, donc la valeur TRUE ne sera pas considérée comme valide.

<!ATTLIST textarea required (true|false) #IMPLIED>

Attention à la confusion: l’attribut s’appelle « required » mais n’est pas obligatoire dans tous les éléments <textarea>, car c’est un attribut optionnel. Dans l’ensemble, les modifications des spécifications dans la DTD ressemblent à ceci :

<!ATTLIST textarea maxlength CDATA #IMPLIED>
<!ATTLIST textarea required (true|false) #IMPLIED>
<!ATTLIST input required (true|false) #IMPLIED>
<!ATTLIST select required (true|false) #IMPLIED>

Note: Ajouter de nouveaux attributs à des éléments existants est facile; ajouter de nouveaux éléments est plus compliqué et n’est pas le sujet de cet article.

Placer les attributs

Maintenant que vous avez défini des attributs personnalisés, comment les placer pour qu’ils soient pris en compte à la validation? La meilleure place serait comme un sous-ensemble directement dans votre document:

<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
[
  <!ATTLIST textarea maxlength CDATA #IMPLIED>
  <!ATTLIST textarea required (true|false) #IMPLIED>
  <!ATTLIST input required (true|false) #IMPLIED>
  <!ATTLIST select required (true|false) #IMPLIED>
]>

Si vous passez un tel fichier au travers de la validation du W3C, il va valider merveilleusement bien. Si vous téléchargez les fichiers d’exemple pour cet article et validez le fichier internal.html, vous pourrez le voir par vous-même. Malheureusement, quand vous affichez ce fichier dans votre navigateur, les caractères
]> vont apparaitre à l’écran. Il n’y a aucun moyen de contourner ce bug, on peut donc abandonner directement cette méthode.

Modifier la DTD

Une autre méthode consiste à obtenir la DTD de XHTML Transitional et d’ajouter les modifications directement dans ce fichier. La version originale de cette DTD est le fichier xhtml1-transitional.dtd dans le répertoire dtd des fichiers d’exemples accompagnant cet article. Vous y trouverez aussi 3 fichiers avec l’extension .ent. Ces fichiers définissent toutes les entités que vous utilisez en HTML, comme &rsquo; et &ntilde;. Vous devez garder tous ces fichiers ensemble dans le même dossier.

Le fichier personnalisé, nommé xhtml1-custom.dtd est créé en ajoutant les nouveaux attributs à la fin du fichier xhtml1-transitional.dtd. Quand vous ajoutez des attributs, faites-le à la fin du fichier pour vous assurer que tout ce à quoi vous faites référence a déjà été défini.

Changer le DOCTYPE

Vous devez maintenant changer l’insrtuction <!DOCTYPE > de votre fichier HTML pour indiquer l’utilisation de votre « version » personnalisé de XHTML. Comme la nouvelle DTD ne fait pas partie des DTD public enregistrée, le DOCTYPE n’utilisera pas le spécificateur PUBLIC. Il sera remplacer par le mot-clé SYSTEM suivi de l’emplacement de la DTD personnalisée. Ce chemin peut être relatif ou absolu, il peut même être une URL si votre fichier DTD est sur un autre serveur. Le chemin doit pointer vers l’emplacement exact de votre fichier ! Le fichier custom.html dans les exemples de cet article utilise le chemin relatif:

<!DOCTYPE html SYSTEM "dtd/xhtml1-custom.dtd">

Quand vous essayez d’utiliser le valideur du W3C sur ce fichier, il rejette le document parce qu’il n’utilise que les DTD qu’il connait et ne va pas chercher les DTD personnalisées.

Utiliser un valideur différent

La solution consiste à utiliser un valideur différent qui utilisera bien l’URL spécifiée pour vérifier la validité du document. Comme il s’agit d’un document XHTML, il est possible d’utiliser n’importe quel analyseur XML qui fait de la validation. Dans cet article nous allons utiliser l’analyseur Xerces disponible sur xml.apache.org. Cet analyseur est écrit en Java(tm), donc Java doit être installé sur votre système. La décompression de l’archive Xerces va créer un doccier xerces-2_6_2 (ou n’importe quelle autre version courante). Par la suite, nous supposerons que vous avez décompresser l’archive à la racine du disque C: sous Windows ou vers /usr/local sous Linux.

Le programme Counter fait partie des exemples fournis avec Xerces. Ce programme compte le nombre d’éléments, d’attributs, d’espace ignorables et de caractères apparaissants dans un document XML (ou dans notre cas XHTML). Ce programme permet d’activer une option de validation lors de l’analyse, le rendant parfait pour cette tache. Vous pouvez lancer le programme Counter (qui devient notre « valideur ») à partir d’un fichier batch dans Windows ou à partir d’un script shell dans Linux. Voici le fichier batch, nommé validate.bat. Il n’y a qu’une ligne de commande, mais nous l’afficherons sur plusieurs lignes pour que cela tienne sur la page.
Notez qu’il y a un espace avant le mot « dom » et après « -v ».

java -cp c:\xerces-2_6_2\xercesImpl.jar; »
c:\xerces-2_6_2\xmlParserAPIs.jar; »
c:\xerces-2_6_2\xercesSamples.jar dom/Counter -v »
%1 %2 %3 %4 %5 %6 %7 %8

Voici le script shell, nommé validate.sh.

java -cp /usr/local/xerces-2_6_2/xercesImpl.jar:\
/usr/local/xerces-2_6_2/xmlParserAPIs.jar:\
/usr/local/xerces-2_6_2/xercesSamples.jar \
dom/Counter -v $1 $2 $3 $4 $5 $6 $7 $8

Bien sur si vous avez décompressé l’archive de Xerces à un autre endroit, vous devrez changer les noms de chemin. Une fois ceci mis en place, il vous suffit de taper la commande suivante sous l’invite de commande Windows pour valider le fichier custom.html :

validate custom.html

Ou celle-ci sous l’invite de commande Linux:

./validate.sh custom.html

Si le fichier est valide, vous recevrez un message donnant le nom du fichier et quelques statistiques à son propos, comme ceci:

custom.html: 543;50;0 ms
  (15 elems, 20 attrs, 9 spaces, 43 chars)

Si le fichier n’est pas valide, vous obtiendrez des messages d’erreur. Par exemple, si vous essayer de valider un fichier badfile.html contenant ces erreurs:

<p>Email: <input type="text" name="email" size="40"
	required="yes" /></p>
<p>Comments:<br />
<textarea maxlength="300" inquirer="false"
   rows="7" cols="50"></textarea>

Vous obtiendrez cette sortie de l’analyseur:

[Error] badfile.html:12:70: Attribute "required"
  with value "yes" must have a value from the
  list "true false ".
[Error] badfile.html:14:63: Attribute "inquirer"
  must be declared for element type "textarea"
badfile.html:
  611;82;0 ms (15 elems, 20 attrs, 9 spaces, 43 chars)

Autre méthode de validation

Si vous utilisez l’éditeur jEdit, vous pouvez télécharger le plugin XML. Si votre fichier porte l’extension xhtml, jEdit utilisera la DTD personnalisée pour la validation comme spécifié dans le DOCTYPE.

Conclusion

Il est facile de spécifier des attributs supplémentaires pour des éléments XHTML; avec un peu de travail, vous pourrez mettre en place un valideur pour vérifier vos fichiers avec votre version personnalisée HTML. Télécharger tous les fichiers d’exemple de cet article et c’est parti!

À propos de l’auteur

J. David Eisenberg est programmeur et professeur habitant à San Jose, CA avec son chat, Marco Polo. La plupart de son travail porte sur XML, Java, JavaScript et Perl. Il est aussi l’auteur d’un livre sur le format d’images vectorielles SVG. Plus d’information sur catcode.com/narrative.html.