Pensé que se trataba de un error interesante y sutil comportamiento que no solo era difícil de rastrear sino también difícil de precisar. No estaba seguro de "de quién fue la culpa".
Aquí está la historia. Siéntase libre de seguir y ver lo que obtiene.
Estaba ejecutando Ubuntu 18.04 bajo WSL.
Hice una aplicación de consola usando .NET Core 3.0. Puede instalar .NET Core aquí http://dot.net/get-core3
Hice esto:
dotnet new console
dotnet add package Humanizer --version 2.6.2
Luego hizo que Program.cs se viera así. Humanizer es una excelente biblioteca de .NET Standard sobre la que aprenderá y pensará "¿por qué .NET no siempre tuvo esto?"
using System;
using Humanizer;
namespace dotnetlocaletest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(3501.ToWords());
}
}
}
Puede ver que quiero que la aplicación imprima el número 3051 como palabras. Presumiblemente en inglés, ya que ese es mi idioma principal, pero notará que no lo he indicado aquí. Vamos a ejecutarlo.
Tenga en cuenta que esta aplicación funciona muy bien y como se esperaba en Windows.
scott@IRONHEART:~/dotnetlocaletest$ dotnet run
3501
Eh. Ni siquiera lo intentó. Eso es raro.
Mi máquina con Windows está en-us (inglés en los EE. UU.), pero ¿cuál es mi máquina con Ubuntu?
scott@IRONHEART:~/dotnetlocaletest$ locale
LANG=C.UTF-8
LANGUAGE=
Parece que no es nada. Es "C.UTF-8" y no es nada. C en este contexto significa la ubicación predeterminada de POSIX. Es el más básico. C.UTF-8 definitivamente NO es lo mismo que en_US.utf8. Es una especie de ubicación, pero no es un lugar.
¿Qué pasa si le digo a .NET explícitamente dónde estoy?
static void Main(string[] args)
{
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Console.WriteLine(3501.ToWords());
}
Y ejecutarlo.
scott@IRONHEART:~/dotnetlocaletest$ dotnet run
three thousand five hundred and one
De acuerdo, las cosas funcionan bien si la aplicación declara "¡hey, soy en-US!" y Humanizer funciona bien.
¿Qué ocurre? ¿Parece que el "C.UTF-8" de Ubuntu no es lo suficientemente "invariable" como para hacer que Humanizer vuelva al inglés predeterminado?
Parece que otras personas han visto problemas inusuales o sutiles con las instalaciones de Ubuntu que usan C.UTF-8 en comparación con una configuración regional más específica como en-US.UTF8.
Podría arreglar esto de varias maneras. Podría establecer la configuración regional específicamente en Ubuntu:
locale-gen en_US.UTF-8
update-locale LANG=en_US.UTF-8
Afortunadamente, Humanizer 2.7.2 y versiones posteriores solucionaron este problema y retroceden correctamente. ¿De quién era el "bicho"? Difícil, pero en este caso, Humanizer tenía una lógica alternativa defectuosa. Actualicé a 2.7.2 y ahora C.UTF-8 vuelve a un inglés neutral.
Dicho esto, creo que se podría argumentar que WSL/Canonical/Ubuntu debería detectar mi idioma local y/o configurarlo en la instalación.
La lección aquí es que sus aplicaciones, especialmente aquellas que se espera que funcionen en múltiples lugares en múltiples idiomas, toman "entradas" de muchos lugares diferentes. Expresado de otra manera, no todas las entradas provienen del usuario.
La configuración regional y el idioma del sistema, la hora, la zona horaria y las fechas se ingresan como contexto ambiental para su aplicación. Asegúrese de hacer valer sus suposiciones sobre lo que es "predeterminado". En este caso, mi pequeña aplicación funcionó muy bien en en-US pero no en "C.UTF-8". Pude explorar el comportamiento y descubrí que había una solución alternativa local (podía detectar y establecer una configuración regional predeterminada si era necesario) y también había una solución de biblioteca disponible.
¡Afirme sus suposiciones!
Patrocinador: ¿Sufre de falta de claridad en torno a los errores de software? Ofrezca a sus clientes la experiencia que merecen y esperan con el control de errores de Raygun.com. Se instala en minutos, ¡pruébalo hoy!