Je considère (peut-être à tort ?) que chaque identifiant d’une page peut être potentiellement une ancre. Aussi, je tâche :
- de choisir un nom explicite ;
- et de choisir un nom dans la même langue que mon contenu.
Ce qui donne par exemple : http://20cent.net/folio/#creations-graphiques 1
On retrouve alors un chemin d’adresse qui me semble tout à fait logique.
Par extension, j’ai toujours pris l’habitude de nommer mes classes de la même manière. Je me retrouve donc avec des .retablir, .liste, #contenu et autres .masquer quand je travaille sur des projets en français (95% du temps). 2
Évidemment pour un projet en anglais (ou multilingue) je change pour .clear, .hide, etc.
Dans la pratique ça n’a que peu d’inconvénients mais :
- il manque un mécanisme (comme il en existe pour les URI) pour réécrire à la volée ces identifiants en fonction de la langue ;
- et ça à le don d’énerver mes collègues !
Du coup, je suis peut-être sur une fausse piste ?
14 commentaires ↓
Moi je note tout en anglais, en partant du principe que c’est un pidgin tout à fait compréhensible même par un français-réticent-à-l’anglais (90% du parc utilisateurs dans une grosse boîte) 😉
J’ai le droit de répondre à côté dis ? dis ?
Parce que plutot que penser à la langue, ce qui me gêne plus c’est le « .masquer » ou « .clear » qui pour moi est du même ordre qu’un « .bleu » ou « .jaune »
A la limite je comprend les « .grande-colonne-grise-a-droite » parce que c’est franchement plus clair pour les développeurs. Mais un « .hide » c’est vraiment équivalent à un style= »display:hidden » (ou quelle que soit la technique utilisée pour le masquage).
C’est à une classe « .date » ou « .descriptif-annexe » d’avoir un style qui cache, pas à la classe de dire ce qu’elle fait.
Tout en anglais aussi, qu’il s’agisse des id, classes, fonctions javascript, commentaires, etc. Vu qu’on ne sais jamais où peux se retrouver notre code, autant utiliser une langue internationale.
Ce qui me gène vraiment dans ta méthode c’est que ta norme change suivant le projet. Si tu travail sur un projet français et qu’il devient par la suite multilingue, tu fais comment ? tu te retrouve avec tout en français alors que s’il avait été multilingue à la base tu aurais tout eu en anglais. Ça manque de cohérence si tu vois ce que je veux dire.
Pour les ancres, il s’agit selon moi d’un cas particulier car c’est non seulement un élément technique (que tu peux cibler avec les CSS/JS) mais aussi un élément visible par l’utilisateur (comme dans l’url de ton exemple). Je pense donc qu’il faudrait vraiment séparer les 2 : garder les id (pour CSS/JS) en anglais et les ancres traduites dans la langue du site.
Pour rebondir, je trouve quand même que
class="noprint"c’est souvent bien pratique.Mais dans l’absolu, je suis bien d’accord avec toi. © Vincent Valentin, 2008
😉
Héhé Éric, en effet un peu HS.
Pour ma défense, je parle là de classes génériques que j’utilise sur tous mes projets, j’en ai très peu, et elles sont bien pratiques quand même.
Mais dans l’absolu, je suis bien d’accord avec toi.
Un peu hors-sujet aussi puisque tu parles seulement des classes et des identifiants : HTML5 va fournir aux developpeurs de nouveaux éléments (header, footer, article, aside, etc.) qui sont des noms hérités de l’anglais. Les feuilles de styles seront donc truffées d’anglais. Comme dit Stéphane, ça reste compréhensible même pour un non-anglophone, ce sont souvent les mêmes termes qui reviennent. Idem d’ailleurs pour les frameworks CSS qui utilisent des noms en anglais me semble-t-il.
Maintenant sur un projet 100% francophone, je ne vois rien de mal à nommer une classe
.non-imprimableplutôt que.no-printà condition d’être sûr que le code sera toujours maintenu par une personne francophone. 😮@Eric : les noms de classes de Yahoo! Grids sont pas véritablement sémantiques non plus :p
Je le répète encore : tout en anglais ! Parce que nos collègues se trouvent aux 4 coins du globes, parce que tu ne peux pas prévoir qui va intervenir, et parce que les besoins et décisions du client évoluent jour pour jour…
Et puis je boycote « .clear » par la même occasion.
Je plussoie Yves parce que vraiment, tant que tu (Vincent) ne te seras pas mangé une CSS avec des noms allemands ou indiens tu maintiendras qu’il faut noter en français.
Ha ha, je suis diabolique. Il me vient soudain l’envie d’apprendre le sanskrit rien que pour t’embêter. Ha ha ha.
Mais dans l’absolu, je suis bien d’accord avec toi. © Vincent Valentin, 2008
Bien bien bien… je vois que la foule est contre moi ! 😀
Je m’en vais changer mes petites habitudes alors.
J’y pense, la gestion des ancres pourrait-elle se faire grâce à la réécriture d’url ?
Que veux-tu dire par la gestion des ancres grâce à la réécriture d’url ?
Les ancres restent au niveau du navigateur et ne sont jamais transmises au serveur, donc tu ne pourra rien réécrire à ce niveau.
Je suis partisant pour tout en anglais même pour une site francophone et entretenu que par des francophone. Et cela pour une raison simple :
En français on a des accents et autre caractère spéciaux que l’on zappe dans le nom de la class et on se retrouve souvent avec des mot incompréhensible ou qui vont demander un temps pour etre déchiffré !
Idem, je fais attention à la nomenclature des sélecteurs CSS, pour deux raisons : d’abord parce qu’ils peuvent être vus des internautes (tel l’id qui fait ancre), et ensuite parce qu’en bossant en équipe, je me dois d’être explicite.
Alors, a priori, tout en français. Si le projet est multilingue : dans la langue principale (si, y’en a toujours une), souvent le français, mais ça peut être italien ou japonais. Bin ouais. Enfin, si le client ou sa cible l’exige, ce sera en anglais, et sans broncher. Mais je fucke les english-lovers. Sincèrement.
Salut Vincent, faisons d’abord la différence entre ancre (<a>) et lien (<link>) donc oui la gestion des références hypertextes des ancres peut se faire par une « réécriture d’URL »(1) ce qui n’est pas le cas des fragments (#toto).
Et effectivement, au-delà de l’interprétation des identifiants par une équipe de développements (en anglais pour toute cette « cible »), tu penses également à l’internaute lambda qui n’a pas à se soucier de l’identification d’une partie de document. C’est la clé : comment identifier un bloc de contenu au sein d’une page ? En mettant en place une vraie URI donc oui en déployant un moyen d’accès compréhensible par son utilisateur donc dans sa langue ! Le fragment devrait donc je pense être localisé comme le reste de l’URL même si techniquement cela est plus lourd à gérer.
(1) Réécriture d’URL : expression signe d’une mauvaise gestion du nommage des documents par un CMS. A partir du moment où les URL sont gérées nativement pourquoi déployer ce patch ? :p
Vincent,
Pour te donner mon avis sur la partie nomage des classes, c’est simple : les propriétés et leurs valeurs sont en anglais, les mots sont séparés par des « - » et non des « _ ». J’applique la même chose pour mes nom d’ID et de classes. Le fait de travailler sur des sites anglophones et multilingues n’a fait que renforcer ce choix.
Laisser un commentaire