2009-11-02 2 views
1

Мы поддерживаем веб-продукт, который мы продали нескольким различным клиентам. Мы поддерживаем сайт на родном и английском языках. В рамках технического обслуживания мы начали обновление до .NET 3.5, и хотя во время этого мы хотели бы иметь лучшую поддержку для дифференцированного макета/локализации в продукте.Обработка локализации + дифференциация клиентов

Мы стараемся не иметь логики клиента внутри кода. Например, мы стараемся избегать такого кода:

if (config.Customer = customer1) 
    SetupPageForCustomer1(); 
else 
    SetupPageForCustomer2(); 

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

SetupPageForCustomer(customer1) 

void SetupPageForCustomer(Customer c) 
{ 
    PageConfig pc = LoadPageConfig("config/" + c.Dir + "ThisPage.aspx.config"); 
    SetupPage(pc); 
} 

Мы обработали Разделение макета, позволяя страницам, нуждающимся в дифференциации, иметь usercontrol для каждого клиента, который загружается динамически на page_load. Локализация в настоящее время обрабатывается с файлами ресурсов, которые отлично работают. Поскольку мы поддерживаем два языка, каждая страница поставляется с двумя файлами ресурсов. Однако, если нам нужно различать текст на этих страницах для клиентов, мы получим (количество языков * количество клиентов) файлы ресурсов, которые кажутся очень полезными.

Ваши мнения по этому вопросу? Каков наилучший способ справиться с такими вещами?

ответ

1

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

+0

Это не меняет того факта, что нам понадобится огромное количество файлов. Скажем, у нас 10 клиентов, что означает, что у нас будет 20 файлов на страницу aspx. –

+0

В конце концов мы решили спуститься по этой дороге.У нас есть файл базового ресурса, который содержит все, что разделяется между несколькими клиентами. Затем в каждом файле клиента (который существует только в случае наличия альтернативных ресурсов) существует возможность переопределения базовых ресурсов. Мы закодировали пользовательский обработчик ресурсов для выбора между файлами клиента. –

0

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

С .NET 2.0 и вы можете создать новые культуры. (См. How to: Create Custom Cultures.) Я бы предложил создать новую «культуру» из вашего файла конфигурации, наследуя от культуры, представляющей используемый язык. Когда у вас есть новая культура, вы можете создать файл ресурсов только для строк, специфичных для этого клиента, если он откажется от значений по умолчанию, если не указано переопределение.

Edit: Кроме того, вот статья, описывающая, как использовать культуру для конкретного клиента использования языка: .NET Internationalization: Using Custom Cultures

0

Я не могу сказать, как работает ваш LoadPageConfig.

Некоторые идеи:

  • Если вы хотите иметь, как маленькие файлы на одного клиента, вы можете загружать свои файлы ресурсов динамически (во время выполнения), так что вам не нужно будет создавать дополнительные культуры.
  • для реальных различий в конфигурации рассмотрите возможность загрузки одного файла конфигурации на каждого клиента с настройками клиента, как описано in this article. Такой же подход можно использовать в ASP.NET.
Смежные вопросы