scénario
Le serveur Web reçoit une demande de Maintenant, nous pourrions faire l'une des opérations suivantes avec l'URL:
Lequel est le meilleur? Avantages, contre un point de vue de l'utilisateur? perspective de développeur? http:/domain.com/folder/page . L'en-tête accepter la langue nous dit que l'utilisateur préfère le grec, avec le code de langue el . C'est bien, puisque nous avons une version grecque de page .
http:/domain.com/folder/page
http:/domain.com/folder/page/el
http:/domain.com/el/folder/page
http://el.domain.com/folder/page
http:/domain.com/folder/page?hl=el
9 Réponses :
Je préfère 3 ou 4
numéro quatre est la meilleure option, car elle spécifie le code de langue assez tôt. Si vous allez fournir aux redirections, assurez-vous toujours d'utiliser une balise de liaison canonique.
Je n'irais pas pour l'option 1, si vos pages sont disponibles publiquement, c'est-à-dire que vous n'êtes pas obligé de vous connecter pour afficher les pages. La raison en est qu'un moteur de recherche ne scannera pas les différentes versions de langue de la page. La même raison va à nouveau l'option no 5. Un moteur de recherche est moins susceptible d'identifier deux pages comme des pages distinctes, si l'identification de la langue va dans la chaîne de requête.
laisse examiner l'option 4, plaçant la langue du nom d'hôte. J'utiliserais cette option si les différentes versions de langue du site contiennent du contenu complètement différent. Sur un site comme Wikipedia, par exemple, la version grecque contient son propre ensemble d'articles complet et la version anglaise contient un autre ensemble d'articles.
Donc, si vous n'avez pas de contenu complètement différent (ce qu'il n'a pas 'T semble de votre message), vous êtes laissé avec option 2 ou 3. Je ne sais pas s'il y a des arguments convaincants pour l'un sur l'autre, mais non. 3 a l'air plus agréable dans mes yeux. C'est donc ce que j'utiliserais.
mais juste un commentaire d'inspiration. Je travaille actuellement sur une application Web comportant 3 parties majeures, un public et deux parties pour deux types d'utilisateurs différents. J'ai choisi le schéma d'URL suivant (avec en faisant référence à la langue bien sûr): La raison en est que si je devais diviser les trois parties en applications distinctes Ce sera une simple reconfiguration dans le serveur Web lorsque j'ai le nom de la pièce en haut du chemin. Par exemple. Si nous devions utiliser un système commercial CMS pour la partie publique du site EDIT:
Un autre argument contre l'option no. 1 Est-ce que si vous n'écoutez que l'acceptation de langue, vous ne donnez pas à l'utilisateur un choix. L'utilisateur peut ne pas savoir comment modifier la langue configurée dans un navigateur ou utiliser une configuration d'ordinateur de poing sur une langue différente. Vous devez au moins donner à l'utilisateur un choix (le stocker dans un cookie ou le profil de l'utilisateur)
Ma question est censée être indépendante de la manière dont l'utilisateur sélectionne la langue en cliquant sur un lien ou en modifiant la langue du navigateur.
À propos du numéro 2, cela ne serait pas une URL étrange: ... / dossier / page? Par1 = x & Par2 = y / el . Cela fonctionnerait-il même?
... / Dossier / page? Par1 = x & Par2 = Y / el - Je ne vois pas pourquoi vous ne devriez pas être capable de le faire fonctionner. En ce qui concerne s'il a l'air étrange, les gens tapent rarement dans une URL complète, et ce n'est pas vraiment nécessaire qu'une URL soit agréable à l'œil. Mais il n'est pas idéal pour les optimisations des moteurs de recherche, donc si le contenu se trouve sur les moteurs de recherche, je recommanderais l'une des autres approches. Mais si le référencement n'est pas une préoccupation, et il est plus facile pour vous de mettre en œuvre, j'irais pour cela. Rappelez-vous simplement que la modification d'une URL après une fonctionnalité est lancée va briser les signets de personnes.
Je suppose que cela pourrait fonctionner techniquement. Mais alors pourquoi n'aurais-je pas ajouter un autre paramètre au lieu d'une barre oblique étrange et d'un nom de dossier?
Je pense que j'ai mal compris votre première question. Si vous écrivez ... / dossier / page? Par1 = x & Par2 = y / el puis y / el sera un autre paramètre de requête, c'est-à-dire que la valeur de Par2 sera simplement "y / el" que je suppose n'est pas ce que tu veux .
Mon choix est # 3: http://domain.com/el/folder/page . Il semble être le plus populaire sur le Web. Toutes les autres alternatives ont des problèmes:
http://domain.com/folder/page --- mauvais pour le référencement?
http:/domain.com/folder/page/el --- ne fonctionne pas pour les pages avec des paramètres. Cela a l'air bizarre: ... page? Par1 = x & Par2 = y / el
http://domain.com/el/folder/page - - semble bon!
http://el.domain.com/folder/page --- Plus de travail nécessaire pour déployer puisqu'il nécessite d'ajouter des sous-domaines.
http://domain.com/folder/page?hl=el --- mauvais pour le référencement?
Pourriez-vous élaborer votre explication de la deuxième URL, s'il vous plaît.
Je pense que vous seriez plus apte à interroger avec page / el? Par1 = x & par2 = y . C'est beaucoup plus facile à travailler avec.
Pick Option 5, et je ne crois pas que ce soit mauvais pour le référencement.
Cette option est bonne car elle montre que le contenu de Dire: Les problèmes de référencement peuvent être traités en créant des fichiers d'index pour tout comme Stackoverflow, celles-ci pourraient inclure plusieurs ensembles d'indices pour les différentes langues, encourageant, espérons-le, encourager l'apparition de résultats pour la langue non par défaut.
L'utilisation de 1 enlève la différentialité de l'URL. L'utilisation de 2 et 3 suggère que la page est différente, éventuellement au-delà de la langue, comme Wikipedia. Et l'utilisation de 4 suggère que le serveur lui-même est séparé, peut-être même géographiquement.
Parce qu'il existe une corrélation étonnamment médiocre de l'emplacement géographique aux préférences linguistiques, la question de la fourniture de serveurs de fermeture géographiquement doit être laissée à une configuration CDN appropriée.
http://domain.com/about/corporate/locations est identique au contenu de
http://domain.com/about/corporate/locations?hl=el sauf que la langue diffère.
Le paramètre hl doit remplacer l'en-tête Accepter-langue de sorte que l'utilisateur puisse facilement contrôler la matière. L'en-tête ne serait utilisé que lorsque le paramètre hl est manquant. La liaison accordée est un peu compliquée par cela, et devrait probablement être traitée par un cookie qui garderait la redirection à la langue choisie par le paramètre hl (car il a peut-être été modifié par l'utilisateur de l'utilisateur de Le paramètre LANGUE LANGUE ACCEPT-LANGUE OR / CODE> Pour l'ajout sur le paramètre actuel hl .
Cela dépend. Je choisirais le numéro quatre personnellement, mais de nombreuses entreprises prospères ont différentes façons de l'atteindre.
C'est vraiment à vous. Que pensez-vous que vos clients aimeront le plus?
Je choisirais Alternativement, vous pouvez aller pour Number 5 : C'est bien pour Google et vos amis, mais pas aussi agréable pour un utilisateur.
Aussi, nous devrions nous abstenir de rediriger un utilisateur n'importe où, sauf si nécessaire. Ainsi, dans mon esprit, une ouverture de l'utilisateur http://example.com/el/folder/page , car:
http://example.com/el/ , chaque visiteur local arrivera à un site en Grèce et éviterait la frustration de choix de langues.
http://example.com/folder/page ne doit pas obtenir de redirection, mais une page dans une langue par défaut.
Dans votre dernier paragraphe, il semble que vous préfériez le numéro d'alternatif 1?
Je ne pense pas qu'il soit, juste que l'URL par défaut devrait livrer en langage par défaut.
aucun d'entre eux. Un «utilisateur normal» ne comprendrait pas (et si vous souvenez) de ces abréviations.
Par ordre de préférence, je suggère:
Je ne m'attendrais pas à ce qu'un utilisateur se souvienne d'eux puisque je redirierais de domain.com à l'URL spécifique de la langue.
Dans ce cas, option 2, n'ayez rien affiché que l'utilisateur n'a pas besoin de voir.
Juste mes deux cents, de la propre expérience affichant que rien ne peut être une vraie douleur sur certains sites Web. En particulier, les sites Web qui vous redirigent vers la page d'accueil lorsque vous changez de langue. Ensuite, vous devez réessayer pour retrouver votre page, ce qui n'est pas toujours facile si vous venez d'un lien externe. Ainsi, si je peux, j'aime pouvoir changer l'URL. Le cas d'utilisation générique pour cela est, en particulier sur «Sites gouvernementaux» si je souhaite envoyer l'URL à un ami qui ne comprend pas la page Language.Ok, son cas d'utilisation particulière et est dû au comportement de la langue de changement de merde.
3 ou 4.
3: Peut être facilement traité avec l'utilisation de HTACCESS / MOD_REWRITE. Le seul inconvénient est que vous devez écrire une méthode d'injection automatique du code de langue comme premier segment de l'URI.
4: Probablement la meilleure méthode. Utilisation des en-têtes d'hôtes, il peut tous être envoyé à la même application Web / au même contenu, mais vous pouvez ensuite utiliser le code pour extraire le code de langue et passer de là.
Simples. ;)
Voir aussi Stackoverflow.com/Questtions/449010
6. Rediriger vers
http:/domain.com/folder/page.el (Mod_negotiation Nom de fichier Style)Soyez prudent de faire confiance à l'en-tête de la langue acceptée. Il existe un énormément d'utilisateurs qui ne prendront pas gentiment à une hypothèse automatique sur leur langue basée sur cet en-tête. Assurez-vous et fournissez un moyen évident de sélectionner la langue appropriée sur chaque page si la langue détectée est fausse.
Voir aussi Stackoverflow.com/questions/1828317/...