[plugin] MyMultiLingue

135678

Réponses

  • PPmarcel a écrit:
    [list=*]
    [*]si on active le plugin betterurl, puis multi-langue, alors tout marche comme prévu.[/*]
    [/list]
    En l'état actuel (sans correction ou sans avertissement), certains risquent de penser que les deux plugins ne marchent pas ensemble.
    je confirme avec 5.3. je me souviens plus exactement dans quel ordre ça ne marchait pas, mais en désactivant et réactivant dans l'ordre indiqué, ça (re)fonctionne
  • en fait, c'est pas si simple:

    ordre des plugins: multiLingue + myBetterUrls
    url bien formées (/(fr|en)/...) pour pages, catégories, article, sitemap mais tout est inaccessibles (404)

    ordre des plugins: myBetterUrls + multiLingue
    url bien formées pour les pages, mais pages inaccessibles (404)
    url malformées (pas d'indication de langues) pour catégories, article, page plugin contact & search, sitemap mais pages accessibles

    je vais abandonner multiLingue pour l'instant, en espérant un prochain fonctionnement correct avec myBetterUrls
  • DudyDudy Member
    avril 2014 modifié
    Certains éléments vont chercher leur traduction dans core/lang/xx/core.php, et ils restent dans la langue par défaut du CMS :

    les dates (archList() dans sidebar.php et artDate() dans articles.php et home.php)

    le compteur de commentaires (artNbCom() dans article.php et sidebar.php)

    les flux RSS des commentaires (comFeed() dans commentaires.php)

    Bonjour, moi aussi j'ai abandonné ce plugin, c'est dommage parce-que c'est quelque chose en plus pour Pluxml
    j'avais dejà posé cette question ici sans trop de retour, (+1 jerry)et j'ai abbandonné
    j'ai toute essayé, par exemple ICI j'ai une version juste avec le plugin multilingue et le problème et toujours là
    dommage!!!
  • Bonjour,
    Ayant mis en place le plugin, qui fonctionne correctement j'ai du cependant faire quelques modifications cosmétiques, pour les raisons qui suivent :
    [== PHP ==]
    public function MyMultiLingue() {
    
    		if($this->aLangs) {
    			echo '<div id="langs">';
    			echo '<ul>';
    			foreach($this->aLangs as $idx=>$lang) {
    				$sel = $this->lang==$lang ? ' active':'';
    				echo '<li><?php echo "<a class=\"lang'.$sel.'\" href=\"".$plxShow->plxMotor->urlRewrite("?lang='.$lang.'")."\"><img class=\"lang'.$sel.'\" src=\"'.PLX_PLUGINS.'plxMyMultiLingue/img/'.$lang.'.jpg\" alt=\"'.$lang.'\" style=\"width:25px\" /></a></li>"; ?>';
    			}
    			echo '</ul>';
    			echo '</div>';
    		}
    	}
    

    Par :
    [== PHP ==]
    public function MyMultiLingue() {
    
    		if($this->aLangs) {
    			echo '<div id="langs">';
    			foreach($this->aLangs as $idx=>$lang) {
    				$sel = $this->lang==$lang ? ' active':'';
    				echo '<?php echo "<a class=\"lang'.$sel.'\" href=\"".$plxShow->plxMotor->urlRewrite("?lang='.$lang.'")."\"><img class=\"lang'.$sel.'\" src=\"'.PLX_PLUGINS.'plxMyMultiLingue/img/'.$lang.'.jpg\" alt=\"'.$lang.'\" style=\"width:25px\" /></a>"; ?>';
    			}
    			echo '</div>';
    		}
    	}	
    

    L'ajout de balise dans directement dans le code, gène pour l'affichage par rapport au thème. Il faut que ce soit le thème qui gère l'affichage et non pas le plugin, de façon à rendre l'ensemble cohérent.
    [== PHP ==]
    public function plxShowStaticListEnd() {
    		echo '<?php
    		foreach($menus as $idx => $menu) {
    			if(strpos($menu, "static-home")!==false) {
    				if($this->plxMotor->aConf["urlrewriting"])
    					$menus[$idx] = str_replace($this->plxMotor->racine, $this->plxMotor->racine."'.$this->lang.'/", $menu);
    				else
    					$menus[$idx] = str_replace($this->plxMotor->racine, $this->plxMotor->racine."index.php?'.$this->lang.'/", $menu);
    			}
    		}
    		?>';
    	}
    

    Par :
    [== PHP ==]
    	public function plxShowStaticListEnd() {
    		echo '<?php
    		foreach($menus as $idx => $menu) {
    			if(strpos($menu, "static-home")!==false) {
    				if($this->plxMotor->aConf["urlrewriting"])
    				{
    					$menu = str_replace("index.php?", "", $menu);
    					$menus[$idx] = str_replace($this->plxMotor->racine, $this->plxMotor->racine."'.$this->lang.'/", $menu);
    				} else {
    					$menu = str_replace("index.php?", "", $menu);
    					$menus[$idx] = str_replace($this->plxMotor->racine, $this->plxMotor->racine."index.php?'.$this->lang.'/", $menu);
    				}
    			}
    		}
    		?>';
    	}
    
    

    L'ajout d'une fonctionnalité ajoutant un menu dans le thème, pose problème avec le re-routage des entrées des pages static en fonction de la langue. Pour cela il faut avant toute modification des url retirer la chaîne "index.php?".

    Il serait intéressant d'avoir une fonctionnalité permettent de générer l'url correcte à la volée dans les pages pour les liens interne. Ainsi pour un lien en fonction de la langue, je vais avoir une url qui sera différente du fait du fonctionnement du CMS et du plugin.
    Exemple :

    en français : index.php?article10/produits

    en anglais : index.php?article10/products

    Il faudrait également être capable de gérer la différence de numérotation d'articles ou de pages static.

    Si quelqu'un à des idées, je suis preneur.
  • avril 2014 modifié
    @Libaud : tu m'intéresses ! ;)
    J'essaye de faire fonctionner et j'ai quelques problèmes.

    Cependant je n'ai pas bien compris tes deux problèmes ci-dessus.
    Pour le premier, c'est pour l'affichage des drapeaux ? Afficher des drapeaux pour choisir une langue est une fausse bonne idée (cf. le deuxième chapitre du post sur le bug de changement de la configuration de base).

    Pour le deuxième problème, si c'est l'URL donné dans le menu pour les pages statiques, je l'avais signalé dans un autre post. Cependant, comme indiqué dans ce post si tu actives la réécriture d'url, cela fonctionne.

    Par contre, personnellement j'ai trois problèmes :
    - le changement de la configuration de base ne se fait pas pour chaque langue. Il est unique pour toutes les langues.
    - les commandes recherche et contact (qui correspondent aux plugins associés) du menu ajouté aux pages statiques, ne fonctionnent plus (comme indiqué dans ce post)
    - le plugin CKeditor ne fonctionne plus pour les pages statiques (comme indiqué dans ce post)

    Et pour toi, ça fonctionne ?
  • StéphaneStéphane Member, Former PluXml Project Manager
    @ComputingFroggy: peux-tu tester stp ces versions des plugins MyContact et MySearch.

    https://github.com/Pluxopolis/plxMyContact/archive/master.zip
    https://github.com/Pluxopolis/plxMySearch/archive/master.zip

    Ce sont des versions que je n'ai pas publié officiellement mais qui comportent des evols
    Merci

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • C'est pas top !

    La commande contact ne s'affiche pas dans le menu mais par contre, toutes les commandes du menu horizontal font afficher la page contact (au lieu de la page qu'ils devraient afficher).
    A voir sur mon site de test

    Aussi, les affichages dans la partie admin ne sont pas corrects (pour les 2 plugin Search et Contact) les zones pour les 2 langues sont affichées : il faut peut-être ajouté un fichier CSS que je n'ai pas ?
  • StéphaneStéphane Member, Former PluXml Project Manager
    Est-ce que tu peux stp me faire un .zip de ton site de test et me le mailer pour que je regarde ce qui ne va pas. Merci

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • @ComputingFroggy,

    Pour la ré-écriture d'URL c'est noté, je vais vérifier le fonctionnement.

    Par contre le 1er point, il s'agit de laisser le formatage HTML (pose des balises UL et LI) au thème et non pas au plugin ! Car, ce n'est pas au plugin, à mon sens, de réaliser le formatage. Perso, je souhaite que les drapeux soit dans une cellule de tableau à minima et à l'horizontal. Le thème avec la feuille de style sont là pour gérer ça.

    Pour les problèmes que tu rencontre il s'agit probablement de dysfonctionnement lié à la mise en place du plugin. Personnellement, je travaille toujours sur un environnement de développement, j'en ai un autre pour tester et enfin une copie de l'environnement de production. Question de pratiques.
    La configuration de base n'a pas pour moi à être spécifique en fonction de la langue, par contre c'est vrai que tout les éléments de type méta devrais pouvoir être traduit mais, le CMS n'est pas prévu pour fonctionner comme ça, pour ce que j'en sais. Je n'utilise pas le plugin contact, probablement qu'il n'est pas compatible avec le plugin multilangue, car chacun fonctionne de façon indépendante. Je n'utilise pas CKeditor mais, les plugins fonctionnent bien globalement.
    ComputingFroggy a écrit:
    @Libaud : tu m'intéresses ! ;)
    J'essaye de faire fonctionner et j'ai quelques problèmes.

    Cependant je n'ai pas bien compris tes deux problèmes ci-dessus.
    Pour le premier, c'est pour l'affichage des drapeaux ? Afficher des drapeaux pour choisir une langue est une fausse bonne idée (cf. le deuxième chapitre du post sur le bug de changement de la configuration de base).

    Pour le deuxième problème, si c'est l'URL donné dans le menu pour les pages statiques, je l'avais signalé dans un autre post. Cependant, comme indiqué dans ce post si tu actives la réécriture d'url, cela fonctionne.

    Par contre, personnellement j'ai trois problèmes :
    - le changement de la configuration de base ne se fait pas pour chaque langue. Il est unique pour toutes les langues.
    - les commandes recherche et contact (qui correspondent aux plugins associés) du menu ajouté aux pages statiques, ne fonctionnent plus (comme indiqué dans ce post)
    - le plugin CKeditor ne fonctionne plus pour les pages statiques (comme indiqué dans ce post)

    Et pour toi, ça fonctionne ?
  • Bonjour,

    Dans le plugin plxMyMultilingue, les images des drapeaux sont au format jpeg.

    Afin de disposer d'une bonne optimisation, il serait intéressant que les images soient au format png et optimisés avec advpng (http://advancemame.sourceforge.net/doc-advpng.html) par exemple.
  • Pour information, Stéphane travaille en ce moment sur des améliorations sur le plugin MultiLingue ... et je lui fait des retours (tests et utilisation).
    Je suppose qu'il y aura bientôt une nouvelle version dès que nous aurons fait le tour de tous les petits soucis ... mais ça s'améliore rapidement.
  • très très bonne nouvelle
  • StéphaneStéphane Member, Former PluXml Project Manager
    version 0.5 (30/04/2014)
    [+] Choix affichage drapeaux ou libellés
    [+] Gestion du titre, de la description, des metas description et keywords du site en fonction de la langue
    [+] Bascule sur l'article, catégorie ou page statique avec le même identifiant lors du changement de langue.
    [+] Traductions du plugin: de, es, it, nl, pl, pt, po, ru
    [+] Conversion des images des drapeaux au format png (taille globale des fichiers réduites de 161Ko à 8.5Ko)
    BUG Mauvais liens des pages statiques

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Pour information, ça fonctionne bien ! !
    Vous pouvez voir un exemple avec mon blog d'informatique.

    Attention :
    1/ à bien mettre à jour, tous les plugins. Les dernières versions sont nécessaires pour prendre en compte la fonction multi-langue.
    2/ à ne pas jongler entre les différentes langues, avec plusieurs fenêtres et/ou onglets : ça ne fonctionnera pas ! ! La langue "courante" est associée à la session utilisateur.

    Je vais l'utiliser pour un autre blog et un mini site : je vous tiendrai au courant.
  • StéphaneStéphane Member, Former PluXml Project Manager
    @ComputingFroggy: Merci pour le retour d'expérience

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Ca fonctionne pour l'utilisateur mais ... il y a un petit bug et il faudrait faire plaisir à Google et aux autres moteurs de recherche.

    Le buguillon : dans l'écran d'admin Paramètres => Configuration de base, les zones de texte changent quand on change de langue MAIS les listes déroulantes sont toujours identiques. D'un point de vue interface utilisateur, c'est déroutant, cette différence de comportement. D'un point de vue, logique de fonctionnement, il est évident qu'on ne veut pas changer le fuseau horaire (quoique mais bon, on ne va pas s’embêter avec ça) et la gestion des commentaires selon la langue. Il faudrait donc séparer les deux parties pour que l'utilisateur se rende compte qu'une partie change avec la langue choisie et une autre non.
    Il reste le problème de la propriété lang du tag html : pour le moment, il est fixé par la valeur de la liste déroulante langue par défaut du site. Mais quand on affiche les pages dans plusieurs langues, cette propriété devrait changer pour chaque langue différente.

    Enfin, il faudrait ajouter une balise pour hreflang dans l'en-tête des pages pour indiquer la page correspondante dans une autre langue et bien sur également sur le lien/drapeau pour changer de langue.
    Ca serait un plus, mais ça peut attendre.

    Le problème de la gestion de la langue dans le tag html est plus gênant !
  • StéphaneStéphane Member, Former PluXml Project Manager
    @ComputingFroggy: je ne suis pas sur de bien comprendre le probleme du tag html dont tu parles

    Est-ce que ça ne serait pas lié à ton thème. Si tu as cette ligne dans ton header.php, c'est géré
    <html lang="<?php $plxShow->defaultLang() ?>">
    

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • StéphaneStéphane Member, Former PluXml Project Manager
    @ComputingFroggy: Pour l'écran d'admin Paramètres => Configuration de base, les valeurs des déroulants n'ont pas à changer en fonction de la langue. La langue par défaut est unique. Le fuseau horaire est à régler en fonction de celui de l'hébergeur. Les anglais d'australie et d'angleterre ne sont pas sur le même fuseau et pourtant l'anglais est utilisé pour ces 2 pays.

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • @Stephane
    - le bug : c'est moi ! Effectivement, j'aurai du regarder header.php. C'était codé en dur
    <html lang="fr">
    en le remplaçant par
    <html lang="<?php $plxShow->defaultLang() ?>">
    tout roule

    - le problème d'affichage des paramètres.
    On est d'accord, les valeurs des listes déroulantes ne doivent pas changer en fonction de la langue. Cependant le fait qu'elles soit situées sur la même page que les informations textuelles qui, elles, changent en fonction de la langue n'est pas une bonne chose pour l'expérience utilisateur. Il faudrait indiquer que les zones de saisies textuelles sont les seules qui réagissent au changement de langue : c'est plus clair pour l'utilisateur. Par exemple, on pourrait ajouter un cadre qui regrouperait les zones de saisies textuelles et les drapeaux/labels de changement de langue. Ca améliorerait l'UX.
  • J'ai créée une pull request sur github avec les modifications suivantes :
    Modification de l'affichage des libellés pour afficher soit une seul langue dans le cas de deux langues soit une liste déroulante avec une icône de changement de langue.
    J'ai du intégrer, dans le plugin, une nouvelle version de printSelect pour ajouter un nouveau paramètre "onchange". Peut-être sera t'elle intégrer dans une prochaine version du core.

    Peut-être que Stéphane intégrera ces changements dans le plugin officiel, sinon, si ça vous intéresse, vous pouvez récupérer cette version sur github.
  • Encore deux remarques sur ce plugin :
    - la valeur du champ informations de chaque Profil ne change pas avec le changement de langue : il est invariable quelque soit la langue. Impossible donc d'afficher un message dans chaque langue en utilisant $plxShow->artAuthorInfos() !

    - si jamais on a travaillé dans la partie admin dans une langue (disons anglais) et qu'on a un autre onglet avec les pages du site (partie visiteurs) dans une autre langue (disons Français) et qu'on visualise d'autres pages du site : on se retrouve avec des pages moitié dans une langue et moitié dans une autre, pour les langues données précédemmment, on aura tous les libellés en anglais mais le contenu (e.g. les articles) en Français. Il suffit de changer de langue pour tout rentre dans l'ordre !
    J'avais déjà indiqué qu'il fallait ne pas changer de langue entre différents onglets ouverts sur le site : plxMyMultiLingue n'aime pas ça.
  • Top bon cela fait un moment que j'avais laissé tombé pluxml pour le multilingue...la je vais tester ca !!
    MErci
  • TomekTomek Member
    J'ai une requête côté utilisabilité de l'admin : le fait de faire un site multilingue ne signifie pas qu'on maîtrise lesdites langues ; or, quand on bascule d'une langue à l'autre pour intégrer le contenu, toute l'interface bascule dans la langue en cours d'édition, ce qui en rend l'utilisation quelque peu… aléatoire. Il y a bien un paramètre dans le profil utilisateur pour ça, mais il est "écrasé" par le plugin multilingue.
  • NaBiSsNaBiSs Member
    mars 2015 modifié
    J'ai identifié un bug avec le plxMyMultiLingue. À chaque fois que j'ajoute une image par une interface WYSIWYG (CKEDITOR, PlxEditor), le chemin vers l'image est correct. Par contre à chaque fois que je vais enregistrer par la suite, le chemin va incrémenter un /fr/. Par exemple

    Premier enregistrement : /racine/data/images/fr/articles/image.jpg
    Deuxième enregistrement : /racine/data/images/fr/fr/articles/image.jpg
    Troisième enregistrement : /racine/data/images/fr/fr/fr/articles/image.jpg

    De ce fait, bien évidement les images ne s'affichent plus.

    J'ai l'impression que cela vient de ce plugin, puisque ce type de sous-répertoire est crée par lui.

    EDIT : Ce n'est pas un bug, j'ai eu la mauvaise idée de créer un répertoire "articles" pour mes images. Le plugin réécrit à la volée les url des articles. Il faut donc éviter la présence de ce mot dans l'URL ;) .
  • TomekTomek Member
    Un petit retour d'expérience à l'usage de ce plugin : il fait bien le job, mais outre le point évoqué plus haut (http://forum.pluxml.org/viewtopic.php?pid=42194#p42194), le fait de vérifier / éditer des pages en changeant de langue dans l'administration met le bazar sur les pages publiques en affichant par exemple le contenu en anglais sur les pages de la version française. Je pense logiquement que ça ne devrait pas poser de souci en usage quotidien, pour peu qu'on n'édite pas le site sous ses différentes langues tous les jours.
  • TomekTomek Member
    Ah, je viens de remarquer autre chose : le lien vers l'accueil dans le menu à la même url quelle que soit la langue utilisée...
  • TomekTomek Member
    En fait, ce dernier point pose visiblement problème, le site s'affiche dans les différentes langues de manière + ou - aléatoire quand on est / retourne sur la home. Y a-t'il moyen de faire en sorte que la home soit réellement différente pour chaque langue ?
  • ScithScith Member
    Bonjour et merci pour ce plugin.
    Soucis chez moi également avec la page d'accueil. J'ai une page statique définie comme page d'accueil (en cochant la case). Mais je ne peux pas cocher la case à la fois dans la version FR et la version EN. Du coup la page d'accueil est soit la statique anglaise, soit la statique française mais pas les deux. Le soucis qui en résulte est que mon blog n'apparaît dans le menu que dans la langue pour laquelle la statique est en accueil ...
  • StéphaneStéphane Member, Former PluXml Project Manager
    Ok, c'est noté, je regarde ça dès que je peux. Merci

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • ScithScith Member
    Merci :) Autre question svp : est-il possible de récupérer l'URL de la page traduite dans une autre langue depuis un hook ou un bout de code ? J'aimerais rajouter dans mon header des balises
    [== HTML ==]
    <link rel=”alternate” hreflang=”en” href=”http://monsite.com/en/” />
    
    J'ai cru lire que ça pouvait avoir un impact sur le référencement. Pas sûr que ça serve à quelque chose, mais s'il y a possibilité simplement pourquoi pas ...
    Merci
Connectez-vous ou Inscrivez-vous pour répondre.