2012-04-10 23 views
6

Estoy construyendo una aplicación web multilingüe usando el patrón MVC como la posición inicial. La aplicación tiene una serie de formularios con los que los usuarios interactuarán y muchos de estos formularios tendrán campos que hacen una búsqueda de una tabla de base de datos, por ejemplo, "Provincia".¿Dónde encaja la traducción de idiomas en el patrón MVC?

Si necesito las opciones en estas listas que se mostrarán en el idioma de los usuarios en la pantalla, puedo ver un par de maneras de hacer esto:

  1. En el modelo. Al consultar el modelo, puedo proporcionar el idioma en el que deseo que se devuelvan los resultados. Esto permitiría que las traducciones se utilicen en cualquier lugar donde se muestren los datos del modelo sin cambios. Sin embargo, esto también significa que el modelo de la Provincia en mi ejemplo (además de todos los demás modelos de aplicaciones) ahora necesita saber cómo hacer traducciones de idiomas.
  2. En el controlador. Puedo consultar el modelo en la acción del controlador como de costumbre y luego crear un objeto 'Traductor' en el que puedo pasar los resultados antes de completar la acción. Esto implicaría que cada acción del controlador podría estar duplicando el mismo código de traducción, violando el principio DRY.
  3. En la vista. Como generalmente se espera que exista la presentación de la aplicación en las vistas, y el idioma del usuario no afecta la lógica de negocios del sistema, se podría argumentar que las traducciones de idiomas pertenecen aquí. Especialmente si se considera que una página también puede contener contenido estático que deberá traducirse. La desventaja de esto es que complicaría un poco las vistas, especialmente para los diseñadores de aplicaciones para el usuario que tendrán que trabajar con el nuevo código de traducción.

¿Existe una mejor práctica aceptada para las traducciones de texto en el patrón MCV para aplicaciones web? ¿Esto cambia para nada si estuviera cargando las opciones de la lista de selección a través de una llamada AJAX en lugar de al momento de cargar la página?

¡Gracias por la ayuda!

Respuesta

1

Si necesita traducir parte de su IU, entonces crearía un método de ayuda que leería un archivo de recursos y generaría una cadena traducida para esos recursos. P.ej.

@Translate("NewUserHeading") 

Por lo tanto, con respecto a la IU, tiene sentido manejar esto en la IU.

Si los datos que va a traducir en algún momento pueden mostrarse en un cliente Flash o en una aplicación móvil, debe ser traducido por un servidor y no debería tener nada que ver con su aplicación MVC.

0

Honestamente, cualquier interacción con una base de datos debe manejarse en el modelo, y eso es lo único que se maneja en el modelo. Interpretar/organizar esos datos debe manejarse en el controlador. Creo que se necesitaría más información sobre de dónde viene esta traducción y cómo funciona realmente para dar una respuesta sólida.

+0

Supongo que esto abriría el debate entre los modelos gordos/controladores delgados y los modelos delgados/controladores de grasa. ¿Estoy en lo cierto al decir que tu lógica de negocios estaría en los controladores? –

+1

@WallyLawless Nunca escuché a nadie argumentar a favor de los controladores de grasa. Los controladores son una capa delgada que se traduce desde la vista hasta el modelo y modelo para ver. Los controladores generalmente no se reutilizan, solo son pegamento, no llenen su código con pegamento. –

5

El mejor lugar para manejarlo está en la vista. Su pregunta solo hace referencia a datos dinámicos de la base de datos, pero también debe manejar la información estática en sus vistas también. Lo mejor es manejar ambos en el mismo lugar. Una práctica común en MVC para manejar múltiples idiomas son las cadenas de recursos, las vistas separadas para cada idioma o una combinación de ambos. Para información de la base de datos, las cadenas de recursos funcionarían bien. Debería almacenar un token en la base de datos para las opciones en la lista (ese token podría ser la traducción al inglés) y la vista obtendría la traducción adecuada de un recurso para el país/localidad especificado. Hay una buena explicación detallada sobre este enfoque en this blog post.

0

La vista solo mostrará las cadenas de un archivo de recursos. Incluir el archivo de recursos correcto para la configuración regional debería hacerlo. En las aplicaciones web, a menudo es un archivo JS de un solo idioma que define las cadenas de interfaz de usuario por localidad, por ejemplo, strings.en-us.js, strings.pt-br.js, etc.

Algunas cadenas provienen del servidor de forma dinámica, el controlador no necesita saber al respecto, el modelo solo debe tomar las cadenas localizadas y el retorno es como parte de la solicitud de datos.

Por lo tanto, está en la vista (si está estática) o en el modelo (si es dinámico). Los controladores deberían simplemente traducir los datos de la vista al modelo y del modelo a la vista

Cuestiones relacionadas