Locale et langue de l'interface utilisateur

Suite à la discussion de Business Week Day :

Comme je l’ai mentionné dans le post lié, la locale n’est pas exactement la même chose que la langue de l’interface utilisateur.

Je prendrai KDE (Linux et Qt) comme exemple ici :

Comme on le voit, dans la première capture d’écran, on peut sélectionner la langue de l’interface. Celle-ci définit, bien sûr, la langue de l’interface et tout ce que vous voyez à l’écran, sauf ce qui est montré dans la deuxième capture.
La deuxième capture permet de définir la locale de l’utilisateur et de remplacer les nombres, l’heure, la monnaie, les unités et le tri.
Ceci est important car beaucoup utilisent le système dans leur langue préférée, mais vivent dans un pays différent où ils ont des préférences de locale différentes.

Je prendrai des exemples de ma région, la région arabe :

Par conséquent, les dates sont affectées par ces différences :

  • Tous les pays écrivent de droite à gauche.
  • Pays du Machrek : ⁨١٢ يناير ٢٠٢٠⁩ = 12 janvier 2020 (Lu de droite à gauche)
  • Pays du Maghreb : ⁨12 جانفي 2020⁩ = 12 janvier 2020 (Lu de droite à gauche)
  • Pour faire simple : qu’il s’agisse de chiffres orientaux ou occidentaux/arabes, l’écriture se fait de droite à gauche, ce qui rend encore plus difficile de décider des chiffres, sans parler du format.

Même le séparateur de milliers est différent :


(Les chiffres arabes orientaux ont également un autre séparateur : ١٠٬٠٠٠٫٠٠ : image )

Comment cela affecte Discourse :

  • Formats de date et d’heure, nombres, début de la semaine de travail.

Ce qui n’est pas affecté :

  • Dates relatives.

Solutions idéales :

  • Extraire et intégrer les formats Unicode et permettre à l’utilisateur de sélectionner n’importe quelle locale qu’il souhaite. Cela nécessite réflexion car cela pourrait entrer en conflit avec Moment.JS.
  • Fournir tous les moyens et méthodes pour que les traducteurs puissent sélectionner quel format afficher où dans le logiciel.
3 « J'aime »

Il n’est pas prévu de scinder le système de locale actuel en locale et langue de l’interface utilisateur dans un proche avenir. Cependant, je suis d’accord, ce serait une bonne chose à faire.

Quoi qu’il en soit, je pense que le système actuel peut déjà être utilisé pour créer des locales spécifiques à une région. Nous avons client.en_US.yml et server.en_US.yml qui remplacent les formats de date/heure, les nombres, etc.

Je suis certain qu’une chose similaire pourrait être faite pour l’arabe. Il devrait même être possible de le faire avec un plugin.

2 « J'aime »