E' tutto il giorno che sto lavorando a localizzare un calendario e ne ho scoperte alcune di veramente divertenti
La prima:
Dato il seguente pezzettino di codice
CultureInfo ci = new CultureInfo(..LanguageString..);
for(int i=0; i<ci.DateTimeFormat.AbbreviatedMonthNames.Length-1; i++)
Console.WriteLine(ci.DateTimeFormat.AbbreviatedMonthNames[i].ToString());
Cosa vi aspettereste per i nomi corti? Gen, Dec, ecc.ecc.
Bene, funziona tutto tranne per la lingua cs-CZ (di quelle che ho provato, ma ovviamente abbiamo un cliente in repubblica ceca e quindi è fondamentale che vada bene) in cui stampa I, II, III, IV, V...
Dato che sto lavorando con dei cechi di fianco a me ho appena chiesto e vi posso garantire che anche in repubblica ceca i mesi hanno un nome e non sono chiamati con dei numeri.
L'altra invece è molto ma molto più subdola. Il pezzo di codice che localizza il calendario viene scritto da un file .aspx che genera dinamicamente le variabili localizzate. Bene, funziona benissimo per tutte le lingue tranne che per quelle in cui ci vuole la codifica utf-8 (ceco per l'appunto o russo e così via).
La cosa subdola è che se faccio leggere al tag <script> un file .js "statico" (salvato in utf-8 e referenziato come .js) funziona perfettamente, se invece del .js gli faccio leggere un file .aspx che genera la localizzazione "al volo" non va. Ho passato un paio d'ore a cercare di fare in modo che l'aspx generasse esattamente lo stesso contenuto del .js, sono arrivato a scoprire che i dati trasferiti al client erano esattamente gli stessi (a livello di byte) ed ancora non andava.
Sapete quale era la soluzione? Specificarlo dove carico il Javascript
<script charset='utf-8' type='text/javascript' src='Localized.aspx'></script>
Senza il pezzo in grassetto Explorer non ne vuole sapere di capire che il file che arriva è un utf-8, anche se i byte che gli mandi dalla pagina aspx sono esattamente gli stessi che arrivano dal .js, byte per byte. Mistico. Nota che con Firefox non ci sono problemi.