Creazione di un database di traduzione di stringhe per più progetti (interni)

Nota preliminare n. 1: non ci stai dicendo come vengono mantenute le traduzioni al momento

Nota preliminare n. 2: il tuo database non è normalizzato. Qualunque sia la soluzione che stai per intraprendere, prima normalizza il tuo database . In seguito ti imbatti in terribili problemi di manutenzione se non lo fai ora

Questo è quello che farei.

1. Riscrivi la tua chiamata di traduzione in modo che riporti un ID di programma sul server

2. Il traduttore back-end inserirà la stringa nella tabella del database se non esiste ancora e la taggerà con l'id del programma

3. Se la stringa esiste già, verrà aggiornata solo se l'ID del programma corrisponde all'ID del programma originale con cui è stata creata la stringa. In caso contrario, restituisci una notifica di conflitto.

Variazioni:

• Potresti usare un 'ID sviluppatore / ID traduttore' invece di un ID programma. Lo considero migliore perché ci sono persone che conoscono una lingua straniera e quelle che pensano di sapere. Solo il primo gruppo ha i diritti di modifica.

• Potresti voler memorizzare gli ID di tutti i programmi che usano la stringa nel DB, in modo da sapere quali programmi sono in conflitto.

• Potresti estendere questo pensiero di "proprietà" a ogni singola lingua: una persona può fare l'inglese, l'altra olandese.

• Una volta normalizzato il tuo database, aggiungi complessità di costruzione come "Il programma A è in Lingue 1,2,3; B è in 3 e 5"

Ti suggerisco anche di scrivere un programma separato di "manutenzione della traduzione" che ti mostrerà le traduzioni mancanti ecc. Una volta l'ho fatto con un'autorizzazione a 2 livelli: ogni traduzione deve essere controllata da una seconda persona (di solito un madrelingua).

Poiché fanno riferimento a un 'this' ... puoi assegnare il nome del progetto una volta a 'this' (tramite il costruttore, ad esempio) e l'interfaccia per le funzioni di traduzione non cambierebbe per i codificatori. Sotto il cofano, aggiunge solo il nome del progetto alla query del database. In alternativa, puoi fornire "questo" un mezzo per conoscere il nome del progetto da solo. Dipenderà davvero da come hai strutturato le tue classi.

Per la memorizzazione, puoi fare qualcosa come:

1 ! hello-world ! nl-EN ! Hello World  ! *
2 ! hello-world ! nl-EN ! Howdy, World ! CowboyApp
3 ! hello-world ! nl-EN ! Arrgh        ! PirateApp

Utilizza un carattere jolly per applicare una traduzione generale a tutte le app, ma il nome specifico dell'app quando desideri sovrascrivere una traduzione per una determinata app. Ciò manterrà le duplicazioni al minimo.

Per vedere quale programma sta usando quali traduzioni, ora lo sai - se non vuoi passare attraverso e gatteggiare manualmente tali informazioni, puoi registrare le richieste di traduzione.

Se tutti i tuoi progetti sono scritti in C # e tutte le chiamate ai traduttori sono simili a questa

this.Translate("hello-world")

dove "ciao-mondo" è la chiave nella tua tabella di traduzione, non dovrebbe essere troppo difficile scrivere un piccolo scanner del codice sorgente usando espressioni regolari per trovare tutte le chiamate del traduttore e assegnare le parole chiave ai corrispondenti nomi di progetto. In questo modo, non devi modificare alcun codice esistente o le interfacce del traduttore.

A seconda della struttura reale del tuo programma, in alternativa potrebbe essere più semplice estrarre tali informazioni dal codice IL degli assembly. Ho fatto qualcosa di molto simile qualche tempo fa, anche per scopi di traduzione, usando questo codice di esempio per analizzare gli assembly.