les articles sont gérés indépendamment donc tu peux avoir des id différents pour 2 articles, meme si l'un n'est que la traduction de l'autre. ce n'est qu'une histoire d'organisation au niveau de la rédaction.
le seul point qui peut etre bloquant pour le moment ce sont les metas du site (description, keywords).
le plugin peut gérer ça très facilement. à mettre sur la todo du plugin
C'est bien entendu sur les metas du site que je veux parler, mais aussi sur le nom du site, le slogan, le sitemap.
Tout ce qui concerne l'identité du site en sommes que les moteurs ce servent pour nous placer.
Dans cette logique pourquoi serait-ce plus compliquer de gérer plusieurs pluxml ayant leur propre langue et géré tout simplement via des sous domaine (fr.exemple.com, en.exemple.com) que par un plugins qu'il faudra être sur de mettre à jour tout les articles,pages,config et inc ?
@zakar! : ah ok les métas du site. effectivement ...
en effet les id ne sont pas communs puisqu'on qu'on peut créer les articles des différentes versions dans l'ordre que l'on souhaite. Donc pas possible de pouvoir changer de langue tout en restant sur le même article ... mince
il me faut donc obligatoirement rajouter un champ de liaison avec l'article de référence pour gérer les images et touti quanti
ça aurait été bien un paramètre supplémentaire dans l'URL et une règle pour avoir /fr/article1/titre ou /en/article1/title
public $aLangs = array('fr', 'en'); # tableau des langues dispos
par
$aLangs = ($this->aParams['flag']['value'] AND $this->aParams['flag']['value']!="") ? explode(",",$this->aParams['flag']['value']) : ""; // récupération des langues sélectionnées dans le panneau de configuration
public $aLangs = array('fr', 'en'); # tableau des langues dispos
par
$aLangs = ($this->aParams['flag']['value'] AND $this->aParams['flag']['value']!="") ? explode(",",$this->aParams['flag']['value']) : ""; // récupération des langues sélectionnées dans le panneau de configuration
Fait tes inits dans le constructeur de la classe en faisant référence à $this->aLangs
Dans cette logique pourquoi serait-ce plus compliquer de gérer plusieurs pluxml ayant leur propre langue et géré tout simplement via des sous domaine (fr.exemple.com, en.exemple.com) que par un plugins qu'il faudra être sur de mettre à jour tout les articles,pages,config et inc ?
Qu'est-ce qui est plus simple en cas d'update: mettre à jour un pluxml et/ou un plugin ou tous les pluxmls ayant leur propre langue (sans parler des mises à jour des éventuels autres plugins utilisés qu'il faudra redescendre sur tous les sites)...
Perso je choisis la solution 1 car plus facile à gérer.
Sinon je suis d'accord, se pose le probleme du référencement avec les metas dans une langue différente pour la meme url du site
Qu'est-ce qui est plus simple en cas d'update: mettre à jour un pluxml et/ou un plugin ou tous les pluxmls ayant leur propre langue (sans parler des mises à jour des éventuels autres plugins utilisés qu'il faudra redescendre sur tous les sites)...
Perso je choisis la solution 1 car plus facile à gérer.
Sinon je suis d'accord, se pose le probleme du référencement avec les metas dans une langue différente pour la meme url du site
Et bien tu vois pour moi il sera plus simple de mettre à jour pluxml si tout les plugins étais sur Github comme pluxml, une simple ligne en ssh suffis pour mettre a jour tout mes pluxml si en plus il ont leur propre sous-domaine
Je le redis un site est unique aux yeux des moteurs de recherche, les plus gros site ce sont creuser eux aussi la tête pour ça et le plus simple pour eux et de dupliquer leur site pour vraiment avoir une identification différente suivant la langue et évite ainsi le duplicate content.
Sans oublier toutes les nouvelles règle pour 2013 des moteurs de recherches. Tenir un site et un boulot que seul ou une équipe peux mettre en place pour avoir de bon résultat en Seo car ce n'est pas une science exacte.
Dans ce cas faudra voir le plugin final, mais pour moi trop de paramètres rentre en compte pour tenter l'expérience via plugin.
Je ne fait que partager mes connaissances dans ce domaine et bien d'autres personnes on tenté ce genre d'approche, s'il étais si facile ont aurai je pense pleins de réponse via une simple recherche.
Qu'est-ce qui est plus simple en cas d'update: mettre à jour un pluxml et/ou un plugin ou tous les pluxmls ayant leur propre langue (sans parler des mises à jour des éventuels autres plugins utilisés qu'il faudra redescendre sur tous les sites)...
Perso je choisis la solution 1 car plus facile à gérer.
Sinon je suis d'accord, se pose le probleme du référencement avec les metas dans une langue différente pour la meme url du site
Et bien tu vois pour moi il sera plus simple de mettre à jour pluxml si tout les plugins étais sur Github comme pluxml, une simple ligne en ssh suffis pour mettre a jour tout mes pluxml si en plus il ont leur propre sous-domaine
Je le redis un site est unique aux yeux des moteurs de recherche, les plus gros site ce sont creuser eux aussi la tête pour ça et le plus simple pour eux et de dupliquer leur site pour vraiment avoir une identification différente suivant la langue et évite ainsi le duplicate content.
Sans oublier toutes les nouvelles règle pour 2013 des moteurs de recherches. Tenir un site et un boulot que seul ou une équipe peux mettre en place pour avoir de bon résultat en Seo car ce n'est pas une science exacte.
Tu m'as convaincu. Effectivement, après reflexion je partage tes arguments
bon ben on fait quoi alors ?
on oublie ce plugin et on décrit une méthode dans le Wiki pour gérer un site multi-langues ?
Ci tu en ressent la force de résoudre tout ces points méthodiquement parlant, je t'encourage à finaliser le plugin, après tout il suffit d'avoir l'idée / les idées que personne n'as pensée pour ce faire connaitre
Dans les problématique il faut aussi tenir compte du charset qui diffère de la langue et de la localision géographique.
bon ben on fait quoi alors ?
on oublie ce plugin et on décrit une méthode dans le Wiki pour gérer un site multi-langues ?
1 -surtout pas 'oublier' !!! ça (te) servira quand même certainement et à bien d'autres ensuite
2 - une telle méthode dans le wiki, non, surtout pas !!!
3 - et pourquoi ne pas pousser plus loin ???
- - 1 site en 2 ou 3 langues utilisant le plugin
- - 2 ou 3 sites dans les mêmes langues, sans utilsation de plugin
... bon des sites de 'test' certes, mais sérieux quand même, sur, par exmple le sujet des "sites multilingues" ... et qui resteraient en ligne au moins un an ... là au moins l'expérience serait tentée, les résultats eux seront vus au fur et à mesure des passages de GG ...
Niveau 'test et référence SEO' cela pourrait même devenir fort attractif !!!
1 an tu y vas fort, en 3 mois tu as de bon résultats déjà.
1 année pour du e-commerce qui pourrait tenir compte des saisons je veux bien
pas la peine de commencer à polémiquer ... c'est juste une proposition
et en 3 mois ce sera à peine 'tout frais' que GG nous sortira une autre prise en compte ... (et l'on a jamais parlé de e-commerce ...)
wait & see .... ils savent de quoi ils parlent mes deux 'loulous' là ....
effectivement s'il faut tout dupliquer et vu la rapidité/simplicité de mise à jour de PluXml, je ne sais pas s'il faut un plugin spécifique ... je vais me débrouiller avec plusieurs instal et un champ de liaison inter-base.
Ce n'est pas que je n'ai pas le courage ... juste une question de priorité
Je vous propose un [del]petit plugin expérimental[/del] permettant d'avoir un pluxml multilingue.
Ne fonctionne qu'à partir de la version 5.1.7 car il utilise un nouveau hook de plxMotor et les chemins vers les fichiers critiques (config.php, path(XML_ etc...).
Il est compatible avec plxMyContact, plxMyAllArchive, ckeditor, plxMyLoremIpsum et plxMyPager mais pas avec plxPermalinks.
Il n'utilise pas de htacess particulier et fonctionne avec ou sans la réécriture d'url.
Pour l'utiliser, il faut d'abord paramétrer un pluxml "vierge". Ensuite, télécharger le plugin, l'activer. Par défaut, il utilise la langue par défaut du pluxml et crée des sous-dossiers xx/ (avec xx la langue), dans les dossiers articles, commentaires, configuration et statiques.
Seules les langues choisies dans le panneau d'administration seront accessibles dans la partie publique.
Il utilise un cookie pour propager la langue mais il tient compte aussi de la langue spécifiée dans l'url (l'url prend le dessus sur le cookie).
Les balises de pages (meta, link etc...) sont personnalisées en fonction de la langue. Le thème est commun à tous les thèmes.
Pour afficher le formulaire de changement de langue dans la partie publique, il faut appeler le hook :
<?php eval($plxShow->callHook('MultiLingue')); ?>
Petit écueil pour le sitemap et les flux : les adresses sont toujours du style sitemap.php?xx/ et feed.php?xx/rss(+/-commentaires et article) que la réécriture soit activée ou pas. Je n'ai pas trouvé comment rediriger avec la langue devant le nom de la page (sans recourir à un htaccess).
Je ne peux rien faire quant à la localisation du serveur ^_^ (voir post de zakar! un peu plus haut...)
Dites-moi ce que vous en pensez. Tous les retours seront les bienvenus.
PS : je retire le lien vers mon plugin afin de concentrer tous nos efforts vers celui de Stéphane qui deviendra bientôt officiel.
oula du lourd apparemment ... je teste ça dès que possible !
je n'irai pas jusque là quand même ... le site est super pour le look mais déjà manque de liens dans les posts ... et bien d'autres choses encore ...
et ensuite quand on veut voir la version "EN", actuellement :
"
Une erreur a été détectée :
Page non trouvée
Catégories ... "
donc ... ???
oula du lourd apparemment ... je teste ça dès que possible !
je n'irai pas jusque là quand même ... le site est super pour le look mais déjà manque de liens dans les posts ... et bien d'autres choses encore ...
et ensuite quand on veut voir la version "EN", actuellement :
"
Une erreur a été détectée :
Page non trouvée
Catégories ... "
donc ... ???
Qu'entends-tu par "manque de liens" ???
Précise aussi le "bien d'autres choses", car là c'est un peu vague et ça ne fait pas avancer le schmilblick.
Si tu n'as pas traduit l'article en anglais, il n'apparaitra pas. Ce n'est pas un traducteur automatique.
Chaque "article/categorie/tag/statique" est indépendant. Il faut faire la traduction d'une langue à l'autre.
Merci pour le plugin, je vais aussi le tester. Sinon quelle est la différence avec le plugin de Stéphane ?
Je me suis servi du plugin de Stéphane comme base et aussi de celui de Danielsan mais alors que celui de Stéphane ne permettait que la traduction des articles, le mien permet de traduire les catégories, les pages statiques, d'avoir une configuration indépendante par langue (titre, description), un sitemap et des flux différents par langue.
Seules les langues ayant été choisies en backend apparaissent en frontend.
Si l'on choisi une langue en frontend, l'ensemble du site est traduit (menus, sidebar, articles...).
En fait, c'est comme si on avait plusieurs pluxml (un pluxml par langue) mais compactés en un seul. L'intérêt est de n'avoir qu'un seul panneau d'administration.
Ton plugin, une fois installé, me renvoie une erreur 502 en frontend. [del](Au temps pour moi, ça ne viendrait pas du plugin).[/del] Je confirme : ça vient bien du plugin.
Si on modifie, la configuration d'une langue, cela ajoute autant de fois cette langue devant les chemins vers les articles, les commentaires et les pages statiques (du style articles/fr/fr/fr).
Les configurations ne sont pas indépendantes. Des dossiers sont créés par langue dans le dossier "configuration", mais ils restent vides (mis à part le htacess et l'index.html).
Apparemment, tu rediriges vers la page d'origine (PHP_SELF) sans tenir compte des paramètres passés dans l'url. Il ne permet donc pas de faire le lien entre deux articles dans deux langues différentes.
Je vais quand même y jeter un coup d'oeil plus approfondi afin d'améliorer le mien. ;-)
Merci Jerry pour ce plugin qui paraît très intéressant
Je ne pourrai pas le tester avant le mois prochain, car je suis moi aussi plus que complet du point de vue boulot (on doit être en haute saison !)
Réponses
C'est bien entendu sur les metas du site que je veux parler, mais aussi sur le nom du site, le slogan, le sitemap.
Tout ce qui concerne l'identité du site en sommes que les moteurs ce servent pour nous placer.
Dans cette logique pourquoi serait-ce plus compliquer de gérer plusieurs pluxml ayant leur propre langue et géré tout simplement via des sous domaine (fr.exemple.com, en.exemple.com) que par un plugins qu'il faudra être sur de mettre à jour tout les articles,pages,config et inc ?
en effet les id ne sont pas communs puisqu'on qu'on peut créer les articles des différentes versions dans l'ordre que l'on souhaite. Donc pas possible de pouvoir changer de langue tout en restant sur le même article ... mince
il me faut donc obligatoirement rajouter un champ de liaison avec l'article de référence pour gérer les images et touti quanti
ça aurait été bien un paramètre supplémentaire dans l'URL et une règle pour avoir /fr/article1/titre ou /en/article1/title
dans plxMyMultiLingue.php, comment remplacer par
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Qu'est-ce qui est plus simple en cas d'update: mettre à jour un pluxml et/ou un plugin ou tous les pluxmls ayant leur propre langue (sans parler des mises à jour des éventuels autres plugins utilisés qu'il faudra redescendre sur tous les sites)...
Perso je choisis la solution 1 car plus facile à gérer.
Sinon je suis d'accord, se pose le probleme du référencement avec les metas dans une langue différente pour la meme url du site
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Je le redis un site est unique aux yeux des moteurs de recherche, les plus gros site ce sont creuser eux aussi la tête pour ça et le plus simple pour eux et de dupliquer leur site pour vraiment avoir une identification différente suivant la langue et évite ainsi le duplicate content.
Sans oublier toutes les nouvelles règle pour 2013 des moteurs de recherches. Tenir un site et un boulot que seul ou une équipe peux mettre en place pour avoir de bon résultat en Seo car ce n'est pas une science exacte.
Je ne fait que partager mes connaissances dans ce domaine et bien d'autres personnes on tenté ce genre d'approche, s'il étais si facile ont aurai je pense pleins de réponse via une simple recherche.
Ps: un petit lien pour se documenter sur ce sujet et comment google vois la chose datant de 2010 mais bon vu que ça pour le moment.
ps2: Autre lien intéressant
Tu m'as convaincu. Effectivement, après reflexion je partage tes arguments
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
on oublie ce plugin et on décrit une méthode dans le Wiki pour gérer un site multi-langues ?
Dans les problématique il faut aussi tenir compte du charset qui diffère de la langue et de la localision géographique.
2 - une telle méthode dans le wiki, non, surtout pas !!!
3 - et pourquoi ne pas pousser plus loin ???
- - 1 site en 2 ou 3 langues utilisant le plugin
- - 2 ou 3 sites dans les mêmes langues, sans utilsation de plugin
... bon des sites de 'test' certes, mais sérieux quand même, sur, par exmple le sujet des "sites multilingues" ... et qui resteraient en ligne au moins un an ... là au moins l'expérience serait tentée, les résultats eux seront vus au fur et à mesure des passages de GG ...
Niveau 'test et référence SEO' cela pourrait même devenir fort attractif !!!
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
1 année pour du e-commerce qui pourrait tenir compte des saisons je veux bien
et en 3 mois ce sera à peine 'tout frais' que GG nous sortira une autre prise en compte ... (et l'on a jamais parlé de e-commerce ...)
wait & see .... ils savent de quoi ils parlent mes deux 'loulous' là ....
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
Ce n'est pas que je n'ai pas le courage ... juste une question de priorité
Ne fonctionne qu'à partir de la version 5.1.7 car il utilise un nouveau hook de plxMotor et les chemins vers les fichiers critiques (config.php, path(XML_ etc...).
Il est compatible avec plxMyContact, plxMyAllArchive, ckeditor, plxMyLoremIpsum et plxMyPager mais pas avec plxPermalinks.
Il n'utilise pas de htacess particulier et fonctionne avec ou sans la réécriture d'url.
Pour l'utiliser, il faut d'abord paramétrer un pluxml "vierge". Ensuite, télécharger le plugin, l'activer. Par défaut, il utilise la langue par défaut du pluxml et crée des sous-dossiers xx/ (avec xx la langue), dans les dossiers articles, commentaires, configuration et statiques.
Seules les langues choisies dans le panneau d'administration seront accessibles dans la partie publique.
Il utilise un cookie pour propager la langue mais il tient compte aussi de la langue spécifiée dans l'url (l'url prend le dessus sur le cookie).
Les balises de pages (meta, link etc...) sont personnalisées en fonction de la langue. Le thème est commun à tous les thèmes.
Pour afficher le formulaire de changement de langue dans la partie publique, il faut appeler le hook :
Petit écueil pour le sitemap et les flux : les adresses sont toujours du style sitemap.php?xx/ et feed.php?xx/rss(+/-commentaires et article) que la réécriture soit activée ou pas. Je n'ai pas trouvé comment rediriger avec la langue devant le nom de la page (sans recourir à un htaccess).
Je ne peux rien faire quant à la localisation du serveur ^_^ (voir post de zakar! un peu plus haut...)
Dites-moi ce que vous en pensez. Tous les retours seront les bienvenus.
PS : je retire le lien vers mon plugin afin de concentrer tous nos efforts vers celui de Stéphane qui deviendra bientôt officiel.
et ensuite quand on veut voir la version "EN", actuellement :
"
Une erreur a été détectée :
Page non trouvée
Catégories ... "
donc ... ???
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
Qu'entends-tu par "manque de liens" ???
Précise aussi le "bien d'autres choses", car là c'est un peu vague et ça ne fait pas avancer le schmilblick.
Si tu n'as pas traduit l'article en anglais, il n'apparaitra pas. Ce n'est pas un traducteur automatique.
Chaque "article/categorie/tag/statique" est indépendant. Il faut faire la traduction d'une langue à l'autre.
Seules les langues ayant été choisies en backend apparaissent en frontend.
Si l'on choisi une langue en frontend, l'ensemble du site est traduit (menus, sidebar, articles...).
En fait, c'est comme si on avait plusieurs pluxml (un pluxml par langue) mais compactés en un seul. L'intérêt est de n'avoir qu'un seul panneau d'administration.
L'arborescence finale est du style :
data/
- articles/
-- fr/
-- en/
- commentaires/
-- fr/
-- en/
- configuration/
-- fr/
-- en/
- documents/
- images/
- statiques/
-- fr/
-- en/
Ma version ne gère pas que les articles mais beaucoup plus:
http://forum.pluxml.org/viewtopic.php?pid=28893#p28893
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Aaarrrrgggggg ! J'avais pas vu la modif. La langue apparait dans l'url ? Et prend-elle le pas sur le cookie ?
Si on modifie, la configuration d'une langue, cela ajoute autant de fois cette langue devant les chemins vers les articles, les commentaires et les pages statiques (du style articles/fr/fr/fr).
Les configurations ne sont pas indépendantes. Des dossiers sont créés par langue dans le dossier "configuration", mais ils restent vides (mis à part le htacess et l'index.html).
Apparemment, tu rediriges vers la page d'origine (PHP_SELF) sans tenir compte des paramètres passés dans l'url. Il ne permet donc pas de faire le lien entre deux articles dans deux langues différentes.
Je vais quand même y jeter un coup d'oeil plus approfondi afin d'améliorer le mien. ;-)
Je ne pourrai pas le tester avant le mois prochain, car je suis moi aussi plus que complet du point de vue boulot (on doit être en haute saison !)