Хранить контент на нескольких языках? Например. Английский, французский, немецкий

Question

Как хранить (и представлять) текст на веб-сайте, предназначенном для использования по всему миру, на нескольких языках? Содержимое в основном представлено в виде статей из более 500 слов, хотя мне нужно будет также переводить крошечные фрагменты текста на каждую страницу (например, «напечатать эту статью» или «вернуться в меню»).

Я знаю, что есть несколько пакетов CMS, которые работают с несколькими языками, но я должен также интегрироваться с нашими существующими системами ASP, поэтому я игнорирую такие решения.

Одна из проблем, с которыми я столкнулся, заключается в том, что Google должен быть в состоянии найти страницы даже для иностранных пользователей. Меня меньше волнуют проблемы с датами обработки и валютами.

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

---

Я посмотрел на файлы RESX, но мне показалось, что они не подходят для всех, кроме самых простых решений для перевода (я уточню, если кто-то захочет узнать).

Google поможет мне с переводом текста, но не хранит / не представляет его.

Кто-нибудь работал над многоязычным проектом, который полагался на собственный код для презентации?

---

Есть мысли о том, как подавать контент следующими способами, и какой из них лучше?

• http://www.website.com/text/view.asp?id=12345&lang=fr
• http://www.website.com/text/12345/bonjour_mes_amis.htm
• http://fr.website.com/text/12345

(это не настоящие URL, я просто показываю примеры)

Answer 1

Сначала поместите весь код для всех языков в одном домене - это поможет вашему google-rank.

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

Где бы мы ни хотели видеть локализацию, мы используем:

<%$ Resources: LanguageProvider, Path/To/Localisation %>

Тогда в нашем web.config:

<globalization resourceProviderFactoryType="FactoryClassName, AssemblyName"/>

FactoryClassName затем реализует ResourceProviderFactory для обеспечения фактической динамической функциональности. Локализации хранятся в БД со строковым ключом «Путь / К / Локализация»

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

Используйте текущую локализацию браузера пользователя, чтобы выбрать язык для обслуживания.

Answer 2

Возможно, вы захотите проверить GNU Gettext проекта - по крайней мере, с чего начать.

Отредактировано для добавления информации о проектах:

Я работал над несколькими многоязычными проектами с использованием технологии Gettext в различных технологиях, включая C ++ / MFC и J2EE / JSP, и все работало нормально. Тем не менее, вам нужно написать / найти свой собственный код для отображения локализованных данных, конечно.

Answer 3

Как и в большинстве общих вопросов программирования, это зависит от ваших потребностей.

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

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

Таблица для первого подхода может выглядеть примерно так:

Идентификатор статьи | Идентификатор языка | Текст статьи для конкретного языка | Создано | Дата создания

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

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

Первая таблица: Идентификатор статьи | Создано | Дата создания | Обновлено | Дата обновления

Вторая таблица: Идентификатор статьи | Идентификатор языка | Текст статьи для конкретного языка

Для меня вопрос сводится к обновлению данных, не зависящих от языка. Если вы обновляете эти данные, то я склоняюсь ко второму подходу, в противном случае я бы выбрал первый подход, поскольку считаю его более простым (не могу забыть принцип KISS).

Answer 4

Если вы используете .Net, я бы рекомендовал использовать один или несколько файлов ресурсов (.resx). На MSDN имеется множество документации по этому вопросу.

Answer 5

Что касается формата URL, я использую site.com/content/example.fr, поскольку это позволяет Apache выполнять согласование языка в случае, если кто-то запрашивает /content/example и браузер сообщает, что ему нравится французский язык. Когда вы делаете это, Apache также добавляет .html или что-то еще в качестве бонуса.

Так что, когда запрос для example и у меня есть файлы

example.fr
example.en
example.vi

Apache автоматически продолжит с example.vi для человека с браузером, настроенным на вьетнамском языке, или example.en для человека с браузером, настроенным на немецком языке. Довольно полезно.

Answer 6

Замечательный вопрос.

Я решил эту проблему для веб-сайта, который я создал (ссылка в моем профиле) с помощью самодельного скрипта Python 3, который на лету переводит общий шаблон и вставляет определенную страницу содержимого с языка, запрошенного (или предположенного Apache из Accept- Язык).

Это было весело, так как я начал изучать Python и написать свою собственную мини-библиотеку для создания страниц контента. Одним из недостатков было то, что на нашем хостинге не было Python 3, но я заставил свой сценарий генерировать статический HTML-код (исходный проверял User-agent) и затем загружать его на сервер. Это работает до сих пор, и создание новой языковой версии сайта теперь очень просто:)

Самым большим недостатком этого метода является то, что для написания вещей с нуля требуется много времени. Поэтому, если хотите, напишите мне, и я помогу вам использовать мой скрипт:)

Answer 7

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