asp.net - istringlocalizer - netcore set culture

.resx vs base de datos vs solución personalizada para proporcionar Localización/Globalización (5)

Como quizás sepa, el método predeterminado (que en realidad es la mejor práctica de la industria) para Localizar aplicaciones .Net es usar archivos de recursos (.resx en este caso). Si desea utilizar la base de datos, deberá escribir su propio ResourceManager.

A partir de esto, la respuesta debería ser obvia: utilice el estándar y no reinvente la rueda.

Es posible que se pregunte por qué la localización a través de archivos de recursos se convirtió en estándar para toda la industria. Bueno, hay muchas razones (demasiadas para mencionar aquí), la mayoría de ellas se refieren al proceso de Localización. La clave es que es penosamente difícil actualizar (es decir, corregir o instalar) las traducciones para la localización basada en bases de datos. Solo piense en lo que necesita para instalarlo: algún script SQL. ¿Sabes qué pasará si envías esto para traducir? ¿O incluso actualizarlo por error? Este tipo de archivos no son muy seguros para trabajar (y tienden a ser muy grandes), por lo que necesitaría crear algún tipo de generador (con un archivo de recursos como entrada, lo cual es totalmente diferente ... ) o tendrías que tener mucho cuidado (y rezar para que un traductor no rompa el archivo).

Es decir, la localización basada en bases de datos a veces es la única forma sensata de hacer las cosas: aquí es cuando se necesita implementar la denominada localización dinámica, que permite a los usuarios traducir cosas o agregar sus contenidos en múltiples idiomas.
Para la localización estática (escenario típico) use los archivos de recursos.

En mi oficina, hemos tenido un debate de larga data sobre Localización / Globalización y cómo manejarlo. Un lado empuja para la ruta del archivo Resource (.resx) integrado en ASP.NET, un lado empuja para una solución basada en base de datos. Un tercer grupo cree en rodar una solución personalizada.

Por supuesto, cada método tiene sus propios beneficios y desventajas únicos, y lo hemos discutido una y otra vez, sin llegar a un consenso real.

Entonces, lo planteo a la comunidad: en su experiencia, qué método proporciona la mejor combinación de los siguientes a medida que la aplicación crece:

Mantenibilidad
Extensibilidad
Rendimiento / escalabilidad

Además de solo consejos, también estaríamos interesados en cualquier proyecto de código abierto que también pueda ayudar a simplificar la pregunta. ¡Gracias!

Como todo lo anterior es cierto, quiero agregar algunas ideas adicionales.

Tiendo a utilizar la localización basada en .resx, cuando trabajo en proyectos / sitios web " estáticos " como Dashboards u otros sitios web pequeños, que se centran en un grupo de usuarios específico.

Cuando trabajo en proyectos más grandes y más " dinámicos " como tiendas, ofertas de servicios, etc. (especialmente cuando el contenido está localizado, no solo etiquetas) me gusta usar la localización de bases de datos.

Cuando se desarrolla en proyectos más grandes, cada idioma es mantenido por otra persona, que no necesariamente está en su proyecto (especialmente en proyectos comunitarios). Por lo tanto, el mantenimiento de diferentes idiomas se convierte en una verdadera molestia. Por otro lado, proporcionar a los usuarios una interfaz de usuario buena / fácil para actualizar su idioma también lleva mucho tiempo. Intenta encontrar un buen camino para tu proyecto.

El uso de resx es el mejor enfoque para algunos valores estáticos que no necesitan ser manipulados a través de la interfaz de usuario de la aplicación, pero si sus valores necesitan ser actualizados, la administración de bases de datos sería lo mejor para ellos. Para mí, sigue siendo una base de caso por caso. Pero uno de los blogs que he visto en Internet hizo que los archivos resx se actualizaran a través de la interfaz de usuario. http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html . Espero que esto te ayude.

La localización de la interfaz de usuario no se debe almacenar en la base de datos, es preferible usar el método estándar de resx porque esto le dará la flexibilidad de personalizar la interfaz de usuario de cada cliente / implementación, sin la necesidad de cambiar el servidor o la tienda mucha información sobre la personalización de cada cliente en la base de datos.

Con respecto a los datos (datos bilingües o multilingües), guárdelos en la base de datos y use la técnica adecuada para el contexto (tabla por idioma o columnas duplicadas para cada idioma).

Rick Strahl (An MVP MV) tiene un gran conjunto de herramientas para administrar la localización a través de la base de datos: ofrece la posibilidad de actualizar y modificar bajo demanda a través de un entorno controlado y hace mucho del trabajo pesado por usted. Histoolkit ofrece las siguientes características:

Proveedor de recursos de localización basado en datos

La localización basada en bases de datos le permite almacenar recursos en una base de datos de SQL Server.
La Administración de recursos basada en la web interactiva proporciona una administración en línea basada en la Web para que pueda editar y actualizar recursos mientras se ejecuta la aplicación
El control de edición de recursos asocia los iconos con cada control localizable y permite saltar directamente al formulario de administración con el identificador de recursos y la configuración regional seleccionados.
Resx Import and Export le permite importar recursos existentes de Resx, editarlos interactivamente con el proveedor de datos y luego exportarlos nuevamente como recursos de Resx.
Utilidades de localización como JavaScript Resource Handler, funciones para incrustar valores de script localizados y mucho más.

También resume muy bien los problemas here (he pegado algunas cosas buenas aquí, ¡no es mi trabajo!)

Para Resx o no para Resx
El mecanismo de almacenamiento de recursos predeterminado en .NET utiliza recursos basados en Resx. Resx se refiere a la extensión de archivo de archivos XML que sirven como entrada sin procesar para los recursos que son nativos de .NET. Aunque XML es el formato de almacenamiento de entrada que ve en Visual Studio y en los archivos .Resx, el formato de recurso final es un formato binario (.Resources) que el compilador compila en ensamblados .NET. Estos recursos compilados se pueden almacenar junto con el código en ensamblajes binarios o por sí solos en ensambles de satélite de recursos cuyo único propósito es proporcionar recursos. Normalmente, en .NET, los recursos de cultivo Invariant están incrustados en el ensamblaje de la base con cualquier otra cultura alojada en conjuntos de satélites almacenados en subdirectorios específicos de la cultura.
Si está usando Visual Studio, el proceso de compilación de recursos es prácticamente automático: cuando agrega un archivo .Resx a un proyecto, VS.NET compila automáticamente los recursos y los incrusta en ensamblajes y crea los ensamblajes de satélites junto con la estructura de directorios requerida para cada una de las configuraciones regionales admitidas. ASP.NET 2.0 amplía este proceso base automatizando aún más el modelo de servicio de recursos y compilando automáticamente los recursos de Resx que se encuentran App_GlobalResources y App_LocalResources y poniéndolos a disposición de la aplicación con un proveedor de recursos que es específico de ASP.NET. El proveedor de recursos hace que el acceso a los recursos sea más fácil y más consistente desde las aplicaciones ASP.NET.
El .NET Framework en sí mismo usa recursos .Resx para servir contenido localizado, por lo que parece natural que las herramientas que proporciona el framework hagan que las herramientas de creación de recursos estén disponibles para servir a este mismo modelo.
Resx funciona bastante bien, pero no es muy flexible cuando se trata de editar recursos. El soporte de herramientas en Visual Studio es bastante inadecuado para admitir la localización porque VS no proporciona una manera fácil de cruzar los recursos de referencia a través de múltiples configuraciones regionales. Y aunque el editor de diseño de ASP.NET puede ayudar a generar recursos inicialmente para todos los controles en una página, a través de la herramienta Generar recursos locales, solo funciona con datos en el archivo Invariant Culture Resx predeterminado.
Los recursos de Resx también son estáticos; después de todo, se compilan en un ensamblaje. Si desea realizar cambios en los recursos, deberá volver a compilar para ver esos cambios. ASP.NET 2.0 presenta recursos globales y locales que se pueden almacenar en el servidor y se pueden actualizar dinámicamente; el compilador de ASP.NET puede compilarlos en tiempo de ejecución. Sin embargo, si utiliza un modelo de implementación web precompilado, los recursos aún terminan siendo estáticos y no pueden modificarse en tiempo de ejecución. Entonces, una vez que terminas con la compilación, los recursos son fijos.
Cambiar los recursos en el tiempo de ejecución puede no parecer un gran problema, pero puede ser bastante útil durante el proceso de localización de recursos. ¿No sería bueno si pudieras editar recursos en tiempo de ejecución, hacer un cambio y luego ver ese cambio en la UI inmediatamente?
Usando recursos de base de datos
Esto me lleva a almacenar recursos en una base de datos. Las bases de datos son, por naturaleza, más dinámicas y puede realizar cambios en los datos en una base de datos sin tener que volver a compilar una aplicación. Además, los datos de la base de datos se comparten más fácilmente entre múltiples desarrolladores y localizadores, por lo que es más fácil realizar cambios en los recursos en un entorno de equipo.
Cuando piensas en la edición de recursos, básicamente se trata de una tarea de ingreso de datos: necesitas buscar valores de recursos individuales, ver todas las variaciones de idiomas diferentes y luego agregar y editar los valores para cada una de las diferentes configuraciones regionales. Si bien todo esto se puede hacer con el XML en los archivos Resx directamente, en realidad es mucho más fácil construir una interfaz de usuario en una base de datos que los archivos XML dispersos por todo el lugar. Una base de datos también le ofrece mucha más flexibilidad para mostrar los datos de recursos en diferentes vistas y hace que sea fácil hacer cosas como actualizaciones por lotes y cambiar el nombre de claves y valores.
La buena noticia es que los esquemas de recursos en .NET no son fijos y puede ampliarlos. .NET y ASP.NET 2.0 le permiten crear gestores de recursos personalizados (core .NET runtime) y proveedores de recursos (ASP.NET 2.0) para servir recursos desde cualquier lugar, incluso desde una base de datos.