Come organizzare le risorse delle stringhe di localizzazione?

Stiamo sviluppando un'applicazione di grandi dimensioni, composta da molti piccoli pacchetti. Ogni pacchetto ha il proprio set di file di risorse per la localizzazione.

Qual è l'approccio migliore per l'organizzazione e la denominazione delle stringhe di localizzazione?

Ecco i miei pensieri finora:

Gestione dei duplicati

Lo stesso testo (ad esempio "Codice postale") può essere ripetuto più volte all'interno di un determinato pacchetto. L'istinto di programmazione (DRY) mi dice di creare una singola risorsa stringa condivisa da tutte le occorrenze .

Inoltre, un traduttore potrebbe voler scegliere una traduzione lunga ("Postleitzahl") in alcuni punti e una più breve ("PLZ") in luoghi con meno spazio. Oppure potremmo decidere di aggiungere due punti ad alcune occorrenze ("Codice postale:"), ma non ad altre. Oppure potremmo richiedere una diversa capitalizzazione ("codice postale") in alcuni punti. Tutti questi argomenti indicano la creazione di una risorsa per utilizzo, anche se il loro contenuto è identico .

Naming

Se miriamo ad eliminare i duplicati, ha senso nominare le risorse in base al contenuto , forse suggerendo il tipo di utilizzo tramite prefisso. Quindi potremmo avere labelOK= "OK" , messageFileTooLarge= "Il file supera la dimensione massima del file." e labelZipCode= "Codice postale" .

La denominazione in base al contenuto ha il vantaggio di gestire naturalmente gli argomenti di formato: la risorsa messageFileHas_0_MBWhileMaximumIs_1_MBprende chiaramente due argomenti di formattazione, la dimensione effettiva del file e la dimensione massima del file.

Se consentiamo duplicati, tuttavia, la denominazione solo per contenuto non ha senso. Per ottenere nomi di risorse univoci, dobbiamo in qualche modo includere il luogo di utilizzo nel nome della risorsa. Funziona con i controlli grafici, anche se gli identificatori tendono a diventare un po 'lunghi: fileSelectionConfirmationButtonText= "OK" , customerDetailsTableColumnZipCode= "Codice postale" . Tuttavia, per i file di codice non visivi, diventa più difficile. Come si nomina un uso specifico di una stringa se non si sa dove verrà visualizzata? Per file di codice e nome della funzione? Sembra piuttosto goffo e fragile per me.

Tutto sommato, mi sto impegnando per consentire i duplicati, ma sto lottando per trovare uno schema di denominazione coerente che supporti questo.

Modifica: questa domanda ha due aspetti: come organizzare le risorse (DRY vs. duplicati) e come nominarle . Finora le risposte si sono concentrate sul primo aspetto. Gradirei un feedback sulle convenzioni di denominazione!

Accetterei la duplicazione ogni volta che non puoi essere assolutamente sicuro che il significato sia esattamente lo stesso in tutti i casi in cui viene utilizzata una determinata stringa.

Anche se due etichette contengono sempre la stessa stringa in inglese (o nella tua lingua madre), non saranno necessariamente le stesse in tutte le lingue. Accettare la duplicazione può offrire a te (o meglio ai traduttori) la flessibilità necessaria per gestire tali situazioni.

Ad esempio: considera un'etichetta "Condizione" che, a seconda del contesto, potrebbe essere tradotta in "Zustand" o "Bedingung" in tedesco (tra molte altre traduzioni possibili).

Accetta alcuni duplicati.

Puoi evitare alcune traduzioni multiple creando controlli extra. Ad esempio un CancelButtone un OKButtonche già contengono il loro testo, e ora Annulla / Abbrechen OK / OK devono essere tradotti solo una volta. Ma questo è quasi un caso speciale.

Questo è il modo in cui lo gestiamo nella mia azienda:

Convenzione di denominazione: denominiamo le etichette con il prefisso con la loro classe / sezione / modulo / ecc. Ad esempio loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancelsono tutte le etichette appartenenti ad un dialogo Carica file. Sebbene questa convenzione di denominazione sottolineata non sia la più comune, la privilegiamo rispetto a convenzioni più standard perché migliora la leggibilità e la "raggruppabilità": nota quanto sia facile vedere a quale elemento appartengono le etichette e che cosa rappresenta ciascuna etichetta, rispetto alle etichette di nome loadFileLoadButton, loadFileNameLabele loadFileCancel. Potresti pensare che la differenza non sia così grande, ma quando hai migliaia di etichette, l'effetto composto ne vale la pena.

Commenti di intestazione: oltre al prefisso dei nomi delle etichette, aggiungiamo anche commenti di "intestazione" ai file di risorse per definire chiaramente i raggruppamenti di etichette. In questo modo, qualcuno che desidera modificare o aggiungere etichette specifiche relative a una particolare classe / sezione / modulo / etc può trovare tutte le etichette relative a quel particolare elemento in un solo posto, sotto un'intestazione, e può facilmente procedere con l'aggiunta o la modifica di etichette facilmente sapendo che non romperanno le traduzioni per altri elementi (IMHO, questo è anche un punto molto forte sul motivo per cui è necessario consentire la duplicazione).

I duplicati "giustificati" sono desiderabili: come accennato in precedenza, queste pratiche porteranno definitivamente a duplicare le etichette, ma non vediamo alcun problema (ulteriori informazioni su come gestirlo in Strumenti del commercio).

Come altri hanno sottolineato, un'etichetta in una lingua può essere tradotta in due o più modi diversi in altre lingue a seconda dei contesti in cui sono presentate. Se si "unificano" le etichette, il traduttore avrà difficoltà a trovare una singola etichetta che si adatta a tutti i contesti in cui si trova. Quindi, come lo vediamo, consentire duplicati "giustificati" aiuta a migliorare la qualità della localizzazione, purché non si riferiscano alla stessa cosa nello stesso contesto (questo è il significato di "giustificato").

Strumenti del mestiere: per essere il più efficace possibile quando fai le tue traduzioni, puoi costruire il tuo strumento che cerca etichette simili esistenti nei tuoi bundle e offrire le loro traduzioni come valori predefiniti per le nuove etichette, oppure puoi persino utilizzare servizi esistenti come questo , che forniscono strumenti come quello che ho appena citato, rendendo la traduzione di nuove etichette un gioco da ragazzi (ancora di più se vengono ripetute più volte, poiché lo strumento offrirà diverse opzioni di traduzione per impostazione predefinita per le nuove etichette ).

Riassumendo: duplicazione giustificata e raggruppamento di etichette in modo contestuale aiuta davvero i traduttori a svolgere il proprio lavoro. Grande tempo. Basta pensarci: avere un contesto aiuta molto il traduttore a selezionare la traduzione corretta. E consentire duplicati "giustificati" elimina il conflitto di dover selezionare una traduzione che si adatta male ad alcuni contesti (ma è comunque la migliore soluzione complessiva).

Spero che questo possa essere d'aiuto!

Quando l'ho fatto in passato, abbiamo seguito il percorso del file di risorse contenente frasi complete. Se la stessa frase esatta fosse usata ripetutamente alla grande, ma se fossero solo parole individuali all'interno di una frase, quelle parole sarebbero duplicate.

Eravamo legati a un framework in cui il file di risorse conteneva solo un elenco di frasi inglesi seguite dalla traduzione (con alcuni dati di indicizzazione alla fine per una rapida ricerca).

Per prompt di dati piccoli o pulsanti, come un nome di campo di "Codice postale" o un pulsante di "OK", memorizzerebbe la stringa "Codice postale" seguita dalla traduzione e la userebbe ovunque fosse richiesta quella stringa completa. Ma (a meno che non abbiamo rotto manualmente una stringa) non lo userebbe per "Codice postale" che appare in una frase.

Usando l'esempio del tuo codice postale, se provi a tradurlo da solo e lo sostituisci in tutte le frasi che lo usano otterrai una traduzione molto brutta.

Ad esempio, "Il codice postale deve essere inserito" potrebbe essere necessario tradurre l'equivalente letterale di "Il codice postale inserito deve essere" in un'altra lingua. Se tagli una frase non otterrai quell'inversione di parole richiesta in un'altra lingua.

Ecco perché alcune traduzioni mal fatte in inglese sembrano così ridicole, la persona che lo ha fatto ha solo tradotto le singole parole, non l'intera frase.

Abbiamo sempre trovato il modo migliore per tradurre le frasi nel loro insieme, senza romperle. Avevamo dei segnaposto per i dati che dovevano essere inseriti (ad es. "Il numero parte @ 1 è ridondante") e il traduttore poteva spostare il segnaposto nella posizione desiderata per una buona traduzione.

Tuttavia, abbiamo scoperto che consentire i luoghi che utilizzavano esattamente la stessa frase o lo stesso prompt di dati o la stessa etichetta del pulsante ecc. Andava bene per condividere le traduzioni. Questo non è mai stato un problema e ha risparmiato tempo / costi per il traduttore.

Il tuo pensiero sulla denominazione è buono.

obiettivi

• Definire un'etichetta comune (ovvero il nome della variabile) per il testo localizzato.
• L'etichetta dovrebbe essere "a misura di mente". Questo è ... altrettanto pratico, pur essendo inequivocabile.
• Le etichette dovrebbero seguire un formato coerente in modo da massimizzare la prevedibilità e il richiamo.

Implementazione

• Ridurre il carico cognitivo con l'uso coerente di abbreviazioni ben note (ad esempio, msg = messaggio, lbl = etichetta, btn = pulsante, ...)
• Gli strumenti presentano variabili / etichette in elenchi alfabetici, quindi la ricerca umana è la migliore quando le etichette correlate si raggruppano. Rendi i nomi gerarchici dal più generale al più specifico. (ad es. msgFileMissing, msgFileSaved, msgFileDeleted).
• L'inglese è una lingua ordinata da un verbo sostantivo. Molte (la maggior parte?) Altre lingue sono sostantivo-verbo. Noun-verb funziona meglio per il raggruppamento gerarchico.