Processo di localizzazione dell'app Delphi 2009 da parte di traduttori volontari?

Question

Ho un'applicazione scientifica gratuita che viene utilizzata da migliaia di persone in quasi 100 paesi. Molti si sono offerti di tradurre gratuitamente. Ora che D2009 lo rende più semplice (con strumenti di localizzazione integrati ed esterni, oltre al supporto nativo Unicode) mi piacerebbe farlo accadere per alcune lingue e aggiungere costantemente quante l'energia dell'utente supporterà.

Sto pensando di distribuire un foglio di calcolo con un elenco di stringhe (dozzine ma non centinaia) da tradurre, farle restituire e confrontare i contributi nella stessa lingua da 2-3 utenti, quindi lavorare a risolvere le discrepanze per consenso. Quindi incorporerò le localizzazioni usando l'Integrated Translation Environment e distribuiremo aggiornamenti localizzati.

Qualcuno ha delegato la traduzione agli utenti? Qualche trucco, specifico D2009 o altro?

EDIT: qualcuno ha confrontato il supporto di localizzazione incorporato in D2009 rispetto a dxgettext?

Answer 1

Non sono mai stato un amico di strumenti di localizzazione proprietari per applicazioni Freeware o Open Source. Utilizzando dxgettext, il porto di Delphi GNU gettext si presenta come una soluzione molto migliore per me:

• Integrazione nel programma (anche molto più tardi rispetto al suo sviluppo) è facile.
• L'estrazione di stringhe traducibili può essere eseguita da programmi a riga di comando ed è quindi facilmente introdotta in una build automatizzata.
• Una nuova traduzione può essere aggiunta semplicemente creando una nuova directory con la struttura corretta, copiando il file di traduzione vuoto in esso e iniziando a tradurre le stringhe. Questo è qualcosa che ogni utente può fare da sé, non è necessario coinvolgere l'autore originale per la creazione di una nuova traduzione. C'è anche una gratificazione immediata con questo processo: una volta riavviato il programma, le nuove traduzioni vengono visualizzate immediatamente.
• La modifica di una traduzione esistente è ancora più semplice rispetto alla creazione di una nuova. Pertanto, se un utente trova spelling o altri errori o necessità di miglioramento nella traduzione, può correggerli facilmente e inviare le modifiche all'autore.
• Le nuove versioni di programma funzionano con le traduzioni precedenti, il sistema si degrada molto bene - le stringhe nuove e non tradotte vengono semplicemente mostrate non modificate.
• Le traduzioni possono essere eseguite utilizzando solo il blocco note, ma esistono anche diversi strumenti gratuiti per la creazione e la gestione dei file di traduzione; vedere i collegamenti sulla pagina dxgettext. Sono localizzati essi stessi e presentano alcuni vantaggi rispetto a un foglio di calcolo:
• È possibile visualizzare la posizione delle stringhe nel codice sorgente (ovviamente solo per le app Open Source, ovviamente).
• Viene visualizzata la percentuale di stringhe tradotte.
• Anche le modifiche alle stringhe già tradotte sono evidenziate.
• L'intero sistema è maturo e a prova di futuro - Ho usato dxgettext per i programmi Delphi 4 e non ci dovrebbero essere nemmeno le modifiche necessarie per Delphi 2009 - i file di traduzione sono sempre stati codificati in UTF-8.

L'utilizzo di un foglio di calcolo per la traduzione non mi sembra una soluzione praticabile una volta che hai più di alcune lingue. Supponiamo che una nuova versione del programma aggiunga 2 nuove stringhe e cambi solo 10 stringhe - non sarebbe necessario aggiungere le nuove stringhe e evidenziare le stringhe modificate in tutte le decine di decine di fogli elettronici e inviarli di nuovo ai tuoi traduttori? Usando dxgettext devi solo spedire il file po modificato a tutti loro.

Edit:

C'è un interessante commento sui problemi ci possono essere con dxgettext e librerie. Non l'ho mai sperimentato, poiché ho smesso completamente di utilizzare le stringhe di risorse. La maggior parte dei nostri programmi sono in tedesco e solo alcuni sono in inglese o tradotti in più lingue.

Le nostre librerie interne utilizzano "_ (...)" attorno a tutte le stringhe traducibili. Sono definiti ENGLISH e USEGETTEXT impostati su base di progetto. Se sono definiti ENGLISH o USEGETTEXT, i testi in inglese vengono compilati nelle DCU, altrimenti il ​​testo tedesco viene compilato nelle DCU. Se USEGETTEXT non è definito "_()" è compilato come una funzione che restituisce il suo parametro così com'è, altrimenti viene utilizzata la ricerca della traduzione di dxgettext.

Answer 2

Ho ... Ci possono essere alcune sfide.

• una stringa non significa molto di per sé, ha bisogno di un contesto.
• corollario, la stessa stringa può richiedere più di una traduzione.
• schermo immobiliare: attenzione a diverse lunghezze a seconda della lingua, ad esempio, il francese tende ad essere più prolisso dell'inglese.
• a meno che non si disponga di una determinata lingua, non sarà possibile valutare le discrepanze.

Answer 3

Ho usato TsiLang Translation Suite per consentire agli utenti finali di tradurre. Ho modificato il codice per consentire la crittografia in modo che se qualcuno fa un ottimo lavoro può proteggere il proprio nome contro un file di traduzione, ma in generale l'idea è che le persone possano condividere le loro traduzioni e aggiungere/modificare qualsiasi piccola parte che desiderano. Dato che tutto accade all'interno dell'app e con visibilità immediata, funziona davvero bene.

Answer 4

Come già accennato, D2009 è dotato di strumenti di localizzazione. Perché non semplicemente usarli? AFAIK è possibile distribuire il gestore di traduzione esterno (etm.exe). Avete bisogno di altro?

Inoltre, la localizzazione è più di una semplice traduzione di testo. ETM supporta anche la traduzione di risorse .dfm.

Answer 5

Per completezza, ecco un altro strumento di localizzazione Delphi chiamato Delphi Localizer Recentemente ho trovato che sembra essere ben progettato e lucido. Lo strumento è gratuito per uso commerciale ad eccezione dei progetti governativi (non è esattamente sicuro del motivo dell'eccezione).

FWIW Ho utilizzato TsiLang Translation Suite in passato e sto attualmente lavorando su un altro progetto utilizzando gli strumenti di localizzazione forniti con DevExpress VCL. Più tardi si integra bene con i loro componenti e con componenti di terze parti.