Мультиязычный сайт, как к этому подойти?

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

У меня есть 2 плана:

1

Конечно, весь контент (текст) находится в базе данных.

Если пользователю нужен другой язык, он щелкает ссылку /флаг, в результате чего запрошенный язык помещается в переменную сеанса, например: session.language = "es"

В базе данных у меня будет 2 столбца (каждый язык имеет 1 столбец), а затем я выберу текст, который принадлежит 'es'

Затем каждая страница будет отправлять запрос в базу данных, чтобы получить текст, загружаемый в файл session.language.

PROS: относительно прост в реализации

Минусы: SEO мудрый, я не думаю, что это может быть очень хорошо. http: //www.domain.com/page.cfm даст текст на английском или испанском (или другом языке). Google не будет добавлять дублирующиеся URL-адреса

2:

Сделайте что-нибудь с http: //www.domain.com/en/page.cfm для английского языка и http: //www.domain.com/es/page.cfm для английского.

С помощью правила перезаписи URL значение языка в URL http: //www.domain.com/en/page.cfm фактически будет страницей http: //www.domain.com/page.cfm?language= ан

Затем переменная url.language выберет правильный язык из базы данных.

PROS: уникальный URL для каждого языка. Хорошо для SEO и индексации Google.

Минусы: немного сложнее реализовать. (Я думаю)

Или у кого-то есть другие /лучшие идеи?

Спасибо !!

4 голоса | спросил Steven Filipowicz 12 PMpThu, 12 Apr 2012 15:15:20 +040015Thursday 2012, 15:15:20

5 ответов


0

Вы должны всегда сначала проверять заголовок браузера «Accept-Language» на наличие языка (языков) по умолчанию (правильный стандартный способ сделать это) и предлагать ссылки (интуитивно на первый взгляд правильный путь) только в качестве альтернативы.

Делать это в базе данных не очень стандартно. Предположим, вы хотите использовать архитектуру MVC (модель-представление-контроллер). Большая часть программного обеспечения использует ключи на уровне представления (представление) (например, html), и наряду с уровнем представления у вас есть языковые файлы (в Java это, как правило, файлы свойств), которые отображаются просто по их именам файлов и могут быть изменены с помощью постоянные пользователи, без каких-либо специальных навыков, такие как профессиональные переводчики без компьютерных навыков. Конечно, вы можете поместить его в базу данных, но тогда это просто дополнительная работа, которая перемещает информацию из уровня представления.

Для этого есть разные библиотеки. Вы должны найти нормальный для вашего приложения. Пожалуйста, измените ваш вопрос, чтобы включить то, что вы используете для разработки приложения. (например, JSP, Tapestry, Wicket, ASP, PHP и т. д.) Например, если вы хотите использовать JSP, я бы тогда предложил вам использовать языковую поддержку библиотеки тегов JSTL. Или, если бы вы использовали Tapestry, я бы указал вам http://tapestry.apache.org/localization.html. или http://tapestry.apache.org/tapestry4.1/UsersGuide /localization.html

Чтобы найти его, можно поискать термины «интернационализация», иначе «i18n» или «локализация». (Термины не означают одно и то же, но немногие используют их правильно, поэтому любой из них работает. http://www.w3.org/International/questions/qa-i18n )

ответил Peter 12 PMpThu, 12 Apr 2012 15:30:44 +040030Thursday 2012, 15:30:44
0

Я бы выбрал вариант 2. У каждого перевода должен быть свой URL. Ссылки на ваш сайт уже будут в предполагаемом переводе.

Чтобы хранить переводы в базе данных, я бы не помещал каждый перевод в отдельный столбец, а скорее поместил бы их в отдельную таблицу:

Таблица сообщений:
- id
- title_id
- ...

Переводы таблиц:
- label_id
- значение
- код страны
- language_code

Где title_id совпадает с label_id

Таким образом, вам не придется изменять структуру таблицы при добавлении нового перевода. Это позволяет вам иметь бесконечные переводы для любой метки или текста.

ответил jan 12 PMpThu, 12 Apr 2012 15:32:34 +040032Thursday 2012, 15:32:34
0

Чтобы эффективно создать многоязычный сайт, вам нужно установить для себя правило, что НЕТ ТЕКСТ всегда указывается в источнике в жестком коде. Он либо должен поступать из базы данных и /или пакета ресурсов.

Текст из базы данных

Вы должны убедиться, что столбец, в котором вы храните свои данные, имеет кодировку Unicode, иначе у вас возникнут проблемы с акцентированным символом. Также не используйте столбец для каждого языка, так как он не масштабируется, делайте то, что предлагает @jan, и имейте таблицу переводов, в которой элементы указываются по ссылке, а также по языку.

Пакеты ресурсов

Вы не захотите получать каждый последний маленький кусочек текста из базы данных, поэтому для тех, кто может использовать пакет ресурсов. Это, по общему признанию, старая ссылка http://www.sustainablegis.com/blog/cfg11n/index.cfm?mode=entry&entry=FD48909C-50FC-543B-1FE177C1B97E8CC1 из блога Пола Хастингса о некоторых решениях для комплектов ресурсов. Честно говоря, его блог - отличный ресурс на эту тему.

Относительно того, как вы обрабатываете URL-адреса, не используйте вариант 1, поскольку вы совершенно правильно определили, что это вызовет проблемы с SEO-рейтингом страницы, и это будет означать, что пользователи не смогут правильно поделиться или вернуться на страницу.

У двух подходов есть код языка в URL, который вы указали в варианте 1.

Pros

  • Проще настроить

против

  • У вас есть одно приложение, которое означает, что по мере добавления большего количества языков вы увеличиваете сложность и вес в памяти этого приложения

Или вы можете иметь другой поддомен или домен для приложения, например es.yourdomain.com или yourdomain.es все они могут иметь одинаковую кодовую базу

Pros

  • Каждый язык является автономным приложением, то есть имеет собственную память

против

  • больше усилий для настройки
ответил baynezy 12 PMpThu, 12 Apr 2012 19:00:04 +040000Thursday 2012, 19:00:04
0

http://i18n.riaforge.org/ имеет загрузку для i18n. Его можно использовать, чтобы убедиться, что все строковые метки совпадают. Таким образом, если кто-то захочет изменить «Сохранить» на «Обновить», все это можно сделать в одном месте.

Также важно учитывать техническую подготовку тех, кто занимается переводом. Часто команде переводчиков проще редактировать файлы в блокноте, чем обновлять БД. Текстовые файлы хорошо работают с контролем версий.

ответил James A Mohler 28 32012vEurope/Moscow11bEurope/MoscowWed, 28 Nov 2012 05:16:21 +0400 2012, 05:16:21
0

Лучший способ, который я нашел, - это использовать XML для хранения только языка страниц, один XML для каждой страницы, а затем вы можете изменить его для языка. когда страница загружается, просто загрузите другой XML из базы данных или файлов ... множество способов сделать это. у всех других методов, которые я пробовал, есть свои проблемы, и, по крайней мере, этот позволяет вам взять язык XML, передать его тому, кто его скопирует, и затем поменять коробки ... вы положили его в БД для его обслуживания.

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

как только вы поймете идею, остальное станет очень легко ... и учитывая CF способы доступа к таким данным с точечной нотацией, легко для нас

скажем, у вас есть "Загрузить изображения"

in english xml it may be <LoadIMGS>Load Images</LoadIMGS> 
in chinese it may be <LoadIMGS>加载图像</LoadIMGS>
or <LoadIMGS>Jiā zǎi túxiàng</LoadIMGS>

независимо от того, в вашем коде CFM вы просто поместите # variablename.LoadIMGS # на место ... я бы также предложил поместить в тег loadimages размер, к которому должен быть изменен шрифт, если не нормальный размер. таким образом, когда переводы слишком велики, вы можете уменьшить этот шрифт для этого ... и т. д.

наслаждаться !!!

ответил Artfldgr 16 FebruaryEurope/MoscowbThu, 16 Feb 2017 00:59:14 +0300000000amThu, 16 Feb 2017 00:59:14 +030017 2017, 00:59:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132