Лучший способ для мультиязычных сайтов виртуальных каталогов

Question

У меня есть сайт, который в конечном итоге будет поддерживать 4 языка и 2 страны (США и Канада, английский и испанский)

Мне интересно, как лучше настроить структуру каталогов?

Сейчас у меня есть корневой сайт site.com:

Вы попадете на страницу, где вы выбираете свою страну и язык.

В идеале я хочу, чтобы каталог был таким:

site.com/ca/en/ (Canada English)
site.com/ca/fr/ (Canada French)
site.com/us/en/ (US English)
site.com/us/es/ (US Spanish)

Но это будет означать, что я буду помещать в него виртуальный каталог «ca» и «us» и языковые виртуальные каталоги. Это хорошая практика, или я должен сделать что-то вроде:

site.com/ca-en/ (Canada English)
site.com/ca-fr/ (Canada French)
site.com/us-en/ (US English)
site.com/us-es/ (US Spanish)

изменить: я сделал следующее:

В приложении есть фиктивный каталог: / ca / ​​и / us /. У них обоих есть default.aspx, который является просто перенаправлением. В моем случае я перенаправляю их на англоязычные сайты:

Например: site.com/ca/ -> site.com/ca/en/ site.com/us/ -> site.com/us/en/

если введен site.com, вы попадаете на страницу выбора языка. По сути, я использую регулярное выражение в Global.asax при каждом запросе для поиска строки языка / культуры.

Это имеет следующие преимущества. Разделение страны. Таким образом, вы контролируете site.com/ca/ или site.com/us/ и можете предоставить простой URL для каждой страны.

В любом случае, виртуальные каталоги / en /, / fr / и / es / находятся внутри физических папок соответствующих стран.

Итак, у вас есть следующее (Виртуальные каталоги выделены жирным шрифтом ):

site.com / ca / ​​ ru / (по умолчанию) site.com/ca/fr/ site.com/us/en/ (по умолчанию) site.com/us/es/

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

Answer 1

Ну, они хотят, чтобы URL был разным для каждого сайта.

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

Каждый раз, когда мы публикуем, я публикую в четырех местах. Одинаковое приложение.

Глобализация, использующая один URL, звучит как хорошая идея, но я не думаю, что она будет работать правильно, и даже если это произойдет, она не предложит хорошую закладку. (Французский человек отправляет ссылку другому французскому человеку с помощью компьютера, настроенного на английский). Есть и другие последствия, но есть причина, по которой сайты, такие как apple и microsoft, используют разные URL для каждого языка / культуры.

При каждом запуске сеанса я проверяю URL и соответствующим образом устанавливаю строки подключения.

В КОНЦЕ, я просто помещаю каталоги / ca / ​​и / us / в основное приложение, добавляю несколько виртуальных каталогов на каждый язык, делаю редирект отклика на страницу «выберите язык».

Возможно, не лучшее решение, но, похоже, оно работает.

Еще одним преимуществом этого является то, что если есть какая-то специальная страница, которая относится только к одному сайту, ее можно добавить только на этот сайт.

Answer 2

Почему бы не иметь один сайт и проверить настройки клиента (request.servervariables / HTTP_ACCEPT_LANGUAGE), какой предпочтительный язык использовать и использовать встроенную глобализацию в asp.Net?

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

Answer 3

общепринятая номенклатура для локализации - ll-CC для кода языка дефис-код страны. пример: en-US, хотя en-US, вероятно, будет по умолчанию с en-GB или en-CA, так как запасные варианты ... es-MX и т. д. также заслуживают внимания. Тем не менее, может быть лучше использовать субдомены, которые позволят разделить ресурсы без сложных правил балансировки нагрузки. Например: us.en.yoursite.com ... это также позволяет упростить распределение серверов в среде веб-фермы. Я бы посоветовал иметь тот же самый код с изменениями настроек для сайта в соответствии с локализацией. Затем используйте ресурс локализации, который вы передаете в текстовом ключе, и языковой перевод разрешается на основе шаблона локализации сайта. Примечание: .Net и другие платформы предлагают встроенные опции локализации ресурсов.