Comment faire un site web Multilingue

Réponse courte: il n'y a pas de réponse courte, comme il y a beaucoup de variables à prendre en compte, et beaucoup de travail à faire. Alors...

Réponse longue: je vais le décomposer ainsi que je le peux, mais il n'y a pas un "bon pour tous" réponse à une question aussi large que la vôtre.

D'abord, les variables de la tâche à accomplir:

1. Liste des langues: votre site d'être dans un ensemble prédéfini de langues, ou qu'il sera varié/hétérogène? Par exemple, un site peut être entièrement bilingue dans les deux langues définies par l' (ou, autre exemple, je lance un anglais/Catalan/espagnol site); ou différentes sections peuvent être disponibles sur les différents ensembles de langues (pour un exemple, regardez MS du sites: elles sont principalement homogène, mais des trucs comme les blogs, les articles de base de connaissances, et certains documents sont uniquement disponibles dans un sous-ensemble de la soi-disant langues prises en charge).

2. Traductions source: le contenu est fourni dans chaque langue par vous-même ou certains collaborateurs? Ou certains sont des versions de lancer à travers un logiciel de traduction à partir d'une seule langue de "base"? La première méthode prend beaucoup de travail supplémentaire pour produire le contenu, mais les rendements des résultats de meilleure qualité que la seconde.

3. Langues elles-mêmes: une fois que vous avez 1) et 2) ont répondu, vous aurez besoin d'être conscient de exactement quelles sont les langues que vous travaillez avec. Notez que dans le cas où vous incluez des dialectes (ex: anglais US + UK anglais ou l'Argentine, en espagnol + Espagne espagnol), vous pouvez rencontrer certains des "duplicate content" problèmes avec les moteurs de recherche, mais les détails sont trop hors-sujet ici (il suffit de mentionner si vous êtes conscient des problèmes potentiels).

4. Ciblez-vous les langues dans l'abstrait (par exemple, mon site vous propose les trois langues sans se soucier le moins du monde, où le visiteur est: qu'est ce que j'ai, afin de choisir ce que vous préférez); ou plutôt cibler les différents pays/régions? Dans ce dernier cas, les choses peuvent obtenir un supplément complexe, comme vous l'avez peut-être besoin de prendre soin des autres choses en plus de langues (comme les fuseaux horaires, des devises, ou de la date format de l'heure conventions, pour n'en citer que certains), mais vous obtenez les avantages d'être en mesure d'utiliser spécifique au pays des Tld.

Une fois que vous avez la-dessus bien définis, nous allons commencer à travailler. Ces sont les plus importants de tâches que vous devez faire de la poignée:

1. Détection de la langue: le plus raisonnable est d'utiliser un paramètre GET (quelque chose comme ?lang=fr-fr dans l'URL). Aussi, vous pourriez utiliser certains cookies et/ou de géolocalisation IP de tomber en arrière quand une URL sans langue argument est demandé. Aussi, si vous en avez les moyens, de traiter le thème de l'URL d'embellissement (ce qui a l'air mieux: example.com/index.php?lang=en-us ou example.com/en-us/home?). Personnellement, j'aime le pouvoir ModRewrite subventions à mon .fichier htaccess, mais qui ne fonctionnera que sur Apache-alimenté serveurs.

2. De gestion de contenu: peu importe si vous êtes récupérer le contenu à partir d'une base (comme le contenu de l'article), les fichiers (typique pour les chemins de navigation, les menus, à l'échelle du site rubriques, etc), ou par tout autre moyen, vous aurez besoin d'un moyen de séparer chaque version (langue) du contenu. Voici quelques exemples de la façon dont il peut être fait:

   • Pour DB contenu, mon meilleur conseil est de venir avec une solide champ modèle de nommage et de s'y tenir. Par exemple, j'ai ajouter _en, _es, ou _ca à tous dépendants de la langue champs de ma DB. De cette façon, je peux accéder à du contenu à droite avec des expressions comme $row["title_$lang"].
   • Pour inclure des fichiers, de nouveau une convention de nommage des fichiers est la sanest approche. Dans mon cas, j'ai les noms de fichiers se terminant par .en.php, .ca.htm, etc. Mon incluent des appels alors ressembler à include("some-filename.$lang.php).
   • De temps en temps, vous serez en crachant des petits morceaux de texte directement à partir de votre code PHP (par exemple, lors de l'étiquetage de les en-têtes de tableau). Vous pouvez utiliser un include de fichier par langue de la définition d'un "morceaux" tableau avec les mêmes touches, ou une table DB comme Geert suggéré. La première approche prend moins de travail à développer, ce dernier devrait prendre moins de travail pour maintenir (surtout si vous ne travaillez pas seul).

3. Langue sélection: tout à fait essentielle, vous devez fournir à vos utilisateurs un moyen de choisir leur propre langue, autre que le fait de modifier les OBTENIR arguments sur l'URL elle-même. Pour les langues rares, "flags" souvent de l'excellent travail, car ils peuvent être compris, même si la page a d'abord tombé sur une langue de l'utilisateur ne connaît pas du tout. Pour plus de langues, un menu déroulant semble plus efficace (en termes de fenêtre d'affichage de l'espace), mais assurez-vous d'ajouter un peu de visuel (ie: non-textuel) conseils. Certains sites vous forcer à choisir une langue à l'entrée, et uniquement des liens vers la page d'accueil sur chaque langue. Personnellement, j'ai mes trois drapeaux debout sur le dessus de mon menu du site, chacun pointant vers l'adresse actuelle avec seulement la langue argument changé. Un code comme celui-ci peut très bien fonctionner:

---

function translatedURI($new_lang) {
    return str_replace("lang=$lang", "lang=$new_lang", "http://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];
}

---

1. CMS peaufinage: si votre site (ou une partie) est à l'aide de une sorte de CMS, forum de discussion, etc, les choses peuvent devenir assez salissant. En parlant de ma propre expérience, j'ai un forum phpBB sur mon site divisé en trois catégories principales (un par langue), de telle manière qu'ils ressemblent à trois forums indépendants (mais les utilisateurs ont juste besoin de se connecter ou de vous inscrire sur l'un d'eux pour accéder à toutes les langues, car ils sont en effet tout simplement les catégories de la même carte). Les réglages que j'avais à faire pour que cela fonctionne en douceur menacé les derniers vestiges de la folie je garde encore :S. Pour ces cas, je conseille à la recherche de la documentation et de prendre en charge des fonctionnalités du logiciel que vous utilisez.

Eh bien, c'est tout ce que je peux sortir avec pour l'instant. Je pense que vous devriez en avoir assez pour remonter vos manches et travailler. Alors, si vous frappez un mur sur votre chemin, revenir avec des questions précises et je suis sûre que vous aurez des réponses précises.

Espère que cette aide.

La solution que j'ai toujours utiliser est de créer une table de base de données, avec tous les messages possibles. Pour chaque message-je utiliser un code (abréviation) à le chercher. Ainsi, par exemple:

lang  id        message
en    login     Login
en    lostpass  Lost your password?
de    login     Anmelden
de    lostpass  Paswort vergessen?
nl    login     Aanmelden
nl    lostpass  Wachtwoord vergeten?

etc. Recherche de traductions est généralement assez rapide en utilisant une requête MySQL, mais vous pouvez également placer tous les messages dans un tableau et de le charger en mémoire lorsque votre script charge. Les utilisateurs devraient toujours être en mesure de définir la langue qu'ils préfèrent ne pas se fier aveuglément sur la langue de l'en-tête défini par le navigateur web.

Je suis actuellement la conception d'un très petit CMS qui doit être multilingue.

L'une des caractéristiques qui mosts préoccupations pour moi, c'est que le client peut spontanément décider d'ajouter ou supprimer une langue.

Pour cette raison, je ne suis pas en vue de la conception de l'ajout de suffixes pour les tables de base de données, je ne peux pas (et ne veux pas) pour modifier les noms de table ou d'y accéder à l'aide de dinamic noms, ni l'ajout ou la suppression de champs à chaque fois qu'une langue est définie ou supprimé.

Je ne voudrais pas utiliser les fichiers, juste parce que j'aime les bases de données et ils sont faciles à mantain.

Et enfin, je pense que dans deux types de traduction:

1. Le texte web.
2. Le contenu du texte.

Donc, mon design a pour objectif de:

• languajes Un tableau avec les langues définies.
• traductions Un seul tableau qui contiendra tous les messages, comme suit:
  • [pk] table_name le nom de la table dont le contenu sera traduit.
  • [pk] field_name le nom du champ dont le contenu sera traduit.
  • [pk] row_id la ligne identifiant de l'élément qui doit être traduit.
  • [pk] langue la langue dans laquelle le texte est traduit.
  • texte le texte traduit.

Qui signifie que les tables qui dans les champs contenus dans une seule langue, scénario, va maintenant avoir son contenu nul, parce qu'il sera toujours dans les traductions table.

Qui permettront d'accroître le sql des requêtes sur la complexité, mais il me permet de développer des outils pour maintenir les traductions dans un moyen facile. Aussi, la complexité de la sql existera qu'une seule fois, lors de la mise en œuvre de la solution. Si cette mise en œuvre est bien conçu, le maintien /l'extensibilité du site ne doit pas être un problème majeur.

Modifier:

Après quelques conversations avec des amis développeur, je pense que la solution je suis aproaching a ici trop de charge sur une seule table.

Une autre approche que je vais étudier à partir de maintenant est de créer une table supplémentaire pour chaque "traduisible table", comme suit:

• any_translatable_table: La table qui ont besoin de traduire l'un de ses champs
• any_translatable_table_translations: La table où les traductions seront stockées.
  • [pk] field_name le nom du champ dont le contenu sera traduit.
  • [pk] row_id la ligne identifiant de l'élément qui doit être traduit.
  • [pk] langue la langue dans laquelle le texte est traduit.
  • texte le texte traduit.

Ce schéma hérite les concepts de la première, mais la sépare du contenu par les tables. Cette solution alternative peut augmenter les performances et d'isoler les problèmes (comme des indices de problèmes).

La traduction supplémentaire d'une table par "traduisible table" sera créé en même temps que celui d'origine.

Et sur le sql des requêtes sur, la complexité est toujours le même: la première approche doit être le nom de la table à rechercher dans les traductions de la table, mais le deuxième, juste ajoute le suffixe "_translations" au nom de la table.