Dove si adatta la traduzione della lingua nel pattern MVC?

Question

Sto costruendo un'applicazione web multilingue utilizzando il pattern MVC come posizione di partenza. L'applicazione ha un numero di moduli con cui gli utenti interagiranno e molti di questi moduli avranno campi che eseguono una ricerca da una tabella di database, ad esempio "Provincia".

Se ho bisogno le opzioni in questi elenchi da visualizzare nella lingua degli utenti sullo schermo, posso vedere un paio di modi per farlo:

1. Nel modello. Quando si esegue una query sul modello, è possibile fornire la lingua in cui desidero restituire i risultati. Ciò consentirebbe di utilizzare le traduzioni ovunque i dati del modello vengano visualizzati senza modifiche. Tuttavia, questo significa anche che il modello Provincia nel mio esempio (più tutti gli altri modelli di applicazione) ora ha bisogno di sapere come fare le traduzioni linguistiche.
2. Nel controller. Posso interrogare il modello nell'azione del controller come al solito e quindi creare un oggetto "Translator" in cui posso passare i risultati prima di completare l'azione. Ciò implicherebbe che ogni azione del controllore potrebbe potenzialmente duplicare lo stesso codice di traduzione, violando il principio DRY.
3. Nella vista. Poiché la presentazione dell'applicazione è generalmente prevista nelle viste e la lingua dell'utente non ha alcun impatto sulla logica di business del sistema, è possibile fare una discussione sulla presenza di traduzioni linguistiche. Soprattutto considerando che una pagina potrebbe contenere anche contenuto statico che dovrà essere tradotto. Il rovescio della medaglia è che complicherebbe un po 'le viste, specialmente per i progettisti front-end che dovranno aggirare il nuovo codice di traduzione.

Esiste una best practice accettata in cui le traduzioni di testo appartengono al modello MCV per le applicazioni Web? Questo cambia del tutto se dovessi caricare le opzioni dell'elenco di selezione tramite una chiamata AJAX anziché a tempo di caricamento della pagina?

Grazie per l'aiuto!

Answer 1

Se è necessario tradurre parte dell'interfaccia utente, creerò un metodo di supporto che dovrebbe leggere un file di risorse e generare una stringa tradotta per tali risorse. Per esempio.

@Translate("NewUserHeading") 

Quindi, per quanto riguarda l'interfaccia utente, ha senso gestirlo nell'interfaccia utente.

Se i dati che si intende tradurre in un dato momento potrebbero essere visualizzati in un client Flash o in un'app mobile, devono essere convertiti da un server e non dovrebbero avere nulla a che fare con l'applicazione MVC.

Answer 2

Onestamente, qualsiasi interazione con un database deve essere gestita nel modello e questa è l'unica cosa gestita nel modello. Interpretazione/organizzazione di tali dati devono essere gestiti nel controller. Immagino che sarebbero necessarie maggiori informazioni su dove questa traduzione provenga e su come ciò possa davvero dare una risposta solida.

Answer 3

Il punto migliore per gestirlo è nella vista. La tua domanda fa riferimento solo ai dati dinamici dal database, ma devi anche gestire le informazioni statiche nelle tue visualizzazioni. Meglio gestire tutti e due nello stesso posto. Una pratica comune in MVC per la gestione di più lingue è costituita da stringhe di risorse, visualizzazioni separate per ciascuna lingua o una combinazione di entrambi. Per informazioni dalle stringhe di risorse del database funzionerebbe bene. Si memorizzerebbe un token nel database per le opzioni nell'elenco (il token potrebbe essere la traduzione inglese) e la vista otterrebbe la traduzione appropriata da una risorsa per il paese/locale specificato. C'è una buona spiegazione dettagliata su questo approccio in this blog post.

Answer 4

La vista mostrerà solo le stringhe da un file di risorse. Includere il file di risorse corretto per le impostazioni internazionali dovrebbe farlo. Nelle applicazioni Web, è spesso un file JS in una sola lingua che definisce le stringhe dell'interfaccia utente per locale, ad es. Strings.en-us.js, strings.pt-br.js e così via.

Alcune stringhe provengono dal server in modo dinamico, il controller non deve saperlo, il modello deve semplicemente afferrare le stringhe localizzate e il reso è come parte della richiesta di dati.

Quindi è nella vista (se è statica) o nel modello (se è dinamico). I controllori dovrebbero semplicemente tradurre i dati dalla vista al modello e dal modello alla vista