La raison d’être de notre communauté est de pouvoir partager des ressources localisées nous permettant d’utiliser DotNetNuke dans notre langue préférée : le français.
Régulièrement, une mise à jour apporte son « bug de localisation », celui qui fait que dans notre langue, et dans d’autres, la localisation impacte la mise en forme ce qui est susceptible de « casser » beaucoup de mise en pages.
Cette fois, le Core Team y va fort : je veux parler du module « AuthenticationServices ».
Son responsable a eu la très très très mauvaise idée de forcer le placement du formulaire dans un tableau de 160 pixels de large, ce qui n’est pas un drame en soit mais sans ce soucier le moins du monde d’une aberration que l’on croyait ne plus voir en 2007 : mettre un champ de saisi et un bouton l’un à côté de l’autre. Ceux qui ont passé du temps à créer des formulaires me comprendront. Il est déjà compliqué de faire cohabiter des intitulés, des champs de saisi et des boutons quand la langue ne bouge pas, mais quand elle change, et qu’on le sait, on doit en tenir compte, non ?
Dans le nouveau module d’authentification qui apparait avec la version 4.6 de DNN, le développeur a surement trouvé joli de mettre le champ de saisi du mot de passe sur la même ligne que le bouton « Login ». OK, no problem in english !
Mais dès que l’on traduit « Login » par « Connexion ». Paf le chien ! Notre bouton ne trouvant pas sa place dans les 160 pixels impartis va se placer gentiment à la ligne !
Il aurait été plus simple de fixer la largeur du champ de saisi du mot de passe à la même valeur que celle du nom d’utilisateur et mettre ce foutu bouton juste en dessous ! Non ?
Non. C’est comme ça et puis c’est tout.
La solution ? Modifier le fichier «DesktopModules\AuthenticationServices\DNN\Login.ascx » et changer la structure du tableau ou modifier la valeur cssclass liée au bouton et ajouter une valeur à sa feuille de style pour ne pas impacter TOUS LES BOUTONS DU SITE (cssclass= « StandardButton » par défaut).
Et bien moi, je dis non. Ce n’est pas une solution. Non pas qu’elle ne soit efficace (elle l’est), mais imaginez le problème lors des mises à jour, surtout si l’on touche au code !
Qu’on le veuille ou non, la langue fait partie intégrante du look. Il suffit de voir le temps que l’on passe pour faire en sorte que le positionnement des différents éléments sur le thème soit parfait, au pixel près !
La volonté affichée de faire de DNN une application localisable impose aux développeurs de tenir compte de cet impératif lors du codage, si ce n’est pour des problèmes d’accents, jusqu’à la place que prend un mot dans un formulaire !
Faisons un parallèle : WWStore
Gilles prend le plus grand soin à respecter le « best practice » en matière de développement, en fournissant un module « in english » natif, accompagné par son PDL (fr-FR par exemple) et la mise en page des différents formulaires prend en compte certains impératifs évidents de « place prise par les mots », et c’est normal.
Donc Messieurs du Core Team, n’oubliez pas la localisation dans vos développements et svp, corrigez-moi ce foutu module pour qu’il soit présentable, tout de moins en français.
David.
ps: si quelqu'un maitrisant la langue de Shakespeare a le courage de publier ce message ou de le retranscrire sur le forum US, ce serait vraiment sympatique...