Неожиданно возник вопрос о смене архитектуры, к единому мнению никак не прийдем, поэтому интересно узнать побольше разных мнений.
Что есть?
"Шарпное" ОО приложение с большой иерархией классов, функциональными модулями и системой плугинов. Плугины разрешено писать только разработчику, некоторые модули используются в других тестовых проектах не требующих локализации. Плугины используют общие модули/классы для перекодировки, приема/передачи данных. Локализация была проведена с помошью плугина полуавтоматически загоняющего строки в ресурсы для каждого проекта. Все работает без проблем.
Но!, начальству не понравилось, что при отрисовке диалога с данными текст "берется" из многих проектов (по расположению классов). Поступила команда сделать все тексты в одном, максимум двух местах для упрощения изменений "главного" диалога. Пока мои аргументы против не подействовали.

Что нужно?
Оптимальное решение для локализации суб-проектов и приложения удобное для разработки, модификации, сопровождения.

Есть еще много деталей, но не хочу пока "засорять" вопрос.

AN>Что нужно?
AN>Оптимальное решение для локализации суб-проектов и приложения удобное для разработки, модификации, сопровождения.
Во-первых, абстрагируйтесь от места хранения ресурсов локализации. Напишите общий интерфейс ResourceLocator, в плагинах получайте доступ к реализации локатора через DI и работайте только через локатор. Тогда вам будет все равно, где что хранится — смена хранилища сведется к изменению реализации локатора.

Во-вторых, очевидно, что жизненный цикл ресурса должен совпадать с жизненным циклом кода, его использующего. Если у вас плагины могут жить независимо от приложения, ресурсы нужно хранить рядом с кодом без вариантов. Тривиальный пример, который должен убедить в этом начальство (если конечно это применимо к вашему софту): приложение загрузило новую версию плагина, в плагине появилась новая кнопка. Если подпись к кнопке не загрузилась, бедные китайские пользователи будут учить русский или английский (не забудьте написать о бесплатных уроках языка на коробке). Если подпись к кнопке пришлось загружать в виде общего компонента со всеми подписями приложения, придется делать варианты локализации на любую возможную комбинацию версий плагинов. Все хорошо только в случае, если подпись хранилась прямо в плагине.

В-третьих, приложение для редактирования ресурсов может использовать тот же самый ResourceLocator, чтобы прозрачно работать с несколькими размещениями ресурсов. Вашему начальнику, ведь, на самом деле хочется, чтобы весь текст редактировался, а не хранился в одном и том же месте. Ему нужен в первую очередь удобный инструмент для контроля за локализацией продукта — ну так дайте ему этот инструмент, и все вопросы будут сняты.

Здравствуйте, AlexNek, Вы писали:

AN>Что нужно?
AN>Оптимальное решение для локализации суб-проектов и приложения удобное для разработки, модификации, сопровождения.

А сделать отдельную сборку с ресурсами, к которой будут обращаться все остальные сборки? Или вообще отдельно resx положить?

Здравствуйте, gandjustas, Вы писали:

g> AN>Что нужно?
g> AN>Оптимальное решение для локализации суб-проектов и приложения удобное для разработки, модификации, сопровождения.

g> А сделать отдельную сборку с ресурсами, к которой будут обращаться все остальные сборки? Или вообще отдельно resx положить?
Как это сделать, вопрос скажем так, вторичный. Отдельная сборка с ресурсами это и есть глобальное хранение.
Для начала желательно определится с удобной моделью распределения данных. "По — проектная модель" удобна с точки зрения разработки, локализации и обновления бинарников. Но в ней затруднено быстро решить задачу типа "Вот в этом диалоге нужно исправить А на Б" малознакомому с проектом человеку. "Глобальная модель" хорошо решает данную задачу, но дает проколы во всем остальном. Вот и вопрос есть ли что оптимальное между этими двумя моделями? Я пока не вижу.

Здравствуйте, Baudolino, Вы писали:

B> AN>Что нужно?
B> AN>Оптимальное решение для локализации суб-проектов и приложения удобное для разработки, модификации, сопровождения.

B> Во-первых, абстрагируйтесь от места хранения ресурсов локализации. Напишите общий интерфейс ResourceLocator, в плагинах получайте доступ к реализации локатора через DI и работайте только через локатор. Тогда вам будет все равно, где что хранится — смена хранилища сведется к изменению реализации локатора.
Вообще то это уже реализация при которой все равно нужно решить где хранить тексты
и что делать с диалогами.

B> Во-вторых, очевидно, что жизненный цикл ресурса должен совпадать с жизненным циклом кода, его использующего. Если у вас плагины могут жить независимо от приложения, ресурсы нужно хранить рядом с кодом без вариантов. Тривиальный пример, который должен убедить в этом начальство (если конечно это применимо к вашему софту): приложение загрузило новую версию плагина, в плагине появилась новая кнопка.
У нас немного не так, но я назвал это "проблемой обновления".
B> Если подпись к кнопке не загрузилась, бедные китайские пользователи будут учить русский или английский (не забудьте написать о бесплатных уроках языка на коробке). Если подпись к кнопке пришлось загружать в виде общего компонента со всеми подписями приложения, придется делать варианты локализации на любую возможную комбинацию версий плагинов. Все хорошо только в случае, если подпись хранилась прямо в плагине.

B> В-третьих, приложение для редактирования ресурсов может использовать тот же самый ResourceLocator, чтобы прозрачно работать с несколькими размещениями ресурсов. Вашему начальнику, ведь, на самом деле хочется, чтобы весь текст редактировался, а не хранился в одном и том же месте. Ему нужен в первую очередь удобный инструмент для контроля за локализацией продукта — ну так дайте ему этот инструмент, и все вопросы будут сняты.
Инструмент редактирования, можно сказать есть, существующий плугин генерирует экзель файл. Проблема в том что редактировать начальство "может" только то, что видит. А когда человеку нужно искать в десятке мест мест где находится нужный текст, и еще потом решать какое из двух предложений "данные загружаются" нужно изменить, то это начальство раздражает.
Кстати, какой сейчас процесс работы.
Когда программисту нужна строка от просто пишет a = "строка";
А когда наступает время локализации, плугин просто заменяет вызов на a = xyz(...); либо на a = "строка"; //ПРОПУСТИТЬ, в зависимости от желания пользователя.
При этом плугин можно запускать в любое время. Диалоги локализируются почти таким же образом. Затем плугин генерирует экзел файл который посылается в переводчикам. Переведенный файл просто импортируется. Нет никаких проблем работать дальше пока перевод не готов.
То бишь удобство, как для программиста там и для "локализатора" налицо. Ну и пропустить, что довольно сложно.