Есть проект(VB.Net, не один, а несколько exe). Пока чисто EN (все тексты, т.е. Label, MsgBox и т.п. в код).
Надо сделать, чтоб была возможность менять язык.

В предшественнике (VB6) было тупо две версии: EN и RU. При этом я тратил много времени при переходе от версии к версии. Либо добавлял функциональные коды в старые RU. Либо полностью по новой менял EN на RU в новой EN-версии. И то и другое -гимор. В итоге крайние RU-версии выходили с задержкой на 1-2 месяца после EN. Ну, в VB6 был еще нехороший ньюанс - прога НЕ Юникод, поэтому подстройка языка OS (Язык для Юникод-программ) была как-бы обязательна для нормального функционирования.

Есть еще ньюанс. Ко мне неоднократно обращались всякие там немцы, итальянцы, греки, китайцы и т.д. на тему перевода проекта. Т.е. понятно что я кроме EN ничего не знаю, гугл не вариант, да и гиморно, но суть в том что люди готовы сами править "языковые файлы" для своих местных пользователей, только скажи "где лежит".

Еще ньюанс: я местами злоупотребляю в коде:
Т.е. например: 1) могу слать сообщение в окно, закрывать его и т.п. на базе того что написано в шапке окна(напр. MyProga Control Panel/Панель управления MyProga). 2) Код может делать выводы на базе какого-нибудь текста в комбобоксе (например Option1/Option2 Вариант1/Вариант2). 3) Какое-нибудь yes/no в таблице в RU может отображаться да/нет, и этому соответствовать true/false в файле настроек, но EN/RU используют разный код и т.д.

Таким образом, стандартные решения когда в ресурсы забиваются кривые гуглопереводы Немецкий/Испанский и выбор ограничен 2-3-мя языками меня устраивать не может.
Надо, чтоб продвинутый пользователь имел возможность добавить свою локализацию (ну допустим английскую я сделаю чтоб было что редактировать, русскую тоже можно сделать для примера), причем у него не возникало технических сложностей с редактированием всяких там ресурсов, xml и прочей хрени.

Я предполагаю сделать так:
1) В настройках проги выбирается файл (ну либо папка с набором файлов языка со стандартными именами).
2) Предполагаю что файл языка - это стандартный ini-файл, у меня проблем с API при работе с ini-файлами нету.
[Section1]
TextValue1="My Text 1"
TextValue2="Мой текст 2"
[Section2]
3) При загрузке exe-шник читает значения из этого ini и присваевает их элементам/переменным, если файл не указан, значение не задано, то используется дефолтное английское.

Почему предполагаю несколько ini в папке -чтобы не тормозил при загрузке от большого количества строк, если скажем 10 exe-шников.
Почему ini - потому что он интуитивно понятен для редактирования простым смертным.
Есть еще ньюанс, чтоб этот ini был в Юникоде, потому что по дефолту они в ANSI, но W-ф-ции никто не отменял, думаю разберусь как это обделать чтоб проблем не возникало.

Сойдет такой вариант?
Или какие другие еще идеи?

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

Т.е. работа по-любому предстоит нехилая, но думаю будучи сделанной один раз она того стоит.
Но надо определиться с реализацией (как технически буду это делать).

Какие соображения?

Сон Веры Павловны https://msdn.microsoft.com/en-us/library/y99d1cd3(VS.80).aspx
Ну я то топики на эту тему проглядел и в эту ссылку тыкался уже.
Это стандартный вариант который мне не подходит, о чем написал выше.
Юзеры ресурсы будут править? Да и самому неохота в изучение этого влезать.

Изопропилесть вариант - держать все тексты в СУБД
никакой файлопомойки +
А чем СУБД-помойка лучше файлопомойки?
Типа быстрее грузиться будет?
Ини вроде тоже быстро грузятся, вряд ли там будет больше 1000 строк.

"Дать пользователю интерфейс" - слишком большие трудозатраты.
Если пользователь тупой, то ему и интерфейс не поможет.
А Ini вроде как он же и интерфейс(особенно если грамотно разложить по секциям и кинуть Original-EN из которого изначально и клонировать)
A=aaaa
B=bbbb
что тут непонятного?

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

Я вот чего думаю.
При смене языка требование перегрузить приложение целиком это нормальный тон?
Или все таки оно должно на ходу это делать.

Даже возьмем отдельно взятое окно (а у меня их к примеру несколько - отдельные exe).
Ну, labels ладно, я перерисую.

А вот у меня к примеру в таблице отображается yes или no, да или нет. И на основании этого отображаемого текста да/yes я сохраняю какую-то настройку как true.
И вот тут варианты:
1) либо я тупо закрываю прогу и запускаю ее заново, и она уже по новой знает что такое да и что такое нет
2) я оставляю критические yes/no и им подобные места непереведенными
3) я таки заменяю yes на да, при этом усложняя в общем-то простой код до безобразия.
4) я переписываю подобные места кода, дублируя например текст да/нет какими-нибудь тагами, что в общем то опять же вариант 3 только более приличный. Но опять же путаницы там хватит.

Проще конечно первый вариант, он почти не требует гавновозни со строками, от которых зависят "вычисления".
Просто при старте присваиваем
str_yes="да", str_no="нет" и работаем уже с этими str_yes/str_no.

ViPRosДмитрий77,ну с yes no - на тебя не похоже (какой то детский лепет), слова ничего не значат, это просто представление инварианта
Не, ну как,
при загрузке читаю настройки.
Т.е. если у меня в ini написано a=1, то я
в какую-нибудь istview-report пишу "да", допустим я могу щелкнуть по этой строчке ListView и поменять через форму через RadioButton "да" на "нет".
Потом нажму на Save, из ListView прочитается "нет",
в ini записывается a=0
И вот прикинь какая хреновая фигня возникает, когда я внезапно меняю язык отображения на другой.
Это я для примера привел.

Изопропилодин хер пересчитывать координаты и размеры нужно
с этим есть определенная задница.
Подогнать размеры label так, чтоб влезал английский или русский я смогу. Какую-то универсальность это уже дает.
А уж у китайца его custom иероглифы куда-то не влезут, ну иж извините, пускай сокращает текст.
Просто чего-то высчитывать для каждой label -это перебор и под все потенциальные языки все одно не угадаешь.

Ну, а насчет "перезагрузки", подумаю. Без нее конечно стиль получше будет. Но при этом увеличивается вероятность случайной ошибки, из-за того что чего-то не предусмотрел.

Я вот о чем задумался.
Программа читает "языковые настройки" в основном при старте /при старте основной формы. Ну, я делаю немного не так: при загрузке второстепенной формы считывается "язык" относящийся к этой форме.
Плюс - что зачем читать, если форма не будет загружена, а также меньше извращений если таки надумаю менять язык "на лету".
минус - то что "язык" загружается несколько раз, если пользователь вызывает эту форму несколько раз.

Это так, вступление. А вопрос в чем.
Если я считываю "язык" в статическую Label, здесь без разницы (новой памяти не выделяется).
А вот если у меня MsgBox, то я должен держать String переменную под каждый текст (без перевода этот текст зашит в код и вызывается по мере необходимости).
В большом exe у меня этих текстов может быть несколько десятков, а то и пара-тройка сотен, среди них могут встречаться и не очень короткие.
Т.е. я стало быть резервирую кучу памяти под этот набор.
Спички? Или критично и стоит задуматься?

P.S. Альтернативный вариант -считывать "язык" на лету по мере необходимости оттуда где лежит. Но издержки в том, что мне придется разбрасывать "код чтения" (обращение к "ресурсам") по всей проге (а это мусор, с которым потом сложно работать), и понятно я этого не хочу. Гораздо удобнее когда все состредоточено в одном или нескольких понятных местах. И потом есть "дефолтный" (не связанный с "ресурсами") основной вариант, который тупо вырубает все "языковые загрузки из ресурсов", и понятно что условие тоже лучше прописывать один раз, а не для каждой String.

ИзопропилДмитрий77 Т.е. я стало быть резервирую кучу памяти под этот набор.
Спички? Или критично и стоит задуматься?
спички
OK, успокоил.