Imaginez un site disponible en plusieurs langues. La langue est détectée automatiquement en regardant l'IP ou l'en-tête du navigateur. Mais ce n'est pas à l'épreuve des balles, donc quelques utilisateurs peuvent se retrouver sur une page dans une langue qu'ils ne comprennent pas.
Je me demande quelle est la meilleure façon de présenter la sélection de langue?
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Q: Les langues de la sélection de langues doivent-elles être répertoriées
N'hésitez pas à ajouter si j'ai raté quelque chose!
L'option 2 est la meilleure option, car vous reconnaîtrez votre propre langue indépendamment de votre connaissance des autres langues (assurez-vous également de fournir des jeux de caractères si vous supportez par exemple le japonais)
Problèmes avec les options 1 et
Option 1. Si vous ne parlez/comprenez pas la langue actuelle, vous ne reconnaîtrez peut-être pas votre propre langue. Dans l'exemple, les Allemands auraient le plus de difficultés.
Option 3. L'anglais est le plus facile à mettre en œuvre car, comme vous le mentionnez, la plupart des gens comprendront l'anglais. Cependant, si votre site Web propose des traductions, vous vous attendez probablement à des visiteurs ayant de faibles compétences en anglais.
Vous pouvez également créer une liste déroulante avec une combinaison de la liste des options 2 et 3. Par exemple. Allemand/allemand
L'option 2 est la voie à suivre comme vous devriez toujours montrer les langues listées par la façon dont elles sont écrites dans cette langue. C'est la façon dont Wikipédia et la plupart des entreprises qui traitent dans de nombreuses langues le font. Voici comment Apple gérer cela:
Problèmes avec les autres options
L'option 1 est un casse-tête à maintenir car vous devez avoir le nom de chaque langue dans toutes les autres langues. Cela n'aide pas non plus quelqu'un à trouver sa langue, car il doit d'abord essayer de traduire le nom de sa langue dans la langue d'une autre langue qu'il ne parle peut-être même pas.
Disons que vous étiez en Chine et que la langue du site était le chinois. Dans quelle mesure cette liste vous serait-elle utile?
C'est une liste de noms de langues écrites en chinois, que vous ne saviez probablement même pas. Cela illustre simplement pourquoi vous ne devriez pas envisager l'option 1.
L'option 3 n'est qu'une version en anglais de l'option 1 et doit être évitée pour les mêmes raisons. L'anglais pour une personne chinoise est le même que le chinois pour une personne anglaise.
L'option 2 est la meilleure, car l'utilisateur peut toujours reconnaître sa propre langue.
Il y a cependant un petit piège. Si vous présentez le sélecteur de langue sous forme de liste déroulante, l'utilisateur ne verra aucune valeur à l'exception de la langue actuelle détectée automatiquement, sauf s'il clique dessus. Et si l'utilisateur ne comprend pas la langue actuellement sélectionnée - par exemple, le chinois déjà mentionné, il ne remarquera peut-être même pas que vous avez un sélecteur de langue!
Par conséquent, vous devrez soit avoir une liste de langues non déroulante clairement visible si vous avez suffisamment d'espace libre sur une barre latérale, un écran de démarrage "confirmer la langue détectée automatiquement" ou, si vous choisissez toujours d'utiliser la liste déroulante, une légende universellement comprise près de il (la "langue" anglaise semble être la moins mauvaise, la plupart des gens devraient reconnaître au moins ce monde même si leur anglais est autrement mauvais).
Mon vote va pour l'option # 2. Si vous cherchez à changer la langue parce que vous ne comprenez pas quelle que soit la valeur par défaut, il sera beaucoup plus efficace de voir les choix dans une langue que vous comprenez. C'est un peu le point, non?
J'ai également croisé cet article de 456 Berea Street où l'auteur préfère une combinaison de vos options 1 et 2, (bien qu'il/elle ne précise pas vraiment pourquoi).
Le nom de la langue sous forme de texte dans la langue elle-même, éventuellement suivi du nom de la langue dans la langue de la page en cours.
La seule option valide est # 2, car c'est la seule qui garantit qu'un visiteur va reconnaître un nom de langue.
Dans les deux autres scénarios, vous supposez que le visiteur va comprendre une deuxième langue, et c'est une grande hypothèse.
L'option 2 est certainement la meilleure solution. Pas de drapeaux, s'il vous plaît!
Je suis un locuteur natif tchèque. Je travaille en anglais et comprends essentiellement plusieurs langues différentes. Je faisais la localisation de l'anglais vers le tchèque (y compris les polices de caractères) depuis 1993. Cela signifie que je suis un geek total, mais depuis que je suis enfant, j'essaie de me concentrer sur mon expérience (lire: utilisateur).
Empruntez le téléphone portable de quelqu'un, changez-le en chinois et laissez-le le réparer. S'il réussit, l'UX est correct.
Une chose à retenir est que les langues peuvent être communes à tous les pays mais peuvent être parlées différemment. Par exemple, l'espagnol en Espagne sera un peu différent de l'espagnol parlé au Mexique. Une manière recommandée de gérer cela serait de suivre l'approche de Microsoft qui permet à l'utilisateur de sélectionner la langue en fonction du pays et de la langue de ce pays.
Cela dit, je recommanderais d'aller avec l'option 2 car cela permet à l'utilisateur de déterminer la langue dans laquelle il veut traduire et peut également s'associer rapidement à la traduction de la langue.
Question interessante.
La voie à suivre est: native.
Ainsi, une personne ne parlant que le chinois - il y en a des millions - peut choisir le chinois. Ce n'est pas possible si vous écrivez uniquement "chinois".
Voici le choix Apple fait: la première boîte de dialogue sous Mac OS X .
Voici comment l'ONU nous accueille: www.un.org .
C'est sympa quand on a des éléments en caractères non latins dans la liste des langues, ça rend le site cosmopolite. J'aime voir des personnages exotiques, ça me donne une bonne impression du site. De plus, lorsque la liste des langues contient des éléments en caractères non latins, cette liste a un rôle d'interface utilisateur: elle attire mon regard, et quand je veux changer de langue, je sais instantanément que c'est l'endroit où aller, sans lire.
Il est très important de comprendre les besoins réels de vos utilisateurs réels. Par exemple, l'hypothèse selon laquelle "les gens reconnaîtront leur propre langue" peut ne pas être vraie - j'ai trouvé des cas où un utilisateur proxy est impliqué, fournissant une assistance aux personnes ayant une alphabétisation limitée en anglais et dans leur langue maternelle. Dans une telle situation, des étiquettes doubles - en anglais et dans la langue maternelle - sont nécessaires.
Dans l'ensemble, il y a tellement de facteurs pratiques et culturels en jeu que vous DEVEZ tester avec des utilisateurs correctement représentatifs pour valider et affiner votre conception. Ne cherchez pas ici des principes abstraits ou une formule magique de "meilleures pratiques" - voyez ce qui fonctionne réellement.
J'aime la façon dont Wiki l'a fait. Ils utilisent le nom natif de la langue, également par ordre alphabétique. L'ordre alphabétique étant dynamique, la liste changera en fonction de la langue utilisée. Par exemple en anglais c'est ABC et en russe son А В (ABV) donc la liste des langues changera respectivement.
Je préfère cette façon parce que c'est facile de trouver une langue, plus facile de repérer les caractères russes, aussi en utilisant l'ordre alphabétique dynamique, je n'ai pas à basculer, mon cerveau, entre le russe et l'anglais.
Quoi qu'il en soit, même si ce que les autres ont répondu est bon, cela ne donne pas une vue d'ensemble. Je vais vous donner ce que je pense être la réponse IDÉALE.
Fondamentalement, cette réponse fournit PLUSIEURS indices (plutôt qu'un simple indice) pour la sélection de la langue.
d'abord est le nom de la langue, (selon les réponses ci-dessus), car il fournit une interface de base pour toute personne alphabétisée en anglais.
Second est le nom de la langue dans son propre script natif, pour une personne alphabétisée de base en langue maternelle. par exemple.
Troisième est un drapeau pour le pays. Pour les langues parlées dans les dialectes et les pays courants, on peut utiliser le pays d'origine ou le pays de parole. Par exemple. ANGLAIS (devrait avoir le drapeau britannique), ANGLAIS ROYAUME-UNI, ANGLAIS US (devrait avoir le drapeau de leur pays respectif). Un indice visuel contournant la partie pensante du cerveau.
Ci-dessous, une mauvaise capture d'écran d'un tel exemple, tirée du site Web http://blog.myheritage.com/2009/06/small-changes-big-differences-new-header-and-footer/
De nombreuses applications que j'ai vues l'ont implémenté correctement, et j'invite les autres à suivre cela.
Certaines autres fonctionnalités requises sont le filtrage rapide des langues affichées par le clavier, comme ce que listary fait pour les listes, pour affiner les résultats. Comme si vous recherchez spécifiquement l'anglais (Singapour).
De plus, l'emplacement du sélecteur de langue est très important. Il devrait être idéalement situé au-dessus du pli (c'est-à-dire sur la première page elle-même) quelque part. La pratique générale est le coin supérieur droit, en dessous des informations de profil que vous pourriez avoir. IT IS UN MUST pour les nouveaux visiteurs, il peut être caché pour les visiteurs réguliers (c'est-à-dire que le site est déjà dans leur langue préférée) et accessible via le deuxième emplacement. Le deuxième emplacement commun est au bas de la page, centré ou aligné à gauche. Bien que je pense qu'il devrait toujours être disponible à première vue. Il en va de même pour les applications.
Ahhh c'est une bête noire! Par exemple, voir Chrome! (Je sais que c'est une application, mais supportez-moi) Il a le plus horrible UX pour changer la langue en anglais d'une langue inconnue pour l'utilisateur. Cela nécessite une quantité excessive de clics et une confusion totale !!
Quelques liens intéressants que j'ai trouvés avec des opinions contraires et d'autres ressources utiles. http://flagsarenotlanguages.com/blog/best-practice-for-presenting-languages/http://commons.wikimedia.org/wiki/Linguistic_flagshttp://commons.wikimedia.org/wiki/Category:Flags_of_languages
Semblable à la réponse de Vijay, l'utilisation d'un drapeau pour indiquer le pays d'origine de la langue est facile à interpréter. Vous n'avez pas besoin d'indiquer le nom anglais de la langue, sauf s'il s'agit de l'anglais - utilisez le nom natif uniquement dans tous les cas. Je l'ai vu utilisé à plusieurs reprises, y compris dans des manuels d'utilisation écrits. Je suis Canadien et j'ai souvent acheté des produits avec des instructions dans plusieurs langues différentes. Devinez combien de fois j'ai vu un drapeau canadien pour les instructions que j'ai pu lire? Jamais. Malgré cela, je n'ai jamais eu de difficulté à comprendre que le drapeau britannique était pour les instructions en anglais.
Nous travaillons avec des systèmes embarqués où l'espace est toujours très limité. Pour cette raison, nous utilisons la 2e option dans le script natif.
D'après mon expérience, les gens ont tendance à sauter des lignes qui ne savent pas lire.
Un avantage de cela par rapport à la solution de Vijay est que les utilisateurs n'ont pas besoin de chercher/rechercher la langue entre les lignes qu'ils ne peuvent pas lire. L'utilisateur doit analyser chaque ligne pour voir si un script natif est disponible car toutes les lignes commencent dans le script du site avec le script natif derrière.
En utilisant uniquement le script natif, l'utilisateur ne "verra" vraiment que les lignes de son propre script. ainsi un Chinois ne "verra" vraiment que les 2 lignes de son propre script et sautera tout le reste.