Idioma de localización e idioma de la interfaz de usuario

Continuando la discusión desde Business Week Day:

Como mencioné en la publicación vinculada, la configuración regional (locale) no es exactamente lo mismo que el idioma de la interfaz de usuario.

Tomaré KDE (Linux y Qt) como ejemplo aquí:

Como podemos ver, en la primera captura de pantalla se puede seleccionar el idioma de la interfaz. Esto, bueno, define el idioma de la interfaz y todo lo que se ve en la pantalla, excepto lo que se muestra en la segunda captura.
La segunda captura permite definir la configuración regional del usuario y anular los formatos de números, hora, moneda, unidades y ordenamiento.
Esto es importante porque muchos utilizan el sistema en su idioma preferido, pero viven en un país diferente donde tienen preferencias distintas para la configuración regional.

Tomaré ejemplos de mi región, la región árabe:

Por lo tanto, las fechas se ven afectadas por estas diferencias:

  • Todos los países escriben de derecha a izquierda.
  • Países del Mashriq: ⁨١٢ يناير ٢٠٢٠⁩ = 12 de enero de 2020 (Lectura de derecha a izquierda)
  • Países del Magreb: ⁨12 جانفي 2020⁩ = 12 de enero de 2020 (Lectura de derecha a izquierda)
  • En resumen: ya sean numerales orientales o árabes occidentales, se escriben de derecha a izquierda, lo que hace aún más difícil decidir sobre los números, por no hablar del formato.

Incluso el separador de miles es diferente:


(Los numerales árabes orientales también tienen otro separador: ١٠٬٠٠٠٫٠٠: image )

Cómo afecta a Discourse:

  • Formatos de fecha y hora, números, inicio de la semana laboral.

Qué no se ve afectado:

  • Fechas relativas.

Soluciones ideales:

  • Extraer e integrar los formatos Unicode y permitir que el usuario seleccione cualquier configuración regional que desee. Esto requiere reflexión, ya que podría entrar en conflicto con Moment.JS.
  • Proporcionar todos los medios y métodos para que los traductores seleccionen qué formato mostrar y dónde en el software.
3 Me gusta

No hay planes para dividir el sistema de locales actual en ‘locale’ e ‘idioma de la interfaz’ en un futuro próximo. Sin embargo, estoy de acuerdo en que sería una buena medida.

En cualquier caso, creo que el sistema actual ya puede utilizarse para crear locales específicos por región. Tenemos client.en_US.yml y server.en_US.yml, que anulan formatos de fecha/hora, números, etc.

Estoy seguro de que se podría hacer algo similar para el árabe. Incluso debería ser posible hacerlo mediante un plugin.

2 Me gusta