Version française des modules et balises Topic is solved

[coroico]

Bonjour,
Existe-t'il un fichier de traduction en Français des modules et balises. Exemple : avoir la balise contact-form qui produise un formulaire avec des intitulés en Français et non en Anglais. Comment faut-il procéder pour traduire ces balises. D'avance Merci.

[PatDeLux]

Oui, cela m'intéresserait aussi, de même que de savoir ou on peut modifier le [More] dans les news pour qu'il devienne [Suite].

Idéalement cela devrait se trouver dans les paramètres globaux il me semble.

Patrick Honorez
www.idevlop.com

[philight]

Bonjour,

il y a une traduction dans 'Extensions/Modules/News' (cliquer sur 'aide' dans le panneau d'admin) avec les paramètres expliqués.

Par exemple, pour remplacer 'more' il faut indiquer moretext='Suite'.

Pour ce qui est des paramètres de contact-form, cette balise n'a pas l'air d'être très paramètrable... Par contre, tu peux télécharger un module supplémentaire comme par exemple FeedBackForm. Un aide partiellement traduite en français l'accompagne et permet d'en faire bon usage

A ++

[arnWald]

Bonjour,
Existe-t'il un fichier de traduction en Français des modules et balises. Exemple : avoir la balise contact-form qui produise un formulaire avec des intitulés en Français et non en Anglais. Comment faut-il procéder pour traduire ces balises. D'avance Merci.

Bonjour,

Pour les modules intégrés, à priori ils sont tous traduits. Pour les modules externes, cela dépend de l'état d'avancement du projet... mais tous "traduisibles" : avis aux amateurs.

Pour les tags (balises), à vue de nez (je ne les ai pas tous essayés) cela ne se pose que pour "contact_form" et "ImageGallery". La manière dont ces tags sont construits ne permet pas le multilinguisme.

Pour "contact_form", c'est un simple formulaire HTML, il suffit donc de modifier le fichier "\plugins\function.contact_form.php" (entre les lignes 91 et 111).

Par exemple, pour les étiquettes des champs (), remplacer :

Code: Select all

<label for="name" <?php echo ($style) ? $labelStyle:''; ?> >Your name :</label>

Par :

Code: Select all

<label for="name" <?php echo ($style) ? $labelStyle:''; ?> >Votre nom :</label>

On peut également modifier les boutons, exemple remplacer :

Code: Select all

<input type="submit" class="button" value="Submit" <?php echo ($style) ? $buttonStyle: ''; ?> />

Par :

Code: Select all

<input type="submit" class="button" value="Envoyer" <?php echo ($style) ? $buttonStyle: ''; ?> />

Ou bien encore modifier le "titre", remplacer :

Code: Select all

<legend>Contact</legend>

Par :

Code: Select all

<legend>Le texte que vous voulez !</legend>

On pourrait même pousser jusqu'à traduire les messages d'erreurs (ligne 58 à 77), exemple remplacer :

Code: Select all

if (empty($name)) $errors .= "\t\t<li>" . 'Please Enter Your Name' . "</li>\n";

Par :

Code: Select all

if (empty($name)) $errors .= "\t\t<li>" . 'Veuillez entrer votre nom' . "</li>\n";

Et si on ne veut pas modifier les fichiers "core" (notamment pour ne pas devoir refaire la manip à l'occasion d'une mise à jour de CMSMS), on peut trés bien récupérer le code, le modfier et en faire un tag utilisateur franco-français.

Personnellement c'est là le grand intérêt que je vois à CMSMS : c'est bien "balisé", mais complètement maléable !

Cordialement.

[coroico]

Merci à tous pour ces explications. Je vais regarder Feedback form voir s'il se prete à mes besoins (simple formulaire de contact) et si le changement de langue est aisé. Sinon je developperai ma propre balise en partant du code de contact_form.

J'ai quand même du mal à comprendre pourquoi le code n'est pas développé en utilisant une classe php type l10n (Localization) qui permettrait d'avoir des tables de traduction pour tous les labels.
Savez-vous si cela est prévu dans une prochaine version ? Où en tous les cas la possibilité de pouvoir traduire à la volée tous les labels. Cela ne serait pas luxueux.

[arnWald]

J'ai quand même du mal à comprendre pourquoi le code n'est pas développé en utilisant une classe php type l10n (Localization) qui permettrait d'avoir des tables de traduction pour tous les labels.
Savez-vous si cela est prévu dans une prochaine version ? Où en tous les cas la possibilité de pouvoir traduire à la volée tous les labels. Cela ne serait pas luxueux.

Autant c'est indispensable pour les modules, autant pour les tags... on peut se poser la question. Surtout que là on parle d'un formulaire basique dont il existe des quantités d'exemples fonctionnels sur le net. On pourrait même se contenter de quelques lignes d'HTML dans un bloc de contenu global.

Il me semble que les tags intégrés sont plutôt à prendre comme des exemples de ce qu'il est possible de réaliser très simplement.

Après on peut toujours mieux, mais cela fini par alourdir. Même si l'espace disque n'est pas un problème en soi, c'est assez représentatif de l'évolution d'un script. CMSMS pèse aujourd'hui près de 8Mo, de base. C'est-à-dire un bon tiers de plus qu'un Joomla (qui est déjà assez touffu en terme de fonctionnalités). Donc oui le code commence à être assez lourd. Il me semble d'ailleurs que c'est un des soucis des développeurs qui annoncent le recours au mapping objet pour la version 1.1. Ce qui laisse présager d'une sérieuse cure d'amaigrissement.

La philosophie de base de CMSMS était simple, léger et facile à mettre en oeuvre. Ce qui ne l'empêche pas d'être complétement adaptable. Il me semble que c'est un positionnement qui se défend. Surtout quand on voit que d'autres produits, pourtant excellent au départ, sont finnalement devenus de "véritables usines à gaz".

Mais ce n'est là qu'un avis personnel.

Cordialement.

[coroico]

Ok, je comprends mieux. Comme je commence à prendre le produit en main, je galère un peu et j'ai un peu de mal à comprendre la philosophie du produit (module, tags, user tags). Simple, léger et facile à mettre en oeuvre. Léger, ce n'est effectivement plus le cas (8.5 Mo à comparer à Modx 5.4 Mo). Simple et facile à mettre en oeuvre. Oui. J'ai quand même réussi à faire rapidement 2/3 pages avec le design ad hoc

[arnWald]

Ok, je comprends mieux. Comme je commence à prendre le produit en main, je galère un peu et j'ai un peu de mal à comprendre la philosophie du produit (module, tags, user tags).

Ce n'est pas vrai pour tous (exemple CMSMailer n'est en fait qu'une interface pour faciliter l'utilisation de la classe tiers PHP Mailer), mais je pense qu'il faut voir le "module" comme une extension des fonctionnalités de l'application. C'est en général un ensemble de fichiers qui viennent greffer tout un tas de choses, que ce soit dans la partie publique ou admin (avec ajout de menus dédiés) ou dans la BdD (avec l'ajout d'une ou plusieurs tables)... Pour développer un module, qui va venir se "hooker" à de multiples endroits, il faut donc maîtriser assez sérieusement l'architecture de l'application de base et le language utilisé (en l'occurence PHP).

Pour ce qui est des "tags", c'est tout à fait autre chose. Ce ne sont que de petits morceaux de code pour rajouter une fonction simple sur une ou plusieurs pages (dans la partie publique donc) : par exemple, afficher le contenu d'une variable, la reformater... Cela permet simplement de ne pas alourdir le gabarit (qui doit rester un "canevas"). Ensuite, les "tags" (tout court) sont déjà intégrés dans CMSMS (ce sont les fichiers du dossier /plugins/) alors que le "tag utilisateur" est écrit... ben par l'utilisateur et stocké dans la BdD (dans la table "userplugins", si j'ai bien tout suivi). Mais les 2 fonctionnent exactement de la même manière.

Bon ensuite pour ce qui est du "vocabulaire" chaque CMS a le sien... et c'est pas toujours aussi accessible !

Simple, léger et facile à mettre en oeuvre. Léger, ce n'est effectivement plus le cas (8.5 Mo à comparer à Modx 5.4 Mo).

Justement c'est ce que je dis : "on rajoute, on rajoute... et cela enfle" ! C'est souvent le cas avant qu'un produit atteigne sa "pleine maturité" et c'est normal. A un moment (et même régulièrement), il faut réorganiser le code, et c'est ce qui va être fait visiblement. Bon ensuite, dans les près de 8Mo (ne comptez pas le cache), il y a déjà presque 2Mo pour FCKeditorX...

Simple et facile à mettre en oeuvre. Oui. J'ai quand même réussi à faire rapidement 2/3 pages avec le design ad hoc

Oui quand même et, vu que vous parlez de ModX (par ailleurs excellent dans son genre), au niveau facilité d'utilisation il n'y a pas photo !

Pour ma part, il y a deux aspects qui me paraissent excellent chez CMSMS :
- l'installation des modules via XML, c'est puisssant et facile, on teste à volonté ;
- la gestion des templates (merci Smarty).

D'ailleurs je ne sais pas si vous avez vu la vidéo flash qui illustre ce dernier point, mais c'est éloquent :
http://cmsmadesimple.org/uploads/media/ ... colate.htm

Cordialement.

[Pierre M.]

Information à 2 centimes sur la version française d'une minuscule partie du "core" :

Il y a quelques temps, les liens "page suivante, page précédante etc" étaient disponibles en Anglais et dans une langue scandinave, je crois. C'était plus ou moins codé en dur dans selflink.php ou quelque chose comme cela. Et dans les gabarits, on choisit la langue avec lang="en".

J'ai regardé le truc.php, j'ai recopié un "case", j'ai remplacé par "fr", j'ai soumis ce "patch" minuscule de 4 lignes via le forum et il a depuis été intégré. Ainsi, on écrit facilement dans le gabarit lang="fr" plutôt que d'utiliser un hack du genre alternatetext="Page cecicela".

Ca paraît standard, mais je ne crois pas que ce soit la voie de l'avenir, où code et textes seront vraiment séparés.

PM

[arnWald]

Ca paraît standard, mais je ne crois pas que ce soit la voie de l'avenir, où code et textes seront vraiment séparés.

200% d'accord. D'ailleurs ce n'est pas la méthode choisie pour les modules fort heureusement. C'est pourquoi pour les tags, il me semble plus judicieux de les considérer comme de simples exemples. A chacun de les adapter, localiser, bidouiller selon ses besoins, capacités...

Le fichier que vous citez "function.cms_selflink.php" est un contre exemple. Déjà, avec 550 lignes de codes... est-ce encore dans la philosophie du tag ? En plus de l'aspect séparation code/texte, la méthode du "switcth" rajoutée au nombre de "if" que comprend ce fichier n'est pas vraiment ce qu'il y a de plus optimum !

Et tiens puisque l'on en parle, hier j'ai trouvé un bug avec l'option "target" et avec "urlparams". Pour cette dernière option, même si je n'ai pas encore bien saisi à quoi elle servait, en l'état actuel du code, elle ne peut pas fonctionner. J'ai corrigé et préparé un fichier diff, mais je n'ai pas encore eu le temps de le faire remonter. J'imagine que cela doit être possible via la Forge (pas encore essayé) ?

Cordialement.

[Pierre M.]

J'ai corrigé et préparé un fichier diff, mais je n'ai pas encore eu le temps de le faire remonter. J'imagine que cela doit être possible via la Forge (pas encore essayé) ?

Oui, je pense que la forge facilite le travail des dévs : vous y enregistrez un bug, vous y proposez un diff, ils en font la revue et l'incorporent en traçant tout cela.
PM

[arnWald]

Par exemple, pour remplacer 'more' il faut indiquer moretext='Suite'.

En fait, pour çà il suffit de déclarer le français comme "Langue par défaut de la partie publique du site" dans "Administration du site >> Paramètres globaux". La traduction est déjà implémentée.

Par contre pour les étiquettes "catégorie" et "auteur", cela ne semble pas fonctionner alors que c'est présent dans le fichier de langue du module.

Cordialement.

[Pierre M.]

Certes, il y a encore des trucs en dur dans le code. D'où l'importance de signaler les bugs dans la forge.
PM