Agilité, Développement Java, Nouvelles technologies et plus…
  • rss
  • Accueil
  • Management
  • Programmation agile
  • Technologie
  • Linux
  • Evénement
  • App Android
  • Contact
  • A propos de l'auteur
  • English
  • Francais

Rendre son site WordPress multilingue avec qTranslate

Fabian Piau | mardi 25 mars 2014 - 08:00
  • Imprimer
  • Twitter
  • LinkedIn
  • Facebook
  • Pocket

 English version available

Mise à jour
21 juin 2020 : Le plugin « qTranslate XT » a pris la relève de qTranslate comme ce dernier n’est plus supporté par son créateur. CarmaBlog utilise désormais qTranslate XT et il n’y a eu aucun problème pour migrer de qTranslate ou qTranslate X vers qTranslate XT, un mode de compatibilité existe. Le contenu de cet article est toujours exact.

qTranslate - WordPress multilingue

Ce n’est pas une fonctionnalité native de WordPress, heureusement l’extension gratuite qTranslate existe. La simple activation de l’extension ne fera malheureusement pas tout, il va falloir aller plus loin que cela.

Les avis des utilisateurs sur qTranslate sont assez mitigés, car une majorité d’entre eux l’installe en espérant n’avoir rien (ou quasiment rien) à configurer. Et souvent, ils se plaignent quand ils se rendent compte que ça ne répond pas à leurs attentes (et en profite au passage pour donner une mauvaise note).

WordPress évoluant en permanence avec des milliers d’extensions disponibles, il est impossible de réaliser une extension multilingue parfaite pouvant tout supporter au biais d’une interface unique, tout ceci sans avoir un seul problème de compatibilité. Ce serait trop beau, d’autant plus que je rappelle que qTranslate est gratuit.


Un thème et des extensions multilingues sinon rien

Pour commencer, si votre thème n’est pas lui-même multilingue (c.-à-d. livré avec plusieurs fichiers de langues et supportant le passage de l’un à l’autre), ce n’est même pas besoin d’aller plus loin. Deux choix s’offrent à vous:

  • Soit changer de thème par un plus récent gérant le multilingue
  • Soit rendre votre thème multilingue (si c’est votre thème, vous devriez savoir le faire et rentrer dans votre code, même si cela prendra un peu de temps).

Aussi, si vous utilisez des dizaines d’extensions « exotiques », il y a fort à parier que vous allez rencontrer des problèmes de compatibilité avec qTranslate. Je vous conseille de vous limiter à une quinzaine d’extensions parmi les plus utilisées. C’est en particulier vrai pour les extensions indispensables dans le sens où votre site ne peut fonctionner bien si vous les désactivez.

Une extension réputée et de préférence bien notée (cela va de pair normalement) permettra de vous assurer:

  • Qu’elle est bien suivie (mise à jour de versions régulière, au fur et à mesure des nouvelles versions de WordPress)
  • Que vous aurez un support suffisant (il y a surement un utilisateur qui a rencontré le même problème que vous)
  • Qu’elle est multilingue. Rendre une extension multilingue est envisageable, mais si c’est évitable, alors autant s’en passer…

Vous pouvez consulter la liste des extensions que j’utilise, elles sont toutes fonctionnelles avec qTranslate et sont, pour la plupart, connues et plutôt bien notées.

Si votre thème et vos extensions sont multilingues, vous verrez que le changement de langue avec qTranslate impactera bien tout cela. Par exemple, l’interface de l’extension Jetpack ou le tableau de bord administrateur WordPress suivront le changement de langue.


Gestion des traductions depuis le tableau de bord WordPress

La gestion des articles est bien intégrée avec qTranslate. Vous aurez autant de champs que de langues choisies pour le titre et le contenu des articles. Même chose pour les catégories et les mot-clés.
qTranslate vous permet d’activer autant de langues souhaitées. Dans mon cas, j’ai activé l’anglais et le français. J’ai donc tous les champs traduisibles en double.

Ecrire un article avec qTranslate activé

Ecrire un article avec qTranslate activé

Si la majorité des informations sont traduites de manière automatique, ce n’est pas le cas pour toutes les informations. Notamment celles déjà existantes que j’avais dû remplir au début lors de la création du blog.
Je peux utiliser un tag fourni par qTranslate pour ajouter mes propres traductions sur ces informations, sous la forme: [:code_lang_1]Mon texte en langue 1[:code_lang_2]Mon texte en langue 2.

Par exemple, voici la nouvelle valeur pour le slogan du site qui s’affiche en haut:

Adapter le slogan du site en fonction de la langue

Adapter le slogan du site en fonction de la langue

De la même façon, il faut modifier autant que possible les titres, les descriptions de tous les textes qui apparaissent sur le site et qui ne sont pas traduit. Voici une liste non exhaustive (dépendante des extensions que j’utilise):

  • Le slogan du site
  • Les titres de certains widgets
  • La description de chacun des liens de site
  • L’affichage d’une ligne sur l’auteur dans le flux RSS (WordPress SEO)
  • Le texte utilisé dans le compteur de vue (WP-PostViews)
  • Le texte utilisé pour le navigateur de page (page précédente, suivante, dernière…) (WP-PageNavi)
  • Le titre et le texte par défaut pour les articles similaires (Yet Another Related Posts Plugin – YARPP)

Si vous utilisez l’extension Contact Form 7, pensez à créer vous-même autant de formulaires de contact que votre site supporte de langues.


Gestion avancée des traductions (code source)

Toutes les modifications et petites améliorations possibles depuis l’interface d’administration étant terminées, vous allez vite vous rendre compte qu’il reste encore quelques petites choses à améliorer pour rendre votre site complètement multilingue.
Dans ce cas, il n’y a plus d’autre choix possible que de se plonger dans le code PHP et de modifier manuellement quelques fichiers de WordPress, de votre thème ou même de certaines extensions. Par exemple:

  • La prise en compte de la langue lors de la construction du lien vers les flux RSS
  • L’ajout du sélecteur de langue qTranslate dans le header du thème
  • L’affichage d’images différentes dans le thème en fonction de la langue
  • La prise en compte de la langue dans les extensions telles que Shadowbox, List category posts, WordPress SEO, Disqus, Social media icons…

Pour cette dernière partie, il n’y a pas de secret, il faut modifier le code à la main en appelant des fonctions disponibles quand qTranslate est activé.
Voici un bout de code pour récupérer la langue et setter un texte différent suivant le cas.

if(function_exists('qtrans_getLanguage')) {
	$lang = qtrans_getLanguage();
	if ($lang == 'en')
		$text = 'anglais';
	else
		$text = 'francais';
}

Attention, quand vous commencez à modifier le code, sachez qu’une mise à jour écrasera vos modifications. Pensez donc bien à noter TOUTES les modifications effectuées avant de mettre à jour WordPress, votre thème ou une de vos extensions. Si cela devient trop compliqué à maintenir, il peut être intéressant de prévoir un système pour automatiser l’intégration de vos modifications après une mise à jour. A vous de voir.


Dans bien des cas, vous l’aurez compris, vous aurez besoin de rentrer vous-même dans le code des extensions incompatibles. C’est un passage obligé pour résoudre certains problèmes, mais aussi pour peaufiner au maximum le changement de langue afin de rendre l’expérience utilisateur la plus complète possible.

Avec le temps, vous allez finalement vous compte que le plus dur et fastidieux n’aura pas été de rendre votre site multilingue, mais de traduire tous vos articles dans les langues que vous supportez!

Articles similaires

Gnome 3 ShellPersonnaliser Gnome 3 (Shell) wordpress-hackerConseils pour sécuriser votre site WordPress WordPressExtensions WordPress de CarmaBlog Mobile devicesUne version mobile de votre Blog WordPress
Commentaires
13 Commentaires »
Catégories
Programmation agile
Tags
multilingue, plugin, qtranslate, wordpress
Flux rss des commentaires Flux rss des commentaires

Faire du Responsive Web Design: oui, mais simplement!

Fabian Piau | mardi 23 juillet 2013 - 19:00
  • Imprimer
  • Twitter
  • LinkedIn
  • Facebook
  • Pocket

 English version available

Il n’y a pas si longtemps, je vous parlais du « Mobile theme » inclus dans l’extension Jetpack pour que votre blog WordPress soit accessible de manière lisible et adaptée sur les appareils mobiles.

Je ne reviens pas sur mes dires à propos de ce thème mobile, car il fonctionne très bien et chaque nouvelle version du plugin Jetpack apporte son lot d’améliorations. Surtout, il a un avantage certain: une configuration quasi proche du néant, il suffit d’un clic pour activer le thème, on peut difficilement faire mieux. Oui, mais… si un peu de développement ne vous fait pas peur, il y a encore mieux!

Je parle du Responsive Web Design (conception de sites web adaptatifs), en plus c’est très tendance en ce moment, et ce n’est pas qu’une mode passagère. Grâce au Responsive Web Design, le site reste le même pour toutes les plateformes et s’adapte automatiquement à la taille de l’écran. L’identité de votre site reste la même (thème, images, couleurs…) et cela vous évite de faire de la gestion de multi-versions: une version desktop, mobile, tablette… La gestion du site est donc simplifiée et la maintenance facilitée.

Responsive Web Design

Avant, les tailles d’écran étaient peu nombreuses (une bonne vieille résolution 1024 x 768 ou, pour les plus chanceux, une résolution 1280 x 1024), c’était le temps des écrans 17 et 19 pouces à tube cathodique (aïe, mes yeux, ça pique… Bon ok je ça commence à dater). Aujourd’hui, il y a des centaines de tailles différentes, Internet est partout que ce soit sur la télévision, dans votre voiture ou même dans votre frigo (bon là je vois un peu trop loin, mais le tout-connecté n’est peut-être pas si loin). Bref, il n’est plus envisageable de travailler sur des résolutions fixes au cas par cas.

Bien sûr dans le cas d’une application spécifique, il y a des arguments contre le Responsive Design. Une application web aura des performances plus lentes comparée à une application native, mais ce n’est pas l’objet de cet article. Cet article met le focus sur les sites web, disons grand public (site d’un journal, site marchand…), qui veulent se rendre accessibles sur mobile et veulent éviter des versions mobiles dédiées (les fameuses URL commençant par « m »). Par exemple m.facebook.com, m.linkedin.com ou encore m.lequipe.fr qui vont disparaitre tôt ou tard.


Testez vous-même

Vous pouvez dès maintenant modifier la taille de la fenêtre de votre navigateur, vous verrez que ce blog s’adaptera automatiquement en conséquence (si vous voyez des bogues ou des idées d’amélioration, je suis preneur!).

CarmaBlog en 1024 x 768

CarmaBlog en 1024 x 768

CarmaBlog en 400 x 768

CarmaBlog en 400 x 768


Vous l’aurez sans doute remarqué, voici les impacts lorsque la taille de la fenêtre diminue:

  • Le menu principal devient plus petit avant de se transformer en une liste déroulante.
  • Des blocs passent à la ligne (icône RSS et boîte de recherche).
  • Le contenu secondaire disparait au profit du principal. Sur un petit écran, on veut aller à l’essentiel (ici les articles) et éviter au maximum les scrolls.
  • L’effet d’ombre et d’arrière-plan disparait. Sur les petits écrans, quelques dizaines de pixels de gagné peuvent représenter 10% de la résolution totale, ce n’est pas négligeable.
  • Les images se redimensionnent pour éviter des disproportions trop fortes.


Des frameworks Responsive, en veux-tu en voilà…

De nombreux frameworks existent pour vous aider à réaliser un site responsive. Le plus connu est sans doute Bootstrap, d’ailleurs c’est le seul que j’ai pu utiliser sur un projet. Il y en a plein d’autres:

  • Foundation
  • Gumby
  • Unsemantic
  • Skeleton
  • Pure
  • KnaCSS


Du Responsive fait-maison!

Il est aussi possible de faire du Responsive Web Design soi-même, sans framework. C’est ce que j’ai fait pour mon blog. Un peu de CSS, un peu de Javascript et quelques heures de boulot suffiront. Ce ne sera peut-être pas compatible avec IE6, ça n’affichera sûrement pas de superbes animations bling-bling, mais cela suffira dans la majorité des cas.

Le secret, c’est l’utilisation des media queries disponibles depuis CSS3, voici des exemples de code:

@media all and (max-width:1000px) {
	.sidebar div {
		display:none;
	}
}

Quand l’écran fait moins de 1000 pixels en largeur, on masque les sidebars à gauche et à droite.


@media all and (min-width:870px) and (max-width:975px) {
	#menu ul li {
		font-size:.7em;
	}
	#header_image {
		height:150px;
	}
}

Quand l’écran fait entre 870 pixels et 975 pixels, on rétrécit le menu (la taille de la police) et le header.


@media all and (max-width:870px) {
	#menu {
		display:none;
	}
	#menuselect select {
		display:block;
	}
	#header_image {
		height:80px;
	}
}

Quand l’écran fait moins de 870 pixels, on cache le menu et le remplace par la liste déroulante et on rétrécit encore l’image du header.


@media all and (max-width:585px) {
	img:not(.fixed):not(.avatar):not(.wp-smiley):not(#sb-player) {
		height:auto !important;
		max-width:80%;
		min-width:70px;
	}
}

Toutes les images dépendent de la taille de l’écran quand celui-ci fait moins de 585 pixels. Les images avec les classes CSS « fixed », « avatar », « wp-smiley » ou ayant l’ID « sb-player » ne sont pas concernées. J’ai eu le problème d’avoir des images grossies avec certaines icônes comme les smileys ou le lecteur d’images Shadowbox.js… Aussi, une image ne peut faire moins de 70 pixels de hauteur (en dessous, je pense qu’il faudrait une très bonne vue).

A noter: j’utilise le mot clé « !important » pour redéfinir un style déjà présent. La valeur spécifiée avec le « !important » écrasera toujours les autres.


J’ai aussi écrit un peu de Javascript pour la création de la liste déroulante qui remplace le menu. Je ne mets pas le code ici (c’est très spécifique à mon site), mais sachez que la fonction ne fait pas plus de 15 lignes. J’ai profité du fait que la librairie jQuery était déjà incluse dans le projet pour utiliser quelques-unes de ses fonctions, histoire d’économiser quelques lignes de code.

En tout, il m’aura fallu environ 200 lignes de code CSS (avec le formatage ci-dessus donc beaucoup de lignes contenant une seule accolade fermante) pour rendre mon site responsive. Ce n’est pas aussi compliqué qu’on aurait pu le penser.

Enfin, il y a une dernière chose importante. Dans le header de vos pages, ajoutez cette balise meta pour indiquer que votre site est adapté pour les mobiles.

<meta name='viewport' content='width=device-width, initial-scale=1.0'>


Vérification

Finalement, le plus long et fastidieux aura été l’affinage des styles en fonction de la résolution. Pas de secret, c’est un processus manuel itératif: on modifie le CSS, on rafraîchit la page et on inspecte.

A ce propos, le site Responsinator teste un site sous les résolutions d’écran les plus fréquentes correspondant à des appareils grand public. Vous pouvez aussi installer Firesizer, une extension Firefox pour connaitre la résolution de la fenêtre du navigateur, très utile lors de la construction des media queries.

Articles similaires

Maven sitePlus loin avec le Maven Site devoxxDevoxx UK 2018 – Jour 2 IT jobsPanorama simplifié des métiers de l’informatique microservices-legoArchitecture Microservices – Les bonnes pratiques
Commentaires
5 Commentaires »
Catégories
Programmation agile
Tags
css, design, mobilité informatique, responsive, wordpress
Flux rss des commentaires Flux rss des commentaires
Page 2 sur 3123
Télécharger l'app CarmaBlog

Flux RSS

  • RSS Feed RSS - Articles
  • RSS Feed RSS - Commentaires

Articles les plus vus

  • Changer la langue de Firefox - 114 918 vues
  • Réaliser un sondage en ligne avec Google Forms / Drive / Docs - 61 556 vues
  • FAQ – Sondage en ligne avec Google Forms / Drive / Docs - 41 503 vues
  • Personnaliser Gnome 3 (Shell) - 29 113 vues
  • La signification d’URL, URI et URN - 15 929 vues
  • Java EE & CDI vs. Spring - 14 821 vues
  • Open Street Map, une meilleure carte que Google Maps? - 13 780 vues
  • Comparaison NoSQL: Couchbase et MongoDB - 13 530 vues
  • Firefox Nightly, Aurora, Beta, Desktop, Mobile, ESR & Co. - 12 725 vues
  • Une première approche du Camel d’Apache - 11 725 vues

Commentaires récents

  • Saint hilaire albert sur FAQ – Sondage en ligne avec Google Forms / Drive / Docsmerci beaucoup
  • Fabian Piau sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsNon, ce n’était pas la bonne pratique effectivemen…
  • Saint hilaire albert sur FAQ – Sondage en ligne avec Google Forms / Drive / Docsah, alors je crois avoir trouvé : mon lien se term…
  • Fabian Piau sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsJe n'arrive pas à reproduire car si vous cliquez s…
  • Saint hilaire albert sur FAQ – Sondage en ligne avec Google Forms / Drive / Docsje vais tenter d'être plus précis : j'envoie un li…

Articles récents

  • Flagger – Monitorer vos déploiements Canary avec Grafana - Il y a 6 mois et 4 semaines
  • Flagger – Déploiements Canary sur Kubernetes - Il y a 8 mois et 1 semaine
  • Flagger – Premiers pas avec Istio et Kubernetes - Il y a 8 mois et 3 semaines
  • CoderDojo Expedia à Londres - Il y a 1 an et 6 mois
  • Etre bénévole à Devoxx4Kids - Il y a 1 an et 8 mois
  • Une migration Java 11 réussie - Il y a 2 ans et 4 semaines
  • Conseils pour sécuriser votre site WordPress - Il y a 2 ans et 3 mois
  • Devoxx UK 2018 – Jour 2 - Il y a 2 ans et 7 mois
  • Devoxx UK 2018 – Jour 1 - Il y a 2 ans et 8 mois
  • TransferWise, Revolut et Monzo, une petite révolution dans le monde des expatriés et voyageurs - Il y a 3 ans et 5 jours
  • Autocomplétion pour Git - Il y a 3 ans et 8 mois
  • Swagger, la documentation API automatisée - Il y a 3 ans et 10 mois
  • Architecture Microservices – Les bonnes pratiques - Il y a 4 ans et 3 mois
  • FAQ – Sondage en ligne avec Google Forms / Drive / Docs - Il y a 4 ans et 9 mois
  • QCon London 2016 – Projet Jigsaw dans JDK 9 – La modularité arrive sur Java - Il y a 4 ans et 9 mois
Offre moi un café

Langue

  • Français
  • English

Suivez-moi!

Suivez-moi sur Linkedin
Suivez-moi sur Twitter
Suivez-moi sur Stackoverflow
Suivez-moi sur Github
Suivez-moi sur Rss
Link to my Contact

Abonnement email

Saisissez votre adresse email pour être informé des nouveaux articles.

Étiquettes

.net agilité android bash blog bonnes pratiques cache cloud conférence css devoxx docker docs drive développeur eclipse extreme programming firefox flagger forms google helm hibernate informatique intégration continue istio java jug kubernetes londres mobilité informatique métier outil panorama partage performance plugin programmeur qcon script société spring ubuntu windows wordpress

Liens

  • Blog Ippon Technologies
  • Blog Publicis Sapient
  • Blog Zenika
  • Classpert
  • CommitStrip
  • Coursera
  • Le Touilleur Express
  • Les Cast Codeurs Podcast
  • OCTO talks !
  • The Twelve-Factor App

Catégories

  • Evénement (15)
  • Linux (3)
  • Management (7)
  • Programmation agile (29)
  • Technologie (44)

Archives

  • juin 2020 (1)
  • mai 2020 (2)
  • juillet 2019 (1)
  • mai 2019 (1)
  • décembre 2018 (1)
  • octobre 2018 (1)
  • juin 2018 (1)
  • mai 2018 (1)
  • janvier 2018 (1)
  • mai 2017 (1)
  • mars 2017 (1)
  • octobre 2016 (1)
  • avril 2016 (2)
  • mars 2016 (1)
  • novembre 2015 (1)
  • mai 2015 (1)
  • février 2015 (1)
  • décembre 2014 (1)
  • novembre 2014 (1)
  • septembre 2014 (2)
  • août 2014 (1)
  • juillet 2014 (2)
  • juin 2014 (1)
  • avril 2014 (1)
  • mars 2014 (1)
  • février 2014 (2)
  • janvier 2014 (1)
  • décembre 2013 (1)
  • novembre 2013 (1)
  • octobre 2013 (3)
  • septembre 2013 (5)
  • juillet 2013 (1)
  • juin 2013 (1)
  • mai 2013 (1)
  • avril 2013 (1)
  • mars 2013 (2)
  • février 2013 (1)
  • janvier 2013 (2)
  • décembre 2012 (2)
  • octobre 2012 (1)
  • septembre 2012 (1)
  • juillet 2012 (1)
  • mai 2012 (1)
  • avril 2012 (1)
  • mars 2012 (1)
  • février 2012 (1)
  • janvier 2012 (2)
  • décembre 2011 (1)
  • novembre 2011 (2)
  • octobre 2011 (2)
  • septembre 2011 (1)
  • juillet 2011 (1)
  • juin 2011 (2)
  • avril 2011 (1)
  • mars 2011 (1)
  • février 2011 (1)
  • janvier 2011 (2)
  • novembre 2010 (2)
  • septembre 2010 (1)
  • août 2010 (1)
  • juillet 2010 (1)
  • juin 2010 (1)
  • mai 2010 (1)
  • avril 2010 (1)
  • mars 2010 (1)
  • février 2010 (1)
  • décembre 2009 (1)
  • novembre 2009 (1)
  • octobre 2009 (2)
  • septembre 2009 (2)
  • août 2009 (3)
  • juillet 2009 (1)
  • juin 2009 (2)
Suivez-moi sur Twitter
Suivez-moi sur Linkedin
Suivez-moi sur Stackoverflow
Suivez-moi sur Rss
Link to my Contact
Suivez-moi sur Github
 
Fabian Piau | © 2009 - 2021
Tous droits réservés | Haut ↑