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

In .NET Framework, le stringhe localizzate si trovano in un file XML (o più file). Tali file fanno parte del progetto e sono impegnati nel controllo del codice sorgente come qualsiasi altro file del codice sorgente. Di solito, Visual Studio viene utilizzato per visualizzare tali file come tabella e modificare le stringhe localizzate.

Lavoro in un piccolo team su un prodotto che dovrebbe avere un'interfaccia multilingue.

1. Come sviluppatore, redigo le stringhe localizzate in entrambe le lingue, dato che la traduzione potrebbe essere inesatta,

2. Un'altra persona del team (un non sviluppatore) rivede il contenuto in entrambe le lingue e lo corregge, se necessario.

Il problema attuale è che la persona non sviluppatrice non userebbe né il controllo del codice sorgente, né un IDE, poiché sarebbe troppo ingombrante e difficile (il controllo della versione è difficile per i non sviluppatori) per questa persona.

Una soluzione alternativa sarebbe quella di esportare le stringhe localizzate come file Excel, attendere che questa persona riveda Excel, quindi reimportare le stringhe modificate. L'avvertenza qui è che potrei creare altre stringhe, rinominare quelle esistenti, ecc., Rendendo difficile diff la versione locale con quella rivista.

Cosa fare?

Come succede in altre squadre?

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

1. Sebbene ciò che KateGregory afferma sia 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), adattarsi / avvolgere correttamente (il lungo tedesco parole) e non provocare attacchi di iniezione (come l'uso degli apostrofi da parte 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 all'insaputa del team o commettere modifiche non intenzionali (intenzionalmente o non intenzionalmente).
4. Presuppone inoltre che l'unica cosa che si sta localizzando siano 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 compilazione include stringhe fornite dai localizzatori dopo un rapido controllo di integrità e la build condivisa con i localizzatori per i test. Il sito Web può utilizzare accessi per diversi localizzatori (e tracciare e fatturare il lavoro se si desidera andare 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 usare per modificare le risorse:

Penso che il check-out-on-edit combinato con un minuto di dimostrazione della finestra "modifiche in sospeso" dovrebbe consentire al non sviluppatore di utilizzare il controllo del codice sorgente necessario.

Vorrei cercare un editor XML * che il non sviluppatore possa usare.

Dovrai quindi fornire gli estratti con versione al non sviluppatore per la revisione.

Una volta terminata la revisione, è possibile ricontrollare il file.

Dopo aver apportato le modifiche, dovrai semplicemente diff i file XML prima del check-in e inviare le sezioni aggiornate dall'utente al non-sviluppatore per la revisione. I tuoi aggiornamenti sono il motivo per cui è necessario mantenere i file di revisione aggiornati.

Cercare di usare Excel renderà le cose estremamente difficili poiché gli strumenti diff per Excel lasciano molto a desiderare. Corri anche il rischio di ulteriori commenti che si insinuano nelle celle extra all'interno del foglio di calcolo. Tali commenti richiederebbero una gestione aggiuntiva da parte tua al fine di unirli nuovamente.

In una vita precedente, abbiamo utilizzato un processo abbastanza simile per una serie di traduzioni di organizzazioni esterne. I nostri file erano essenzialmente file di testo con una forma simile ma diversa da XML. E abbiamo avuto tonnellate di modifiche in corso mentre i file erano in fase di revisione, quindi apprezzo il divertimento della tua situazione.

Un'opzione è quella di creare un'applicazione di supporto in cui il traduttore può vedere l'elenco delle stringhe in un riquadro e immettere la lingua specifica in un altro. In questo modo i dati vengono archiviati nuovamente nell'XML e quindi è possibile che l'applicazione esporti il ​​file.

Se elabori le chiavi in ​​un database e memorizzi lì ogni lingua, ciò consentirebbe l'integrazione delle modifiche e il traduttore di vedere ciò che deve essere aggiornato. Quindi puoi semplicemente esportare nel file XML specifico della lingua che rimetti nel controllo di versione o il traduttore potrebbe.

Usiamo un metodo simile a questo con il nostro codice Rails, non modificiamo né forniamo nemmeno i file specifici della lingua, sono tutti mantenuti e quindi esportati dall'applicazione esterna utilizzata dal nostro team di traduzione. Mi dispiace non so se il loro software è personalizzato o pronto all'uso, ma non dovrebbe essere così difficile mettere insieme qualcosa di semplice.

Come fai a sapere che hai tutte le stringhe e che sono formattate correttamente nell'app? Come fai a sapere che numeri, valuta, fuso orario e altre informazioni sulla locale sono formattati correttamente? Che tutto sia caricato e la serializzazione multibyte funzioni correttamente?

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