Sviluppa pensando alla localizzazione?

Quando si lavora su un progetto software o un sito Web, si sviluppa tenendo presente la localizzazione?

Con questo intendo ad es

• Esternalizzazione di tutte le stringhe, inclusi i messaggi di errore.
• Non usare immagini che contengono testo.
• Progettare la tua interfaccia utente tenendo presente l'espansione del testo.
• Utilizzo della pseudo-traduzione per testare l'interfaccia utente nelle prime fasi del processo.
• eccetera.

Sui progetti su cui lavori, sono nella categoria "bello da avere" e lascia che il team di localizzazione si preoccupi per il resto, o hai predisposizione alla localizzazione integrata nel tuo processo di sviluppo? Sono interessato a sapere come gli sviluppatori vedono la localizzazione in generale.

Lavoro per una grande azienda Fortune 500 e iniziamo sempre pensando alla localizzazione. I nostri progetti di solito sono solo per gli Stati Uniti, ma troppe volte nel corso degli anni, scriveremo un'app per un cliente e poi qualcun altro la vedrà e dirà "ehi, sarebbe perfetto per il Paese X". Quindi la prossima cosa che sai è che stai attraversando il codice aggiungendo la localizzazione. In realtà non ci vuole altro tempo per creare l'app fin dall'inizio, quindi lo facciamo. Inoltre il vantaggio aggiuntivo è che quando un cliente viene da noi e chiede che la sua app sia in (scegli la tua lingua), gli consegniamo un file e diciamo loro di farlo tradurre in (scegli la tua lingua) e abbiamo finito .

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

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

Per capire i problemi che potrebbero verificarsi a causa di ciò, è come avere la parte occidentale degli Stati Uniti che parla una lingua (molto) diversa dalla parte orientale. Pensa che al centro del paese la popolazione sia un po 'unita, 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ì, qualche anno fa, me ne preoccupavo.

Ora non mi interessa molto la localizzazione perché gli strumenti IDE più recenti ti consentono di convertire qualsiasi applicazione statica in un'applicazione completamente localizzata molto facilmente.

Strumenti che utilizzo con Visual Studio .NET:

• CodeRush , un plug-in di Visual Studio che consente di spostare testi codificati in file di risorse.
• Easy Localizer , estrarre le etichette in un file Excel in cui si aggiunge tutta la lingua aggiuntiva, quindi unire nuovamente i file delle risorse.

La maggior parte dei miei clienti richiede solo una lingua e in realtà specifica quella lingua. Pertanto, non passiamo il tempo a localizzare l'applicazione. Tuttavia, ciò non significa che possiamo ignorare completamente altre lingue. Quindi restiamo fedeli alle basi:

• Usa Unicode ovunque. È 2k10, non ci sono scuse per non farlo.
• Design per un po 'di elasticità nel layout. Anche con tutto l'inglese, caratteri diversi hanno impronte dello schermo molto diverse con la stessa dimensione in punti.
• Mantieni le funzioni dell'applicazione / la modellazione dei dati fuori dal livello di visualizzazione

Personalmente, quando una potenziale lingua di localizzazione è fondamentalmente diversa da quella in cui è stata progettata l'applicazione, c'è molto di più in corso rispetto alla semplice selezione di testo. Mentre la sostituzione del testo aiuta e consentirà a un'azienda di ottenere un'implementazione "rapida e sporca" in una nuova posizione rispetto a prima, non risolve le differenze fondamentali nel modo in cui gli utenti dell'altra lingua pensano.

Ho studiato giapponese e mentre posso considerarmi solo un principiante in quella lingua, so abbastanza che ci sono alcuni concetti per i quali non esiste una traduzione diretta. Esistono 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 rispondere veramente alle esigenze di una cultura molto diversa, hai bisogno di un volto completamente nuovo per la tua applicazione. Ecco perché la separazione del modello / vista / controller diventa ancora più importante. Finché l'applicazione funziona allo stesso modo, la parte della vista può essere completamente sostituita. Quando ciò accade, qualcuno sta pianificando di pagare dei soldi veri per affrontare il problema in modo corretto.

Lo abbiamo fatto secondo necessità: le cose rivolte ai clienti ora sono tutte pensate per i18n, dal momento che abbiamo ampliato i nostri mercati e alcune cose interne sono ora compatibili con i18n, quindi i dipendenti che lo usano non devono parlare inglese.

Quindi, l'abbiamo fatto secondo necessità, come startup.

Sembra che le persone stiano facendo degli sforzi piuttosto leggeri. Soprattutto quando si utilizza l'inglese come lingua originale, è facile ignorare il fatto che altre lingue richiedono normalmente anche 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 è negativo per l'esperienza dell'utente.

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

Scrivo applicazioni Android e la localizzazione è piuttosto semplice usando file di stringa in stile java. Quasi zero sforzi per una completa internazionalizzazione su tutte le lingue Android.

Risposta: Sì Anche se nell'ambiente che lavoro (Python / Zope / Plone) è molto facile localizzare le stringhe in seguito, quindi lo salto se non è un requisito dall'inizio.

Ma conservo 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 beneficio è grande.