Come gestire l'attività di revisione delle stringhe localizzate da parte di un non sviluppatore?

La localizzazione è molto più complessa della semplice modifica di XML in Visual Studio, in particolare:

1. Anche se KateGregory dice è corretto, Visual Studio è costoso e l'acquisto di copie per i localizzatori è spesso proibitivo.
2. A meno che il localizzatore non sia anche uno sviluppatore, non possono vedere le stringhe nel prodotto e verificare che le stringhe siano visualizzate correttamente (caratteri non europei come le lingue asiatiche o testo da destra a sinistra come l'arabo), adatta / avvolge correttamente (Le parole lunghe del tedesco) e non causano attacchi di iniezione (come l'uso degli apostrofi del francese)
3. Sebbene il controllo della versione non sia uno strumento complesso, l'accesso al controllo del codice sorgente a localizzatori remoti o contratti è un rischio. Potrebbero copiare il codice sorgente senza le conoscenze del team o commettere modifiche irrisolte (intenzionalmente o involontariamente).
4. Suppone anche che l'unica cosa che stai localizzando sia i file RESX. Alcuni prodotti potrebbero avere dati localizzati come i nomi dei rapporti.

Pertanto, la cosa migliore da fare è creare un semplice sito Web che esponga le varie stringhe, nascondendo la sintassi sottostante. Il processo di build include le stringhe fornite dai localizzatori dopo un rapido controllo di integrità e la build condivisa con i localizzatori per il test. Il sito Web può utilizzare gli accessi per diversi localizzatori (e tenere traccia e fatturare se si vuole arrivare così lontano). Questo è più lavoro ma una soluzione migliore a lungo termine.

La modifica di XML fa schifo. Visual Studio ha una vista che puoi utilizzare per modificare le risorse:

Pensocheilcheck-out-on-editcombinatoconunminutodidimostrazionedellafinestra"modifiche in sospeso" dovrebbe consentire al tuo non sviluppatore di utilizzare il controllo del codice sorgente quanto necessario.

Vorrei cercare un editor XML * da usare per i non sviluppatori.

Dovrai quindi fornire estratti di versioni al non sviluppatore per la revisione.

Una volta terminata la revisione, puoi ricontrollare il file.

Quando hai apportato delle modifiche, dovrai semplicemente diffare i file XML prima del check-in e inviare le sezioni aggiornate per te al non-dev per la revisione. I tuoi aggiornamenti sono il motivo per cui è necessario mantenere i file di revisione con versione.

Cercare di usare Excel renderà le cose estremamente difficili dal momento che gli strumenti di differenziazione per Excel lasciano molto a desiderare. Corri anche il rischio di ulteriori commenti che si insinuano nelle celle aggiuntive all'interno del foglio di calcolo. Questi commenti richiederebbero un trattamento aggiuntivo da parte tua per unirli nuovamente.

In una vita precedente, abbiamo utilizzato un processo abbastanza simile per un numero di traduzioni da parte di organizzazioni esterne. I nostri file erano essenzialmente file di testo con una forma simile ma diversa da XML. E abbiamo avuto un sacco di cambiamenti mentre i file erano fuori per la revisione, quindi apprezzo il divertimento della tua situazione.

Un'opzione consiste nel creare un'applicazione di supporto in cui il traduttore può visualizzare l'elenco di stringhe in un riquadro e inserire la lingua specifica in un altro. In questo modo i dati vengono archiviati nell'XML e quindi è possibile fare in modo che l'applicazione esporti il file.

Se si elaborano le chiavi in un database e si memorizzano tutte le lingue lì, si consente di integrare le modifiche e il traduttore di vedere quali esigenze devono essere aggiornate. Quindi puoi esportare nel file XML specifico della lingua che hai reinserito nel controllo della versione o nel traduttore.

Usiamo un metodo simile a questo con il nostro codice Rails, non modifichiamo o forniamo file specifici della lingua, vengono tutti mantenuti e quindi esportati dall'applicazione esterna utilizzata dal nostro team di traduzione. Spiacente, non so se il loro software è personalizzato o meno, ma non dovrebbe essere così difficile mettere insieme qualcosa di semplice.

Come fai a sapere di avere tutte le stringhe e che sono formattate correttamente nell'app? Come fai a sapere che numeri, valuta, fuso orario e altre informazioni locali sono formattati correttamente? Che tutto è caricato e la serializzazione multibyte funziona correttamente?

No. La localizzazione è una funzionalità come le altre. Controllalo. Crea una build. Lascia che il tester ottenga la build e verifica che la funzionalità sia eseguita correttamente come qualsiasi altra. Quando crei una nuova build, puoi eseguire test di regressione sulla localizzazione, proprio come qualsiasi altra funzione.