Internazionalizzazione dell'applicazione non inglese

È solo un mio modesto parere, ma penso che dovresti usare l'inglese come lingua predefinita della tua applicazione (come per ogni altra applicazione concepibile).

Ci sono almeno tre ragioni per questo:

1. La maggior parte se non tutti gli strumenti esistenti riconoscono e gestiscono solo inglese (o almeno solo lingue di tipo inglese). Sono italiano e so molto bene cosa significa gestire caratteri non ASCII (accentati) nel codice e nelle interfacce utente.

2. Al giorno d'oggi è quasi impossibile sviluppare un'applicazione senza scambio di codice con persone straniere. Pensa solo a SO stesso. Stai calpestando un problema, cerca aiuto su SO e pubblica qui uno snippet del tuo codice. Le persone che potrebbero aiutarti avranno un duro lavoro nel cercare di capire i nomi e i commenti delle tue variabili nella lingua nativa.

3. Più importante, sul web quasi tutti comprendono l'inglese. Forse solo una piccola percentuale di persone può effettivamente parlare e capire il linguaggio parlato ma quasi tutti possono leggere e capire scritto lingua. L'inglese è probabilmente la scelta migliore come linguaggio predefinito (o "fail safe" o "fallback").

Nonostante ciò, non vi è alcuna ragione convincente per tradurre tutto in inglese come prima mossa. Basta tradurlo mentre ti sposti alla nuova versione.

Inoltre: non provare a tradurre tutto . Ci sono elementi di codice e di interfaccia utente che non verranno mai esposti, nemmeno agli altri programmatori (stranieri).

Prova a tradurre questi elementi:

1. Messaggi visualizzati nell'interfaccia utente (notifica e simili) e nella console (messaggi di errore e simili)

2. Testi dell'interfaccia utente (ovviamente ...). Ciò significa qualsiasi testo in HTML e Javascript.

3. Se possibile, nomi di classi pubbliche, nomi di variabili pubbliche, nomi di metodi pubblici e commenti nel codice. Questi elementi saranno probabilmente letti e usati da altri programmatori e in questo momento non puoi sapere quale sarà la loro lingua madre.

4. Se usi qualche script di build cusom (Ant / Maven / Rake / Whatever), alcuni script di versioning personalizzati (GIT, SVN, ecc.) o qualche strumento di generazione di codice personalizzato, traducili pure. Fanno parte del tuo toolbox / toolchain ed è importante che altri programmatori (magari stranieri) possano comprenderli e usarli.

So che tradurre il codice sorgente è uno sforzo enorme e terribile. Non voglio dire che devi farlo tutto in una volta e solo ora. Basta tradurre il codice mentre si refactoring e solo quando si calpesta. È meglio avere un albero di sorgenti misti in inglese / madrelingua che in una sola lingua nativa (perché ogni programmatore decente nella tua zona dovrà comunque capire l'inglese. Questo significa che non puoi fare alcun danno traducendo le tue cose in inglese ).

Lascia nella tua lingua gli elementi che non compaiono nell'interfaccia utente e nel codice e / o che sono troppo dolorosi da tradurre. Ad esempio:

1. Nome tabelle e colonne DB. Crea un file "glossario" esterno per loro.

2. Classi private ("inner"), variabili private e nomi di metodi privati. Molto probabilmente, questi elementi non verranno mai visualizzati altrove e puoi tranquillamente ignorarli.

Ricorda che la maggior parte degli IDE può aiutarti molto in questo compito. Inoltre, puoi facilmente scrivere alcuni script PHP (o Python / Perl / Ruby) personalizzati per aiutarti a trovare e modificare le stringhe di testo.

Non è una buona fonte, vedrò se riesco a trovarne uno migliore. Fino ad allora, si tratta di centro di sviluppo di Gnome

Currently, gettext does not support non-ASCII characters (i.e. any characters with a code above 127) in source code.

Dato che vivo e lavoro in Germania, i nostri siti Web utilizzano sempre le traduzioni. Usiamo Ruby on Rails, ma da quello che ho letto gettext () sembra funzionare in modo simile al sistema di traduzione dei RoRs. Non importa se hai già la traduzione. Basta creare il file con i testi locali e trovare un buon sistema per ordinare questo file (principalmente seguendo la struttura dei siti.)

Normalmente facciamo qualcosa del genere:

main.news: News
main.download: Download

portal.order.name: Name
portal.order.street: Street
portal.order.city: City

Quindi questo sarebbe i primi due sono testi nella pagina principale e gli altri sono etichette per il modulo d'ordine nella sezione del portale. Li otterresti con gettext ("main.new"). Non limitarti a fare una lunga lista o non troverai mai più le cose. Consentire che alcune cose appaiano più volte (come se avessimo indirizzi in varie forme). Potresti creare tag come address.street, address.city, ma non cercare di evitare ripetizioni al 100%.

Può essere utile avere le traduzioni in fogli Excel o simili, da dove si generano i file di testo. Questo potrebbe facilitare la gestione. Non lo facciamo normalmente, anche un buon editor è ok.

Poi arriva il database, che è più complesso. Ci sono diversi modi per farlo. Fondamentalmente hanno tabelle separate per le traduzioni come Product con ProductTranslations o semplicemente ripetono campi come title_en, title_de etc.

L'approccio alla tabella è migliore se hai molte lingue. I campi sono più semplici e la ricerca con SQL è più semplice. Ma usiamo Apache Solr per la ricerca di testi, con un nucleo per lingua che funziona piuttosto bene, quindi il database è principalmente per l'archiviazione.

A seconda della tua lingua, preparati a problemi di codifica. Se possibile evitare di copiare i dati su sistemi diversi. Il peggiore è Windows a Linux. Se necessario, utilizzare il modo più diretto possibile. Una volta abbiamo esportato i dati del server MS-SQL in CSV e la lettura in Linux / Mysql. Fonte costante di dolore Ha funzionato molto meglio quando abbiamo saltato la parte CSV e letto i dati direttamente tramite ODBC.