Почему вы используете ветки для обработки локализации? имхо это безумие
Существует несколько способов локализации без использования одной кодовой базы для каждого языка.
Например. Создав собственный движок представлений поверх существующего, вы можете загружать представления из внешних сборок. Или вы можете создать одно представление для каждого языка.
Вы также можете использовать строковые таблицы в своих представлениях, чтобы сделать их локализованными.
Абстрактное представление вещей. Например. Файлы aspx / cshtml, javascript, css и т. Д.
Javascripts: у меня есть один javascript со всей моей логикой, который использует переменные вместо строк для отображения сообщений. Таким образом, я могу загрузить другой javascript перед логическим скриптом (например, myplugin.sv.js до myplugin.js, чтобы получить шведский язык.
Наиболее распространенный способ для файлов aspx / cshtml - использовать в них строковые таблицы.
Локализовать CSS? Почему?
Абстрагирующие контроллеры
да? Зачем? Используйте здесь также строковые таблицы.
Как вы справляетесь со сложностью наличия всех ваших кодов для каждой страны в одной отрасли?
Не используйте ветки.
Как вы управляете переключениями функций для каждой абстракции?
да
Как выбрать подходящую страну при развертывании?
Используйте один и тот же сайт для всех языков. Для выбора языка используйте IP-адрес, заголовок Accept-Language http или языковые предпочтения пользователя. Язык указывается настройкой Thread.CurrentThread.CurrentCulture и Thread.CurrentThread.CurrentUICulture
Как вы запускаете модульные тесты для конкретной страны?
Не. Логика должна быть такой же.
Обновление в ответ на ваш комментарий
Я написал довольно много систем, в которых контент динамически загружается в приложение / службу. Я никогда не использовал разные базы кода, даже если разные клиенты используют разные функции в мультитенантных системах (SaaS).
Прежде всего, вам нужно принять две вещи:
a) Весь контент загружается постоянно (не о переводах, а о возможностях).
б) Используйте надлежащие / стандартные методы локализации, но нет необходимости переводить все функции на все языки.
Что вы делаете, просто контролируете, какой контент загружать, и используете стандартные методы для получения переведенных функций. Управление осуществляется путем проверки текущего языка (Thread.CurrentThread.CurrentCulture.Name) или любого самодельного элемента управления.
Задайте новые вопросы, чтобы получить больше деталей.
Обновление 2
Я бы не стал полагаться на IoC для предоставления специфичных для языка функций, но использовал бы для этого рефлексию и класс FeatureProvider.
Например, допустим, у вас есть функция с именем ISalaryCalculator, которая учитывает все местные налоговые правила и т. Д., Тогда я бы создал что-то вроде этого:
// 1053 is the LCID (read about LCID / LocaleId in MSDN)
[ForLanguage(1053)]
public SwedishSalaryCalculator : ISalaryCalculator
{
}
И есть FeatureProvider, чтобы загрузить его:
public class FeatureProvider
{
List<Assembly> _featureAssemblies;
public T GetLocalFeature<T>()
{
var featureType = typeof(T);
foreach (var assembly in _featureAssemblies)
{
foreach (var type in assembly.GetTypes().Where(t => featureType.IsAssignableFrom(t))
{
var attribute = type.GetCustomAttributes(typeof(ForLanguageAttribute)).First();
if (attribute.LocaleId == Thread.CurrentThread.CurrentCulture.LCID)
return (T)Activator.CreateInstance(type);
}
}
return null;
}
}
И чтобы получить функцию (для текущего языка):
var calculator = _featureManager.GetLocalFeature<ISalaryCalculator>();
var salaryAfterTaxes = calculator.GetSalaryAfterTax(400000);