Mesure par défaut, "métrique" ou "impérial"?
Le public est un mélange européen et américain. Quelle est la norme dans ce cas, métrique ou impérial?
Je permettrai aux utilisateurs de changer.
S'il s'agit d'une application de bureau, vous pourrez récupérer les paramètres des unités dans le système d'exploitation. Ceux-ci sont définis au moment de l'installation, donc ne nécessitent aucune interaction de l'utilisateur, ce qui est parfait.
S'il s'agit d'une application Web, vous pouvez obtenir les informations sur la langue à partir de l'en-tête d'acceptation de la langue qui vous indiquera généralement le pays ainsi que la langue. Par exemple, un en-tête de langue avec en/US indiquerait clairement américain. Je ne sais pas si un Américain hispanophone apparaîtra comme es/US, mais j'imagine qu'ils le pourraient. Donc, vous voudrez peut-être accepter tout ce qui se termine par/US comme indiquant américain. À peu près tout le reste serait métrique. (Le Royaume-Uni est un cas spécial, où la jeune génération (<40 ans) utilise la métrique, mais les plus anciennes utilisent l'impérial (> 50). J'irais avec la métrique à moins que ce ne soit une application de cartographie, auquel cas j'irais impérial! ).
La plupart du temps, celles-ci vous donneront une réponse précise, mais vous constaterez parfois que vous ne pouvez pas obtenir d'informations significatives, auquel cas je choisirais par défaut la fraction la plus importante de votre audience. La logique ici est qu'en choisissant le plus grand public, vous ennuyez le moins de gens.
Mais si votre public est à peu près de la même taille et que vous avez une marque qui est fortement associée aux États-Unis ou à l'Europe, choisissez la norme. La logique ici est que les Américains seront moins surpris de voir des compteurs dans l'interface s'ils perçoivent votre entreprise comme européenne, et vice versa. De toute évidence, le commutateur que vous ajoutez est important.
Ces deux solutions de rechange ne devraient généralement pas être nécessaires, les paramètres régionaux devraient être disponibles dans presque tous les cas. S'il s'agit d'une application Web, vous souhaiterez peut-être enregistrer les paramètres régionaux pendant un certain temps pour le vérifier.
S'il s'agit d'une webapp, essayez de détecter les paramètres régionaux. Si une solution n'existe pas, j'essaierais de détecter l'emplacement de l'utilisateur et de le baser sur cela. (API de géolocalisation)
S'il s'agit d'une application de bureau, Peter a raison: récupérez-la dans les préférences du système d'exploitation.
Cependant, si c'est une webapp, ne dépend pas de la langue.
Dépendez plutôt des solutions GeoIP.
Alors que l'API de géolocalisation serait assez lourde et peu fiable sur un navigateur de bureau, interrompant également le flux d'utilisateurs ("Cette application veut connaître votre emplacement. Autoriser/Refuser?"), GeoIP est très bien.
Les adresses IP sont désespérément inadéquates pour obtenir des informations de localisation réelles, mais elles sont attribuées par continent, donc pour cela, c'est sûr.
En ce qui concerne l'itinérance (utilisateurs américains voyageant à l'étranger), les cartes iOS passent en yards et en miles si je vais au Royaume-Uni (même les cartes à l'ancienne). Dans certains cas, cela est bénéfique, car les panneaux de signalisation seront en miles, et les habitants parleront de yards, pour moi, c'est dérangeant car je n'ai pas d'idée solide sur ce que signifie un `` yard '', je suis un Européen continental.
Je prendrais le premier paramètre de l'IP, le stocke dans un cookie, et si l'utilisateur modifie ce paramètre à tout moment plus tard, le stocke également dans un cookie: de cette façon, l'unité est ressentie comme "persistante", car elle n'est modifiée que à la demande des utilisateurs - si un résident américain voyageant à l'étranger passe à la métrique et oublie de revenir à la maison impériale, je suppose qu'il en connaîtra la raison.