Какими способами вы поддерживаете «международность» контента на контент-сайтах?
Обычно, если говорят о локализации сайта, то подразумевают, что вот у вас есть файлики, там все атрибуты менюшек, сиди и переводи. Окей, но это элементы меню... А что делать, если на сайте например есть разделы:
1. блоги
2. книги
3. инструменты (калькуляторы)
Вот пришёл испанец на сайт в раздел калькуляторов. Здесь в целом можно обойтись атрибутами локализации, как раз через ключи в файлах. Т.е. Педро зашёл, увидел текст на испанском (элементы меню), и инструмент тоже на испанском (кнопки clear, submit, name и прочее подобное).
Окей. Но сложности начинаются с книг. Книга - это запись в БД (заголовок, описание, автор, картинка). Вот как её хранить? Мне тут предложили такой вариант:
- одна таблиц, в которой только идентификаторы текстов
- другая таблица, это атрибут, язык, текст
Да, решает проблему, т.е. мы можем давать информацию локализованно, но увы, работать это будет не быстро.
Окей. А что с блогами? Педро, Вася и Нiколаi, пишут на трёх разных языках. Как тогда их разделять? И что показывать пришедшему пользователю? Только тот контент, который соответствует его региону?
Простите, наверное всё сумбурно, но не нашёл статей ни по хранению подобной информации, ни по клиентской стороне.
В каждом фреймворке своя реализация. Кто-то предпочитает вручную реализовывать данную функциональность. Я сталкивался и с тем, и с другим.
У меня на работе сейчас в Django проекте используется самописная система, в которой автоматически генерируются поля вида title_en, title_zh_cn для каждого из определенных языков в settings.LANGUAGES. В других проектах пользовался готовой библиотекой для Django: django-modeltranslation.
Привет!
Во-первых, приведенные примеры - это абсолютно разные задачи, поэтому решения у них так же сильно различаются.
Если есть возможность заранее сделать перевод, например для кнопок меню или для кнопок каких-то инструментов, то нужно это делать заранее. Механизмы у многих самописные, но так же существуют в разных фреймворках свои реализации, например, если пользуетесь npm, посмотрите globalize npm. Смысл в том, что все текстовки выносятся в отдельные файлы (обычно на клиенте) и их можно отдельно редактировать и легко добавлять новые.
Что касается книг, то это идёт работа с базой, необходимо вынести тексты в отдельную таблицу/таблицы, либо добавить идентификатор языка и хранить в одной таблице. В любом случае у вас увеличивается размер базы данных и увеличивается сложность запросов и сложность работы. Естественно, работать будет медленнее, это такая плата.
Если говорить о динамически генерируемом контенте, как вариант, если это устраивает, можно разделить страницы. То есть будет форум на русском языке и форум на английском языке и они не пересекаются.
Есть и другой вариант, у контор, которые занимаются переводами обычно есть api (можете посмотреть хоть яндекс транслейт, хоть гугл транслейт, есть еще куча специализированных). Такие апи обычно платные. Соответственно, пишется комментарий на испанском, этот текст прогоняется через апи (для каждого используемого языка) и результат записывается в организованную, примерно как для книг, базу. Ну и да, это, естественно, машинный перевод так себе качества.
добавить идентификатор языка и хранить в одной таблице. В любом случае у вас увеличивается размер базы данных и увеличивается сложность запросов и сложность работы. Естественно, работать будет медленнее, это такая плата.
Vapaamies, была одна таблица, а стало две таблицы, то есть на всех запросах появился join и данных стало в 5 раз больше. Время отклика увеличится, может незначительно, но увеличится
