Esempio di vita reale del processo di localizzazione di Software

Questo è un esempio di vita reale di tradurre una piccola applicazione di Windows chiamata Multilizer Translator Gadget, che è un Gadget di Windows Sidebar. Anche se ogni progetto di localizzazione software è unico, c'è un percorso universale che è seguito dalla maggior parte dei casi di localizzazione. Andiamo attraverso questo percorso con questo caso.

Fase di pre-localizzazione

Prima di qualsiasi progetto di localizzazione può essere avviato, è necessario definire gli obiettivi del progetto. Localizzazione non è un termine semplice e per evitare eventuali malintesi è importante chiarire che cosa significa in questo caso specifico. Nel nostro caso la localizzazione è stata ridotta a tradurre l'interfaccia utente in più lingue.

#1 Impostare gli obiettivi per il progetto.

Dopo uno sa qual è il risultato desiderato del progetto, si raccomanda di dare un'occhiata al software. Ci sono molte cose che gli sviluppatori di software possono fare per facilitare il processo di localizzazione effettiva. (A causa dell'aspetto tecnico di questa tappa, i seguenti paragrafi contengono qualche gergo tecnico. Se è troppo complicato, Basta saltare straightly alla “Fase di localizzazione” o chiedere qualche aiuto un nerd.)

Nel nostro caso abbiamo scoperto che il gadget consistono tipicamente di HTML, CSS, e JavaScript. E i testi da tradurre possono essere nei file HTML, o a volte anche in JavaScript. Questo applicato anche al gadget che abbiamo sviluppato.

Le fonti sono state organizzate in modo tipico nelle seguenti cartelle:

radice   immagini   css, js

La radice contiene il codice HTML e il manifesto di gadget. CSS contiene i fogli di stile. Immagini contiene le immagini utilizzate da gadget. E js contiene JavaScript che aggiunge la funzionalità desiderata nel gadget.

#2 Controllare l'architettura software.

Il Gadget prende un uso dell'architettura Microsoft MUI; possono esserci cartelle denominate dalle impostazioni internazionali ISO, come 'es-ES'. Su un sistema spagnolo Sidebar sarebbe per prima cosa file sotto ' es-ES’ directory. Se non trovato, poi ' neutro’ vuoi caricare file. Basato su questa architettura, Traduzione comporterebbe che verrebbero copiati tutti i file in una nuova directory denominata dalle impostazioni internazionali ISO. Dopo che i file con testi in italiano può essere tradotta in un'altra lingua. Questo approccio, Tuttavia, non è così elegante. Un sacco di file sono stati raddoppiati come tale.

Per ovviare a questo, abbiamo deciso di internazionalizzare il codice. Questo significa che abbiamo rimosso tutti i testi in inglese e li mise in un file di risorse comuni, denominato 'resourcestrings.js'. E l'interfaccia utente è ora popolata all'avviamento chiamando un getResourceString() funzione.
Con questo approccio la traduzione del gadget è semplicemente ridotto traduzione di 'resourcestrings.js'.

Abbiamo anche aggiunto due funzioni extra per fare la parte di programmazione ancora più conveniente:

  • setElementText(elementid,resourcekey)
  • setAttributeText(elementid,attributename,resourcekey)

#3 Internazionalizzare il codice (Se possibile)

Queste relativamente piccoli cambiamenti nel codice di facilitare e semplificare notevolmente la fase successiva del progetto di localizzazione.

Fase di localizzazione

Quando è fatto tutto il lavoro preparatorio, la localizzazione effettiva può cominciare. Uno può fare la fase di localizzazione semi-automaticamente o manualmente con uno strumento speciale di localizzazione. Lavoro manuale richiede conoscenza molto più tecnico di sviluppo software di lavorare con uno strumento di localizzazione. Le differenze più significative tra questi due metodi sono tempo e sicurezza. Uno strumento di localizzazione accelera il processo di automazione di certe attività e protegge il software eliminando la possibilità di apportare modifiche fatale al codice durante il processo di localizzazione.

Abbiamo fatto il nostro progetto con la nostra, strumento di localizzazione avanzato chiamato Multilizer Enterprise. È uno strumento versatile per i piccoli e grandi progetti. Abbiamo innanzitutto creato un nuovo progetto Multilizer e scansionato il nostro software con lo strumento. Il nostro strumento di localizzazione riconosce quale parte del codice dovrebbe essere tradotto e illustrato solo queste stringhe. Dopo che abbiamo esportato il materiale traducibile automaticamente a Google Translator Toolkit con MOTO.

#4 Preparare il progetto per la traduzione.

A questo punto del progetto è il momento di tradurre. A seconda gli obiettivi del progetto di localizzazione, uno dovrebbe decidere come è fatta la traduzione. La migliore uscita rischia di essere fatta da un traduttore professionista specializzato sul tema e sulla localizzazione di software. Tuttavia ci sono anche situazioni quando per esempio. Traduzione di crowdsourcing è la soluzione migliore. Nuovamente gli obiettivi e gli obiettivi del progetto dovrebbero essere presi in considerazione. Nel nostro progetto abbiamo utilizzato una piattaforma di lavoro online chiamata Elance per trovare traduttori.

I traduttori hanno lavorato sul nostro progetto con Google Translator Toolkit. Questo tipo di outsourcing online è semplice per i traduttori, perché essi possono lavorare in linea dove e quando vogliono senza che sia necessario per il download o l'installazione di programmi per il proprio computer. Per garantire la qualità, ci dovrebbe essere un canale di buona comunicazione tra i partecipanti.

#5 Reclutare Traduttore(e) e comunicare con loro.

Quando le traduzioni sono finite, possono essere integrate al codice. Nel nostro progetto, questo è stato reso importando le traduzioni automaticamente indietro da Google Translator Toolkit Multilizer Enterprise.

#6 Integrare le traduzioni al progetto si.

Quando tutto questo sono stati fatti, è possibile completare il progetto e costruire il software localizzato. In questa fase c'è una tentazione per contrassegnare il progetto finito e passare a quello successivo. Tuttavia c'è ancora una cosa importante da fare.

Fase post-localizzazione

Dopo che il software è localizzato, uno dovrebbe testarlo correttamente. È una buona idea lasciare che il traduttore(e) vedere l'esito pure. Tutte le eventuali inesattezze o refusi sono relativamente facili da risolvere adesso prima di qualsiasi ulteriore commercializzazione azioni.

Questo è come il nostro progetto di localizzazione ha proceduto. Vuoi fare qualcosa in modo diverso?

Link: