Локальное приложение.

В базе данных можно к ресурсам атрибуты приписать (таблицу создать для каждого типа), потом запросы делать по атрибутам. Но сложно - надо всё это делать, возиться.

В resx никакие атрибуты задать нельзя, есть лишь имя ресурса, его значение (строка, картинка и т.д.) и комментарий. Но просто, потому что вся инфраструктура уже встроена - достаточно добавить resx файл и легко потом из него доставать данные, не создавая подключение к БД (пусть даже локальной).

Например, хочу хранить локализованные строки. По концу имени файла определяется локаль:

Менеджер ресурсов сразу достаёт из нужного файла, основываясь на текущей культуре запущенного приложения:

var rm = new System.Resources.ResourceManager(resourceType);

rm.GetString(resourceName);

GetString returns the value of the resource localized for the caller's current UI culture, or null if name cannot be found in a resource set.

Культуру можно принудительно переключить при запуске:

Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");

Кто как обычно делает? Вообще, это нормальная практика хранить в resx много больших картинок, или считается устаревшим, и сейчас всё через БД делается?

Один из аргументов для локализованных строк в обычных текстовых файлах вместо resx или БД - можно легко отдавать переводчикам и вставлять обратно.

Почитал тут

asp.net - .resx vs database vs custom solution for providing Localization/Globalization - Stack Overflow

Получается, это силно зависит от проекта и кто над ним работает. resx надо перекомпилировать каждый раз - т.е. снова выгружать на сервер или в магазин приложений или ещё как доставлять обнову. Если ресурсы тянутся из БД, то можно обновить лишь её. Но опять же, только до тех пор, пока сама схема БД не поменяется - тогда поменяются и запросы из приложения, а значит обновлять придётся и само приложение.

Вобщем, как ни крути, если и сами ресурсы будут часто меняться, и схема их хранения, то обновлять придётся всё постоянно. Поэтому компилятся ресурсы в само приложение или подтягиваются из рядом лежащего файла или удалённой БД - не особо важно.

Что касается переводчиков, то всё если ресурсы в БД, всё равно придётся как-то их оттуда доставать и отдавать переводчикам, и потом обратно ложить.

Остановился пока на resx, как самом простом варианте. По мере работы с ним будет видно, нужна ли БД или какое другое решение.

Локальное приложение.

Плясать нужно отсюда и от способа локализации приложения.

Для десктопа полно вариантов когда строки автоматом ищутся/меняются.

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

когда-то нужно было отроязычить (даже четвероязычить с учетом английского) wpf приложение. словарь какой-то создал и оттуда брал тексты. даже где-то приложение написал для управления этими текстами. могу поискать, если еще найду. было очень удобно.

что было неудобно - нужно было подстраивать контролы по самым длинным текстам, или делить на две строки, в общем, выпендреж, если на одном языке "дох", а на другом для того же "не, все-таки да".

решение непринципиально. лишь бы все понимали, как пользоваться. тексты не так часто меняются.

В WPF же контролы растягивающиеся можно делать. А контейнеры (панели), в которые они помещаются, обычно в scroll viewer оборачиваются, чтобы их прокручивать можно было.

Ещё вот что мне всегда не нравилось в этих стандартных ресурсах, которые МС уже сто лет как не развивает и нужно каждый раз руками подписывать

PublicResXFileCodeGenerator вместо дефолтного

ResXFileCodeGenerator, что нет нормального встроенного механизма для хранения данных для свойств сущностей. Хранилище этих встроенных ресурсов - тупо подобие словаря "name - value", где name выступает в роли ключа, а хотелось бы "key - value - name - description - etc.". Т.е. чтобы как типа в базе данных - табличка, чтоли, но не база данных. Поэтому приходится городить на каждую запись в таком ресурсе Property1Name, Property1Description, Property1Value - и так по каждой проперти. Или придумывать формат хранения, где через условный разделитель вводить все эти данные в одну строку, а потом доставать и сплитить.

Короче, либо костыли, либо БД (оверкилл для такой задачи), либо кастомное хранилище (оверкилл для такой задачи). Т.е. работать в принципе можно, но хочется идеального.

но хочется идеального

За всё надо платить чем то.

Кто как обычно делает?

Локальное приложение имеется ввиду десктопное? Ну обычно в ресурсы всё запихиваю, но раньше во времена Visual Basic 6.0 в нашей программе был перевод на несколько языков в БД Microsoft Access 97, если немногопользовательская программа, то если хотите можете использовать SQLite3 https://www.nuget.org/packages/sqlite/, там нужно 2 таблицы - 1 таблица - язык-страна, 2 таблица - перевод. Перевод в БД хранили, чтобы клиенты сами могли перевести на другие языки. А ещё раньше тоже во время Visual Basic 6.0 как-то даже в ini файл запихивал см. http://plssite.ru/csharp/csharp_ini_files_article.html.

кто как обзывается, тот так сам называется... маску ношу чтобы не заразить антиваксеров... Дневник тяжелобольного инвалида