Локализация .NET; Резервный язык при использовании ResourceManager

Question

Недавно я углубился в локализацию с помощью .NET. По сути, я узнал, как настроить форму (используя свойство Language и Localizable), а затем соответствующим образом изменить культуру.

Однако я обнаружил, что при переносе моих жестко запрограммированных английских строк в автоматически сгенерированные файлы ресурсов и использования .GetString ("Key") - ну, скажем так, это не очень понравилось: P.

Я решил создать отдельный набор файлов resx, предназначенных исключительно для жестко закодированных переводов строк. Они следовали соглашению / требованию [name]. [Culture-code] .resx. Я сделал из них для каждого соответствующего языка; например appstrings.de.resx (для немецкого языка) и appstrings.resx (в качестве инварианта базовой линии).

Чтобы использовать эти новые ресурсы, я создал экземпляр ResourceManager и Resource Set

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

Текущая культура пользовательского интерфейса была установлена ​​(например, на немецкий) с помощью

My.Application.ChangeUICulture("de")

---

Оригинальный выпуск

Если только resSet.GetString ("Key") явно не определено в appstrings.de.resx , он вернет пустую строку. Могу ли я в любом случае сделать это откатом к appstrings.resx (где «Ключ» существует), который, как я предполагал, будет базовой линией по умолчанию?

Обновление

Rhapsody сделала предложение ниже, хотя сам фактический совет не сработал, на самом деле он вызвал интересную точку, используя resManager.GetString ("Key"), а не resSet.GetString ("Key"). Это, кажется, работает без изъянов. То есть значения, присутствующие в специализированном языковом файле, возвращаются, в то время как «отсутствующие» значения возвращаются к культуре по умолчанию при доступе одним ключом.

Последующий выпуск

Единственная оставшаяся проблема заключается в том, будет ли влияние производительности на использование ResourceManger в отличие от кэшированного ResourceSet таким пагубным?

Answer 1

Вы можете попробовать объявить культуру по умолчанию для приложения, как показано ниже

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

Этот код объявляет, что ваша культура по умолчанию - en-US. В вашем примере, если текущая культура "de-DE", она ищет ресурс в "de-DE", затем ищет родительскую культуру "de" и т. Д., И Ultimatly переходит к файлу ресурса определенной культуры (en-US). , см. MSDN , чтобы узнать о запасных стратегиях от resourceManage. Приведенный выше код обычно идет в assenblyInfo.cs. Второй параметр сообщает менеджеру ресурсов, где находятся ресурсы, расположенные в основной сборке или сателлите.

К сожалению, в этом решении вы должны использовать имя культуры, а не имя файла ресурса. однако вы можете расширить RM, чтобы использовать определенный ресурс по имени файла, но его проще выбрать стандартную культуру и переименовать файл ресурсов в эту культуру, и у вас есть готовое решение.

Answer 2

Попробуйте

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

Где Strings - имя файла resx в вашем проекте. Это автоматически вернет базовое значение, когда оно не доступно для текущей культуры.

Это простой пример, вы можете сделать его более надежным.

Answer 3

Однажды я создал веб-приложение, в котором в качестве резервного языка использовался en-US, но есть другие, более специфичные, такие как .de, на основе настроек в веб-браузере пользователя.

В основном, чтобы все заработало, я установил xml в web.config

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

Оттуда я использовал внутренний статический ResourceManager из файла .cs, который предоставляется на языке по умолчанию, например,

Resources.<ResourceFileName>.ItemSearchNoResultsErrorText

и в файлах .aspx:

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

Насколько я понимаю, важно, где находится ваш файл .cs, который содержит класс ResourceManager, за языковым файлом .de или резервным языком? Поскольку он компилируется как отдельная сателлитная сборка, он зависит от того, где компилируется класс .cs и к какой сателлитной сборке он относится.

Как правило, у меня всегда был класс ResourceManager в качестве кода на языке en-US, потому что это тот, который я хочу использовать в качестве запасного языка, если более конкретные не найдены

Используя эту настройку, я никогда не получал пустое значение, он всегда использовал запасной язык, хотя я заменял спутниковые сборки во время выполнения.