Internationaliser un site

[francoisch]

Bonjour

Jai un site avec très peu de texte mais, naturellement, tout ce qui y est écrit est en français.

Je cherche maintenant à « internationaliser », un peu, mon site en présentant des libellés rédigés en anglais aux visiteurs anglais.

Comment my prendre en Php ?

Je pense à externaliser tous les libellés dans un tableau bi-dimensionnel (francais, anglais), tester le bon langage à lentrée du visiteur dans le site et pointer sur les libellés adéquats.

Merci de tous vos avis et conseils.

Francois

[Dadou]

Le mieux est de faire comme si tu créais deux sites, qui pourraient avoir une structure différente, je sais par expérience que les sites multilingues ne sont pas toujours mis à jours dans toutes les langues qu'ils proposent.

Quand à une éventuelle détection de la langue, je le déconseille aussi, un certain nombre d'internautes utilisent des navigateurs qui ne sont pas forcement dans leur langue maternelle, en l'occurence, c'est souvent le cas pour des groupes américains implantés en france, qui pour un soucis de support impose à tous leurs utilisateurs la version US des logiciels.

[francoisch]

Merci de ta réponse Dadou.

Partant du fait que mon site a très peu de libellés et que je ne vais gérer que deux langues, je penche actuellement pour une solution très simple:

- choisissant (ou détectant) la langue au début de la visite

- j' "include" un fichier ou un autre (francais, anglais) avec les libellés placés dans des variables

- naturellement, dans mes pages, je remplace les libellés actuels par <?php echo $variable ?>

Je suis conscient que c'est très rustique masi ça doit convenir à ma situation.

Aussi, j'ai bien compris ta remarque à propos de la détection et je vais en tenir compte.

Merci encore de ton aide.

Francois

[slender]

salut

- choisissant (ou détectant) la langue au début de la visite

Peut-être à faire à l'entrée du prospect sur le site en visite initiale mais offrir un panel de boutons (dans ton cas, 2) pour opérer un changement de langue au gré de l'utilisateur. A conserver dans le cookie si il revient.

Sinon, pour un petit nombre de pages ta méthode convient:

en fichier include:

$string_lang = array(

'TITRE_H1' => array(

'fr' => "titre1",

'en' => "title1"),

'TEXT_01' => array(

'fr' => "<p>bonjour</p>",

'en' => "<p>hello</p>"));

puis dans ta page tu rappelles:

$string_lang['TITRE_H1'][$langue]

ou

$string_lang['TEXT_01'][$langue]

[argentcool]

Bonjour francoisch

Dans mon site bestvoc.com (7 langues) j'ai mis toutes les traductions dans une base de données MySql.

Pour chaque page je charge les traductions de cette page dans telle langue.

On ne sait jamais comment un site peut évoluer :-)

Devoir tout adapter par la suite, c'est l'enfer...

Amicalement,

Patri.ck

[TheRec]

Bonjour,

Je ne suis pas totalement d'accord avec Dadou concernant la négociation de langue, elle n'est pas nécessaire mais en même temps elle ne pose aucun problème si par la suite il est possible à l'utilisateur définir lui-même la langue dans laquelle il souhaite utiliser le site (dans le cas où la négociation n'aurait pas été efficace). De plus, si tu ne proposes pas ce genre de négociation cela implique d'avoir une langue par défaut ou un sélecteur de langue à l'entrée du site, ce qui du point de vue de l'utilisabilité ne se justifie pas plus qu'une simple négociation de langue. Même si un utilisateur est forcé à utiliser un navigateur dont l'interface n'est pas dans la langue dans laquelle il veut consulter le contenu, il a la possibilité de définir, dans la majorité des navigateurs modernes, une liste de priorité des langues qui est justement utilisée dans la négociation de contenu. Certains répondront que cette fonctionnalité des navigateurs n'est pas très "connue" et à cela je répondrai que c'est exactement la même problématique que les liens avec target="blank", les développeurs n'ont pas à corriger ou forcer le comportement de l'utilisateur face au navigateur et à sa configuration.

[Dadou]

Même si un utilisateur est forcé à utiliser un navigateur dont l'interface n'est pas dans la langue dans laquelle il veut consulter le contenu, il a la possibilité de définir, dans la majorité des navigateurs modernes, une liste de priorité des langues qui est justement utilisée dans la négociation de contenu.

Encore faut il que l'utilisateur soit apte à le faire, et en général quand il est forcé à utiliser un navigateur dont l'interface est dans une autre langue que la langue dans laquelle il veut consulter le contenu, il n'a pas forcement :

- Les connaissance pour modifier le réglage du navigateur

- Ou tout simplement les droits pour le faire (et c'est le cas dans la plupart des grosses boites)

Certains répondront que cette fonctionnalité des navigateurs n'est pas très "connue" et à cela je répondrai que c'est exactement la même problématique que les liens avec target="blank", les développeurs n'ont pas à corriger ou forcer le comportement de l'utilisateur face au navigateur et à sa configuration.

Non pas d'accord, le rôle du dév est de faire une interface intuitive facile à utiliser, par une interface ou l'utilisateur doit aller farfouiller dans les réglages de son navigateur.

De plus en général, la détection de langues casse l'historique de navigation, et c'est des plus pénibles, exemple de cas vécu par des utilisateurs lambda :

Ils font une recherche sur google,

ils cliquent sur le premier résultat,

détection de la langue, hop envoyé vers la version française du site

le site ne correspond pas à ce qu'ils souhaitent, et cliquent donc sur le bouton précédent

re-dectection de la langue, hop re-envoyé vers la version française du site

et ainsi de suite

En tant qu'utilisateur averti, je connais bien les réglages de mon navigateur, je maitrise bien aussi l'historique de navigation, mais je trouve très pénible les sites qui me redirigent automatiquement.

Laisser à l'internaute le choix de sa langue est la solution la plus ergonomique qui existe pour un site multilangues.

[captain_torche]

Personnellement, si détection de langue il doit y avoir, je pense qu'elle ne doit se faire que sur la page d'accueil du site. Les autres pages doivent proposer un lien vers d'autres versions localisées, mais rien d'automatique.

[TheRec]

C'était mon propos captain_torche, merci de l'avoir clarifié. Je ne vois pas en quoi proposer cette fonctionnalité, qui n'influence que le choix de la langue lorsqu'elle n'est pas spécifiquement définie par l'utilisateur (par un sous-domaine, un prefix dans le chemin et en dernier ressort une variable de session)... mais bon si tu trouve plus ergonomique de le laisser arriver sur un langue par défaut dans tous les cas ou un sélecteur de langue à l'entrée du site, pourquoi pas Mon optique est de faire "au mieux", vu que l'information transmises par les en-têtes HTTP n'est pas une garantie de la langue de l'utilisateur. Et dans tous les cas, sans négociation, tu ne pourras pas présenter de page dans la langue de l'utilisateur... donc le choix se résume à soit essayer de proposer quelque chose qui correspond à l'environnement de travail de l'utilisateur (si le choix n'a pas été fait avant selon la décision de l'utilisateur avec les moyens évoqués précédemment !) ou ne pas s'occuper de la langue de l'utilisateur et le laisse changer la langue quand elle ne lui convient pas.

Le fait que la négociation de langue "casse" l'historique tient plus du fait du développeur que de la technique en elle-même, il est tout à fait possible de développer la négociation de façon à ce qu'elle soit une simple redirection par en-tête. Le cas que tu expliques correspond justement à une redirection effectuée en contradiction avec les recommandations du W3C, forcément tu t'expose à ce genre de problèmes.

Et évidemment que laisser le choix à l'utilisateur, sur toutes les page du site est primordial... négociation de langue ou non

P.S. : Pour ce qui est d'arriver sur le site depuis un moteur de recherche, le seul problème (outre une mauvaise redirection) se pose pour les pages qui n'ont pas une URL spécifique en fonction de la langue (ce que le W3C ne recommande pas), entre autre la page d'accueil du site généralement... après c'est clair que si tu laisses l'accès aux autres contenus sans discriminer leur langue au moyen de l'URL tu te retrouve dans la même situation. Un site multilingue implique donc une gestion stricte des URL de chaque page, pour limiter l'usage de négociation de langue à la seule page d'accueil.

[francoisch]

bonjour et merci de vos nombreuses réponses.

Comme mes besoins sont simples comme vous l'avez compris, j'ai adopté des solutions simples.

Pour la langue, je la détecte dans le navigateur, au moins pour le tout début de la visite, avant l'identification; comme mes visiteurs sont ensuite identifiés en début de visite, je peux forcer la langue pour chacun si besoin est.

Aussi, comme j'ai très peu de texte et deux langues seulement, je ne suis pas allé jusqu'à une solution avec MySql; j'ai simplement deux fichiers Php qui contiennent chacun des variables pour chaque élément de texte.

Je n'ai donc qu'un seul jeu de pages qui contiennent des variables Php à la place des textes.

Pour le futur, si mes textes se développaient, si je devais supporter d'autres langages, je suis conscient qu'il faudrait que je change mon fusil d'épaule, allant dans les directions que vous mentionnez (pages en Mysql, ...).

Merci de votre aide.

Francois