Come localizzare correttamente i numeri?

Quali avvertenze dovrei conoscere mentre localizzo i numeri nella mia applicazione front-end?

Esempio: in portoghese brasiliano (pt-BR) abbiamo diviso migliaia con punti e decimali con virgole. In inglese americano (en-US) è ​​il contrario. In pt-BR presentiamo le cifre separate da migliaia, lo stesso di en-US. Ma leggendo sull'inglese indiano (en-IN) oggi mi sono imbattuto in questo gioiello:

Il sistema di numerazione indiano è preferito per il raggruppamento delle cifre. Se scritti a parole o quando pronunciati, i numeri inferiori a 100.000 / 100.000 sono espressi esattamente come nell'inglese standard. I numeri compresi e oltre 100.000 / 100.000 sono espressi in un sottoinsieme del sistema di numerazione indiano.

https://en.wikipedia.org/wiki/Indian_English#Numbering_system

Che significa:

1000000 units in pt-BR are formatted 1.000.000
1000000 units in en-US are formatted 1,000,000
1000000 units in en-IN are formatted 10,00,000

Oltre alle virgole, ai punti e ad altri separatori specifici, sembra che anche il mascheramento sia una preoccupazione valida.

Quali altri avvertimenti dovrei conoscere mentre localizzo i numeri nella mia applicazione front-end? Specialmente se sto mostrando numeri a set di caratteri non latini?

La maggior parte dei linguaggi e dei framework di programmazione ha già un meccanismo sensibile e funzionante che è possibile utilizzare per questo.

Ad esempio, l'ecosistema C # ha lo spazio dei nomi System.Globalization , che consente di specificare ciò che Culturesi desidera:

Console.WriteLine(myMoneyValue.ToString("C", "en-US"));

Questo non è qualcosa che vuoi reinventare. Utilizzare le funzionalità di internazionalizzazione fornite dalla propria lingua o struttura preferita.

Alcune risposte eccellenti qui già, ma non hanno menzionato una cosa che penso sia importante non dimenticare: assicurarsi che ovunque avvenga una formattazione numerica, è chiaro (o può essere controllato) a cosa serve l'output:

• quando è per l'interfaccia utente, è necessario applicare la formattazione localizzata

• quando il numero sta per essere scritta in un file, o inviati attraverso la rete, o un'altra forma di cui è necessario il numero in lettura ottica modulo, assicurarsi che sia non formattato secondo la cultura corrente, ma secondo una taratura fissa (ad esempio, nell'ambiente .NET, utilizzare InvariantCulture).

Altrimenti si verificano problemi quando i numeri vengono scritti o inviati utilizzando la cultura A e letti o ricevuti utilizzando la cultura B.

Per la mia esperienza, questo è uno dei maggiori ostacoli nel fare una corretta localizzazione dei numeri: nel tentativo di centralizzare la formattazione e la conversione dei numeri, le persone iniziano a creare funzioni generali e riutilizzabili per la formattazione, quindi iniziano a usarle in tutto il posto. Tuttavia, non appena si richiedono i numeri anche in un formato stringa leggibile dalla macchina da qualche altra parte nel programma, sono necessarie due varianti: una formattazione localizzata e una non localizzata. Ciò comporta un rischio elevato di confondere le due forme di conversione (specialmente quando gli sviluppatori e le macchine di prova hanno le impostazioni internazionali predefinite simili all'impostazione "fissa" utilizzata per la formattazione non UI, ma parte della base utenti non lo ha fatto).

Addendum: questo problema può diventare davvero brutto in situazioni in cui non è chiaro in anticipo se il numero verrà elaborato da una macchina o da un essere umano (o entrambi) in seguito. Ad esempio, come parte dell'output di un file di registro. In tali casi è probabilmente meglio attenersi allo standard "neutro" di non utilizzare alcun separatore tranne il punto come separatore decimale.

Una corretta localizzazione è piuttosto difficile. La maggior parte degli ecosistemi di programmazione tenta di trovare una soluzione per la localizzazione, ma nella mia esperienza sono tutti più o meno distrutti. Pertanto suggerirei:

• Non tentare di automatizzare la localizzazione. Non funzionerà sempre. È difficile per te individuare i problemi e frustrante per i tuoi utenti.

• Sii coerente: non mescolare lingue diverse e convenzioni di formattazione, ad esempio separatori decimali in stile brasiliano nel testo inglese.

• Supportare esplicitamente un determinato set di impostazioni locali. Collabora con i tuoi traduttori per capire la formattazione corretta di date e numeri. Probabilmente finirai per creare il tuo toolkit di localizzazione, sebbene la maggior parte (ma non tutti) i problemi possano essere delegati a una libreria esistente.

• Rendi le opzioni di formattazione semplici configurabili da ciascun utente: formati per date e orari, separatori decimali, valuta preferita, ... Ciò è particolarmente utile per viaggiatori, espatriati o altre persone che devono mescolare più località o culture indipendentemente dalla lingua.

Una considerazione importante: dovresti decidere quanto è abbastanza. Perché se vai nella tana del coniglio cercando di localizzarti perfettamente, diventerà sempre più complesso.

Prendi un'etichetta tipica come "Hai selezionato n articoli". Ciò è errato se è stato selezionato un solo elemento. La brutta ma pragmatica soluzione è scrivere "Hai selezionato n articoli." Ma se vuoi farlo correttamente, hai bisogno di due testi diversi a seconda di n. Se provi a farlo in più locali, diventerà rapidamente molto complesso, poiché lingue diverse hanno una grammatica diversa. Alcune lingue hanno coniugazioni diverse per uno, due e più elementi e così via. Per questo motivo le persone che si conoscono si lamenteranno sempre che i quadri di localizzazione esistenti sono insufficienti.

Ma devi scegliere le tue battaglie e decidere quale livello di raffinatezza è sufficiente. Per molti scopi dovrebbe essere sufficiente una libreria di localizzazione standard per la formattazione di numeri e date.

Non puoi essere a conoscenza di tutti gli avvertimenti delle lingue. Stai parlando di numeri, ma ci sono plurali, generi, regole di confronto. Devi sapere che esistono e fare affidamento su un ampio lavoro svolto da altre persone, in particolare i progetti ICU e CLDR.

La maggior parte dei linguaggi moderni implementa alcune o tutte le caratteristiche di questi progetti, ma anche se non lo fanno, leggere questi progetti ti darà una buona idea di cosa cercare.

http://site.icu-project.org

http://cldr.unicode.org

Aggiornare

Lo strumento di sondaggio CLDR fornisce l'accesso a tutti i modelli. Questo ti mostrerà come formattare un numero in determinate lingue e regioni. Ad esempio, portoghese (Portogallo):

http://st.unicode.org/cldr-apps/v#/pt_PT/Number_Formatting_Patterns/

E se vuoi davvero controllare tutti i dati (e forse usarli), puoi scaricare il CLDR in formato JSON da GitHub:

https://github.com/unicode-cldr/cldr-json#cldr-json

Maggiori informazioni sui download qui:

http://cldr.unicode.org/index/downloads

Bene, mentre sono contento di tutte le risposte qui, non sono davvero soddisfatto di ciascuna di esse separatamente per contrassegnarne una come risposta corretta.

Finora questo è ciò di cui dovremmo essere a conoscenza quando localizziamo i numeri:

Per l'uomo :

• Migliaia di separatori non si separano sempre a migliaia. Vedi il caso indiano nella domanda;
• Migliaia e decimali personaggi variano cultura per cultura. In tedesco migliaia sono divisi usando spazi, per esempio, mentre in inglese sono i comandi e in portoghese sono i punti;
• Non abbiamo informazioni se esiste una differenza rilevante tra le lingue da sinistra a destra e da destra a sinistra;
• Fornire un set specifico di localizzazioni supportate e renderlo chiaro per i tuoi utenti;
• Consenti ai tuoi utenti di modificare la localizzazione predefinita in una delle localizzazioni supportate e saranno felici e ti invieranno torte grate, perché sei un dio generoso. :);

Per i computer :

• Ricordare che le macchine non sono indulgenti e dovrebbero sempre ricevere la stessa formattazione durante la serializzazione e la deserializzazione di un numero;
• Stick con un unico formato per esso;
• Utilizzare il formato minimo necessario possibile. Evita la separazione di migliaia, i decimali dovrebbero essere sufficienti per la serializzazione e la deserializzazione.

Per gli sviluppatori :

• (come suggerito da @hyde di seguito): utilizza la libreria esistente per la localizzazione;
• Se possibile, utilizzare tester nativi e specificare casi di test di localizzazione / internazionalizzazione, altrimenti affidarsi alla libreria;
• Ricorda che la localizzazione è un problema per lo più risolto. Ogni lingua principale ha una biblioteca, nativa o esterna, in grado di localizzare numeri, date e orari;