Ho pensato che fosse un bug interessante e sottile comportamento che non era solo difficile da rintracciare, ma difficile da definire. Non ero sicuro di 'di chi fosse la colpa.'
Ecco la storia. Sentiti libero di seguire e vedere cosa ottieni.
Stavo utilizzando Ubuntu 18.04 con WSL.
Ho creato un'app console utilizzando .NET Core 3.0. Puoi installare .NET Core qui http://dot.net/get-core3
Ho fatto questo:
dotnet new console
dotnet add package Humanizer --version 2.6.2
Quindi ha reso Program.cs simile a questo. Humanizer è un'ottima libreria .NET Standard che imparerai e penserai "perché .NET non ha sempre questo!?"
using System;
using Humanizer;
namespace dotnetlocaletest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(3501.ToWords());
}
}
}
Puoi vedere che voglio che l'app stampi il numero 3051 come parole. Presumibilmente in inglese, poiché è la mia lingua principale, ma noterai che non l'ho indicato qui. Facciamolo funzionare.
Nota che l'app funziona benissimo e come previsto in Windows.
scott@IRONHEART:~/dotnetlocaletest$ dotnet run
3501
Eh. Non ci ha nemmeno provato. È strano.
La mia macchina Windows è en-us (inglese negli Stati Uniti), ma qual è la mia macchina Ubuntu?
scott@IRONHEART:~/dotnetlocaletest$ locale
LANG=C.UTF-8
LANGUAGE=
Sembra che non sia niente. È "C.UTF-8" e non è niente. C in questo contesto indica la posizione predefinita POSIX. È il più elementare. C.UTF-8 NON è sicuramente lo stesso di en_US.utf8. È una specie di luogo, ma non è un posto.
Cosa succede se dico esplicitamente a .NET dove mi trovo?
static void Main(string[] args)
{
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Console.WriteLine(3501.ToWords());
}
Ed eseguirlo.
scott@IRONHEART:~/dotnetlocaletest$ dotnet run
three thousand five hundred and one
OK, quindi le cose funzionano bene se l'app dichiara "hey, sono en-US!" e Humanizer funziona bene.
Cosa c'è che non va? Sembra che "C.UTF-8" di Ubuntu non sia "invariante" abbastanza da far tornare Humanizer a un valore predefinito in inglese?
Sembra che altre persone abbiano riscontrato problemi insoliti o sottili con le installazioni di Ubuntu che utilizzano C.UTF-8 rispetto a una locale più specifica come en-US.UTF8.
Potrei risolvere questo problema in alcuni modi. Potrei impostare la locale in modo specifico in Ubuntu:
locale-gen en_US.UTF-8
update-locale LANG=en_US.UTF-8
Fortunatamente Humanizer 2.7.2 e versioni successive hanno risolto questo problema e si ripiega correttamente. Di chi era il "bug"? Difficile, ma in questo caso Humanizer aveva una logica di fallback imperfetta. Ho aggiornato alla 2.7.2 e ora C.UTF-8 torna a un inglese neutro.
Detto questo, penso che si possa sostenere che WSL/Canonical/Ubuntu dovrebbe rilevare la mia lingua locale e/o impostare la localizzazione su di essa durante l'installazione.
La lezione qui è che le tue applicazioni, specialmente quelle che dovrebbero funzionare in più locali in più lingue, ricevono "input" da molti luoghi diversi. Detto in modo diverso, non tutti gli input provengono dall'utente.
Le impostazioni locali e la lingua del sistema, l'ora, il fuso orario, le date sono tutti inseriti come contesto ambientale nell'applicazione. Assicurati di affermare le tue ipotesi su cosa sia "predefinito". In questo caso, la mia piccola app ha funzionato benissimo su en-US ma non su "C.UTF-8". Sono stato in grado di esplorare il comportamento e scoprire che esisteva sia una soluzione locale (potevo rilevare e impostare una locale predefinita, se necessario) sia una correzione della libreria disponibile.
Afferma le tue ipotesi!
Sponsor: Soffri di mancanza di chiarezza sui bug del software? Offri ai tuoi clienti l'esperienza che meritano e si aspettano con il monitoraggio degli errori di Raygun.com. Si installa in pochi minuti, provalo oggi!