Come localizzare correttamente i numeri?

36

Quali avvertenze devo tenere presente durante la localizzazione dei numeri nella mia applicazione front-end?

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

The Indian numbering system is preferred for digit grouping. When written in words, or when spoken, numbers less than 100,000/100 000 are expressed just as they are in Standard English. Numbers including and beyond 100,000 / 100 000 are expressed in a subset of the Indian numbering system.

link

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 a virgole e punti e altri separatori specifici, sembra che anche il mascheramento sia una preoccupazione valida.

Quali altre avvertenze dovrei essere a conoscenza mentre localizzo i numeri nella mia applicazione front-end? Specialmente se sto mostrando numeri a set di caratteri non latini?

    
posta Machado 06.12.2016 - 17:40
fonte

6 risposte

86

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

Ad esempio, l'ecosistema C # ha il System.Globalization namespace, che consente di specificare Culture che desideri:

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

Questo non è qualcosa che vuoi re-inventare. Utilizza le funzionalità di internazionalizzazione fornite dalla tua lingua o framework preferita.

    
risposta data 06.12.2016 - 17:48
fonte
23

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

  • quando è per l'interfaccia utente, la formattazione localizzata deve essere applicata

  • quando il numero verrà scritto su un file, o inviato tramite la rete, o un'altra forma in cui il numero è necessario nel modulo leggibile dalla macchina , assicurarsi che sia < strong> non formattato in base alla cultura corrente, ma in base a un'impostazione fissa (ad esempio, nell'ambiente .NET, utilizzare InvariantCulture ).

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

Secondo 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 dappertutto. Tuttavia, non appena uno richiede i numeri anche in un formato stringa leggibile da una macchina da qualche altra parte nel programma, sono necessarie due varianti: una formattazione localizzata e una non localizzata. Ciò comporta un rischio elevato di mescolare le due forme di conversione (specialmente quando gli sviluppatori e le macchine di test hanno le impostazioni internazionali predefinite simili all'impostazione "fissa" utilizzata per la formattazione non UI, ma parte della base utente non lo è).

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

    
risposta data 06.12.2016 - 23:37
fonte
9

La corretta localizzazione è abbastanza difficile. La maggior parte degli ecosistemi di programmazione ha tentativi di soluzioni per la localizzazione, ma nella mia esperienza sono tutti più o meno infranti. Pertanto suggerirei:

  • Non provare ad automatizzare la localizzazione. Non funzionerà sempre. È difficile per te individuare i problemi e frustrare per i tuoi utenti.

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

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

  • Apporta semplici opzioni di formattazione configurabili da ciascun utente: formati per date e ore, separatori decimali, valuta preferita, .... Questo è particolarmente utile per i viaggiatori, gli espatriati o altre persone che hanno bisogno di mescolare più lingue o culture indipendentemente dalla lingua.

risposta data 06.12.2016 - 18:01
fonte
2

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

Prendi un'etichetta tipica come "Hai selezionato n elementi". Questo è sbagliato se è selezionato un solo elemento. La soluzione brutta ma pragmatica è scrivere "Hai selezionato n item (s)." Ma se vuoi farlo correttamente, hai bisogno di due testi diversi a seconda del n. Se provi a farlo in più lingue, diventerà rapidamente molto complesso, dal momento che lingue diverse hanno grammatica diversa. Alcune lingue hanno coniugazioni diverse per uno, due e più oggetti e così via. Per questo motivo le persone che conoscono si lamenteranno sempre che i quadri di localizzazione esistenti sono insufficienti.

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

    
risposta data 07.12.2016 - 08:30
fonte
2

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 delle lingue moderne implementa alcune o tutte le funzionalità di questi progetti, ma anche se non lo fanno, leggere questi progetti ti darà una buona idea di cosa cercare.

link

link

Aggiorna

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

link

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

link

Maggiori informazioni sui download qui:

link

    
risposta data 07.12.2016 - 08:13
fonte
0

Bene, mentre sono felice con tutte le risposte qui, non sono davvero soddisfatto di ognuna di esse separatamente per contrassegnare una come risposta corretta.

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

Per gli umani :

  • Migliaia di separatori non si separano sempre a migliaia. Vedi caso indiano nella domanda;
  • I caratteri di migliaia e decimali variano da cultura a cultura. In tedesco le migliaia sono divise usando spazi, per esempio, mentre in inglese è commans e in portoghese è punti;
  • Non disponiamo di informazioni se esiste una differenza rilevante tra le lingue da sinistra a destra e da destra a sinistra;
  • Fornisci un set specifico di localizzazioni supportate e rendilo chiaro ai tuoi utenti;
  • Consenti ai tuoi utenti di modificare la localizzazione predefinita in una delle localizzazioni supportate e saranno felici e ti invieranno dolci in segno di gratitudine, perché sei un dio generoso. :);

Per computer :

  • Ricorda che le macchine non sono clementi e devono sempre ricevere la stessa formattazione durante la serializzazione e la de-serializzazione di un numero;
  • Attacca con un unico formato per questo;
  • Utilizza il formato minimo necessario possibile. Evita la separazione di migliaia, i decimali dovrebbero essere sufficienti per la serializzazione e la de-serializzazione.

Per gli sviluppatori :

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