vb.net - puede - que es un archivo de recursos

Localización.NET; Lenguaje alternativo al usar ResourceManager

Question

Recientemente estuve profundizando en la localización con .NET. Esencialmente, aprendí cómo personalizar un formulario (usando las propiedades de Idioma y Localizable) y luego cambiar la cultura en consecuencia.

Sin embargo, descubrí que cuando migraba mis cadenas codificadas en inglés a los archivos de recursos generados automáticamente y usaba .GetString ("Clave"), bueno, digamos que no era feliz: P.

Decidí crear un conjunto separado de archivos resx dedicados exclusivamente a las traducciones de cadenas codificadas. Siguieron la convención / requisito de [nombre]. [Código de cultura] .resx. Hice de estos para cada idioma relevante; por ejemplo, appstrings.de.resx (para alemán) y appstrings.resx (como línea base invariable).

Para utilizar estos nuevos recursos, creé una instancia de ResourceManager y Resource Set

Dim resManager As New ResourceManager("LanguageTest.appstrings", Assembly.GetExecutingAssembly)
Dim resSet As ResourceSet = resManager.GetResourceSet(My.Application.UICulture, True, True)

La cultura de UI actual se estableció (por ejemplo, en alemán) usando

My.Application.ChangeUICulture("de")

Problema original

A menos que resSet.GetString ("Key") se defina explícitamente en appstrings.de.resx , devolverá una cadena en blanco. ¿Hay alguna forma en que pueda recurrir a appstrings.resx (donde "Key" existe), que supuse que sería la línea base predeterminada?

Actualizar

Rhapsody hizo una sugerencia a continuación, mientras que el consejo real en sí no funcionó, de hecho provocó un punto interesante, usando resManager.GetString ("Key") en lugar de resSet.GetString ("Key"). Esto parece funcionar sin defectos hasta el momento. Es decir, se devuelven los valores presentes en el archivo de idioma especializado, mientras que los valores "faltantes" se retrotraen a la cultura predeterminada cuando se accede mediante una sola tecla.

Problema subsiguiente

El único problema restante sería si el impacto en el rendimiento del uso de ResourceManger en comparación con un ResourceSet en caché será perjudicial.

Answer 1

Puedes intentar declarar un Culture por defecto para la aplicación como se muestra a continuación

[assembly: NeutralResourcesLanguageAttribute("en-US", UltimateResourceFallbackLocation.Satellite)]

Este código declara que su cultura predeterminada es en-US. En su ejemplo, si la cultura actual es "de-DE" busca recursos en "de-DE", luego busca la cultura "de" padre y así sucesivamente y Ultimamente va al archivo de recursos de cultura definida (en-US) . ver MSDN para estrategias de respaldo por resourceManage. El código anterior va normalmente en assenblyInfo.cs. El segundo parámetro le dice al administrador de recursos dónde se encuentran los recursos ubicados en el ensamblaje principal o satélite.

Desafortunadamente, en esta solución, debe usar un nombre cultural, no el nombre del archivo de recursos. sin embargo, puede extender RM para usar un recurso específico por nombre de archivo, pero es mucho más sencillo seleccionar una cultura predeterminada y cambiar el nombre de su archivo de recursos a esa cultura y tiene la solución lista para usar.

Answer 2

Tratar

Public Function GetString(ByVal Name As String) As String
Return My.Resources.Strings.ResourceManager.GetString(Name)
End Function

Where Strings es el nombre de los archivos resx en su proyecto. Esto devolverá automáticamente el valor de referencia cuando no esté disponible para la cultura actual.

Es un ejemplo fácil, es posible que desee hacerlo más a prueba de tontos.

Answer 3

Una vez creé una aplicación web que tenía en EE. UU. Como el lenguaje alternativo, pero tenía otras más específicas, como .de, basadas en la configuración del navegador web de los usuarios.

Básicamente para que funcione, configuré el xml en web.config

<globalization uiCulture="auto" culture="auto" requestEncoding="utf-8" responseEncoding="utf-8"/>

A partir de ahí, utilicé el ResourceManager estático interno del archivo .cs que se proporciona con su idioma predeterminado, por ejemplo

Resources.<ResourceFileName>.ItemSearchNoResultsErrorText

y en archivos .aspx:

<%$ Resources:<ResourceFileName>, TimeSelect %>

Según tengo entendido, entonces es significativo dónde vive su archivo .cs que contiene la clase ResourceManager, ¿está detrás del archivo de idioma .de o del lenguaje alternativo? Como se compila como un conjunto de satélites separado, depende de dónde se compila la clase .cs y del ensamblaje de satélites del que forma parte.

Como regla, siempre he tenido la clase ResourceManager como un código en el idioma en-US porque ese es el que quiero usar como el lenguaje alternativo si no se encuentran los más específicos.

Al utilizar esta configuración, nunca obtuve un valor en blanco, siempre utilizo el lenguaje alternativo, aunque cambio los ensambles satelitales en tiempo de ejecución.