Sto usando le tecnologie .Net e poiché la "traduzione istantanea" di ASP.Net non è davvero facile da fare con ResX, dato che deve essere compilata dopo ogni modifica, ci sono alcuni hack disponibili ( link ), ma così com'è, sono hack ... e sembrano avere problemi.
Così ho deciso qualche tempo fa (nel 2006, prima ancora di aver visto soluzioni come il link precedente) che stavo per impostare tutta la traduzione in un database SQL e memorizzare nella cache tutte le traduzioni necessarie in memoria per le prestazioni.
Il vero problema inizia quando voglio fare join tra tabelle con più campi che vengono tradotti. Fondamentalmente quello che faccio è memorizzare l'ID della traduzione all'interno di ogni campo, così posso aggiungere o modificare traduzioni in lingue in modo indipendente.
Ad esempio (non è reale ma dovrebbe mostrare il concetto):
ITEM(ItemID, TranslationReference_Name, TranslationReference_Use, ...)
TRANSLATION(TranslationReference, IDLanguage, Content)
Dopodiché, come puoi immaginare, quando voglio che una query SQL contenga, ho bisogno di fare join E questo è dove si sporca, perché non ho trovato nessun altro modo per farlo, e per ogni campo di ITEM che ha bisogno di una traduzione in una specifica IDLanguage, ho bisogno di fare un join.
Questo è un male per le prestazioni, perché la tabella TRANSLATION contiene migliaia di righe. Quindi ogni volta che devo fare un join completo per ogni colonna che necessita di una traduzione.
Inoltre, l'altro problema è che mi piacerebbe avere la traduzione inglese di base se una lingua specifica non è stata ancora tradotta, così come puoi immaginare che diventa molto più sporca per codificare ...
Non ho idea di come migliorarlo. Dovrei semplicemente rinunciare al concetto di join del database e tradurre ogni risultato del database sul mio codice .Net, facendo riferimento a un dizionario (che ho già) contenente la traduzione, quindi non richiederà alcun collegamento effettivo?
E questo è solo alcuni degli svantaggi di questa soluzione ... perché in uso reale, ho bisogno che gli utenti caricino i loro contenuti tradotti dinamicamente e gestiscano le versioni di queste traduzioni.
Keep in mind that I do not want to have N rows (N being the number of languages that this record is available) for the "ITEM" table, I know I could set 1 row by language, and have its translated content in nvarchar inside it, but that's not what I want because I need the same ID for every record, independant to the language it can be translated into.
Ho cercato attraverso il web e non ho trovato nessun buon articolo a riguardo.
Ho parlato con un altro sviluppatore che ha tradotto diverse lingue per il suo sito web di dati, se ricordo bene che stava usando più tabelle per la traduzione, non avrebbe archiviato IDLanguage all'interno di una tabella TRANSLATION globale, ma avrebbe diviso ogni traduzione in la propria tabella e fare qualcosa come iniettare la lingua nel codice SQL per cambiare, qualcosa come:
SELECT Content FROM Translation_EN ...
SELECT Content FROM Translation_FR ...
Sarebbe sicuramente più efficace di un join su una tabella completa, ma ciò non semplificherà il mio SQL pieno di join ...
Quindi probabilmente dovrei pensare alle alternative e ho bisogno delle tue idee e commenti su questo.
Grazie mille.