Question très basique. Dans app.yml, j’ai fi comme locale par défaut. Mais fait-il plus que de simplement définir des valeurs par défaut pour tout et tout le monde ?
Et si oui, un utilisateur verra-t-il tout dans cette langue par défaut, maintenant fi, jusqu’à ce que Allow user locale soit modifié ?
Mais qu’en est-il de Set locale from accept language header ? Si quelqu’un a en_US, alors la version anglaise est proposée ? Et cela signifie-t-il que la locale par défaut n’est qu’une suggestion et sera remplacée si Accept-Language est autre chose ?
Et la raison pour laquelle je pose cette question est mon nouveau site, qui est fortement ciblé sur les États-Unis, et il a besoin d’un forum. Mais je ne pense pas qu’il attire suffisamment l’attention pour que cela vaille la peine de faire tout le travail que demande le lancement d’un forum. J’envisageais donc une solution où je dirigerais ces visiteurs américains/mondiaux vers une catégorie spécialement conçue à cet effet.
Mais mon forum est par ailleurs entièrement en finnois, et si Accept-Language ne change pas la locale par défaut, cela ne fonctionnera pas.
(Et en partie, j’espère que le traducteur fonctionnera un jour ).
Je sais que ce n’est pas une question de support légitime, mais j’essaie d’éviter le général…
Ce n’est pas quelque chose que je connais très bien, mais en l’absence d’autres réponses jusqu’à présent…
Je pense que l’ajout de la locale par défaut à votre app.yml remplace tout ce que vous avez défini pour default locale dans les paramètres de votre site (et le supprime également de la page des paramètres). Mais ce ne serait que la valeur par défaut, et vous pouvez laisser les gens choisir (ou laisser leur navigateur choisir) une alternative plus appropriée pour eux.
J’espère que c’est pertinent, sinon cela peut juste servir à remonter le sujet pour voir si nous pouvons obtenir une réponse plus éclairée.
Il existe deux branches de logique dans ApplicationController#with_resolved_locale : les utilisateurs connectés et les utilisateurs déconnectés.
Les utilisateurs déconnectés (1) définissent la locale à partir de la requête, puis (2) utilisent le paramètre du site ‘locale par défaut’ si aucune n’a été détectée.
La priorité est donnée à ?lang= dans l’URL, puis au cookie locale, puis à Accept-Language si chaque paramètre de site respectif est activé.
La logique pour les utilisateurs connectés est plus simple : préférence de l’utilisateur, puis ‘locale par défaut’ si la préférence de l’utilisateur est interdite.
Dans tous les cas, si la locale résolue a été déchargée du serveur Discourse, en est utilisé. (Cela se déclenche principalement lors des tests unitaires et d’intégration, si je me souviens bien.)
locale = SiteSettings::DefaultsProvider::DEFAULT_LOCALE if !I18n.locale_available?(locale)
Donc, en résumé, ce que cela fait :
C’est la langue pour les requêtes anonymes sans en-tête Accept-Language.
Y compris, en particulier, le processus d’inscription de compte.
C’est la langue qui sera toujours utilisée si vous n’avez pas permis aux utilisateurs de choisir leur propre langue, ou si l’utilisateur n’a pas défini de locale préférée.
).
