Ti sviluppi con la localizzazione in mente?

Lavoro per una grande azienda di Fortune 500 e iniziamo sempre con la localizzazione in mente. I nostri progetti sono di solito solo per gli Stati Uniti, ma troppe volte nel corso degli anni, scriveremo un'app per un cliente e poi qualcuno lo vedrà e dirà "hey, sarebbe fantastico per il paese X". La prossima cosa che sai è che stai passando attraverso il codice aggiungendo la localizzazione. Non ci vuole più tempo per costruire l'app fin dall'inizio, quindi lo facciamo. Inoltre, l'ulteriore vantaggio è che quando un cliente viene da noi e chiede che la sua app sia presente (scegli la tua lingua), gli consegniamo un file e diciamo loro di farlo tradurre (scegli la tua lingua) e abbiamo finito .

Penso che sia stato importante 10 anni fa. La tecnologia recente ha risolto il problema .

Io vivo in un paese in cui ci sono 3 lingue nazionali , e solo una di esse è una minoranza.

Per comprendere i problemi che potrebbero verificarsi a causa di ciò, è come avere la parte occidentale degli Stati Uniti che parlano una (molto) lingua diversa dalla parte est. Pensa che al centro del paese, la popolazione è un po 'fusa, e quindi devi usare entrambe le lingue ovunque.

Avere 4 lingue in applicazioni desktop e siti web era ed è ancora molto comune (3 lingue nazionali + inglese). A volte è un obbligo.

Ero consapevole della localizzazione perché sono stato condizionato dal mio ambiente. Quindi sì, pochi anni fa, mi preoccupavo.

Ora non mi interessa molto della localizzazione perché gli ultimi strumenti IDE ti permettono di convertire qualsiasi applicazione statica in una completamente localizzata con estrema facilità.

Strumenti che uso con Visual Studio .NET:

• CodeRush , un plug-in di Visual Studio che consente di spostare testi codificati in file di risorse.
• Localizzatore facile , estrai le etichette in un file Excel in cui aggiungi tutte le lingue aggiuntive, quindi unisci indietro nei file delle risorse.

La maggior parte dei miei clienti richiede solo una lingua, e in effetti specifica quella lingua. Pertanto, non dedichiamo tempo a localizzare l'applicazione. Tuttavia, ciò non significa che possiamo ignorare completamente altre lingue. Quindi seguiamo le basi:

• Utilizza Unicode ovunque. È 2k10, non ci sono scuse per non farlo.
• Progetta l'elasticità di alcuni nel layout. Anche con tutti gli inglesi, i font diversi hanno un footprint dello schermo molto diverso con le stesse dimensioni dei punti.
• Mantieni le funzioni dell'applicazione / modellazione dei dati fuori dal livello di visualizzazione

Personalmente, quando un potenziale linguaggio di localizzazione è fondamentalmente diverso da quello in cui è stata progettata l'applicazione, c'è molto di più che nella semplice selezione di testo. Mentre la sostituzione del testo aiuta e consente a un'azienda di ottenere un'implementazione "rapida e sporca" in una nuova posizione relativamente prima, non risolve le differenze fondamentali nel modo in cui pensano gli utenti nell'altra lingua.

Ho studiato giapponese e, anche se posso considerarmi un principiante in quella lingua, ne so abbastanza che ci sono alcuni concetti per cui non esiste una traduzione diretta. Ci sono idee diverse su ciò che rende qualcosa utilizzabile. Mentre i grandi concetti principali potrebbero essere simili, sono i dettagli che fanno davvero la differenza con gli utenti.

Per soddisfare veramente le esigenze di una cultura molto diversa, è necessario un volto completamente nuovo per la tua applicazione. Ecco perché la separazione modello / vista / controllore diventa ancora più importante. Finché l'applicazione funziona allo stesso modo, la porzione di vista può essere completamente sostituita. Quando ciò accade, qualcuno sta pianificando di pagare dei soldi veri per affrontare il problema correttamente.

L'abbiamo fatto secondo le necessità: le cose rivolte ai clienti ora sono tutte fatte con i18n in mente, dato che abbiamo ampliato i nostri mercati, e alcune cose interne ora sono in grado di supportare i18n, quindi i dipendenti che ne fanno uso non ne hanno bisogno parla inglese.

Quindi, lo abbiamo fatto in base alle necessità, come avvio.

Sembra che le persone stiano prendendo gli sforzi della l10n piuttosto alla leggera. Soprattutto quando si usa l'inglese come lingua originale, è facile ignorare il fatto che normalmente altre lingue richiedono addirittura il 30-40% di spazio in più per il testo. Ciò richiede che i traduttori usino abbreviazioni che non sono così facili da capire, il che ovviamente non va bene per l'esperienza utente.

Di solito, aggiungo l'internazionalizzazione più tardi quando ne ho bisogno, anche se so fin dall'inizio che ne avrò bisogno. Con le lingue che sto usando, non è terribilmente difficile farlo in una fase separata, e posso mantenere un aspetto ingombrante dalle prime fasi costruttive.

Scrivo applicazioni Android e la localizzazione è piuttosto semplice utilizzando i file di stringa stile java. Quasi zero sforzi per la piena internazionalizzazione su tutte le lingue Android.

Risposta: sì. Anche se nell'ambiente lavoro (Python / Zope / Plone) è molto semplice localizzare le stringhe in seguito, quindi lo salterò se non è un requisito dall'inizio.

Ma memorizzo il testo in oggetti unicode, ecc.

Quindi, sì. Mi assicuro che le mie applicazioni siano ragionevolmente facili da localizzare e anche se non localizzate funzioneranno in un contesto internazionale. Non farlo è un errore, poiché lo sforzo necessario è piccolo e il vantaggio è notevole.