- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Как вообще организовывается мультиязычность контента? Озадачился над реализацией, думаю, как лучше?
Вариант 1. Просто создать копии шаблонов страниц где захардкожен текст и выдавать его с урлом типа site.con/ru/page (/pl|en/by/ukr)
Самая простая реализация, но правки превращаются в ад.
Вариант 2. Создать языковый файл и динамически подгружать контекст в шаблон. Тут легко править - все в одном месте. Но увеличивается количество запросов в бэк. Правда если использовать нереляционные базы данных - нагрузка будет минимальной.
Может есть еще варианты? Не нужно предлагать решения, привязанные к какому-то языку, тем более плагины. Интересует чисто концепция.
site.con/ru/page
ru.site.con/page
Создать языковый файл и динамически подгружать контекст в шаблон.
Это если вам не нужен трафик из ПС. Иначе, как они поймут на каком языке страница?
Нужен трафик
сайт/ру/
сайт/англ/
сайт/укр/
не нужен трафик - как угодно
По вопросу домен или подкаталог не скажу - это вопрос не технический.
По реализации, чаще делают на файлах - это касается текстов интерфейса. (битрикс, symfony, yii, django) Контент по прежнему в базе остается. Так же это решается, на сколько я помню (но сам не пользовался локализацией), в фронтендовых UI фреймворках.
Больше тут "сложность", точнее какой вопрос надо решать где хранить перевод контента - в той же таблице отдельная колонка, или отдельная колонка.
Про динамическую подгрузку контента не понятно. Если на серваке собирается страница полностью с контентом - так и надо собирать далее, если собиралась в браузере - так и остается.
Нужен трафик
сайт/ру/
сайт/англ/
сайт/укр/
не нужен трафик - как угодно
Да, принято, спасибо, об этом не думал.
По вопросу домен или подкаталог не скажу - это вопрос не технический.
По реализации, чаще делают на файлах - это касается текстов интерфейса. (битрикс, symfony, yii, django) Контент по прежнему в базе остается. Так же это решается, на сколько я помню (но сам не пользовался локализацией), в фронтендовых UI фреймворках.
Больше тут "сложность", точнее какой вопрос надо решать где хранить перевод контента - в той же таблице отдельная колонка, или отдельная колонка.
Про динамическую подгрузку контента не понятно. Если на серваке собирается страница полностью с контентом - так и надо собирать далее, если собиралась в браузере - так и остается.
На этом этапе меня интересует только интерфейс.
В зависимости от выбранного языка должен меняться. КАк я говорил есть два варианта - или просто хранить 1-2-3-4 шаблона с разными языками или подгружать в переменные шаблонизатора в зависимости от выбранного языка. Второй правильный но тут надо как-то избежать лишних запросов в базу. Понятно что кэширование будет. Пока идея - спользовать DynamoDb/Mongo. Вроде как самое то. Запросы очень быстрые, все храниться в json-ах:
{
"ru": {
"mentor": "Преподаватель",
...
}
"by": {
"mentor": "Настаунik"
}
}
Да все просто для шаблонов.
1 шаблон, к которому подключается нужный файл в зависмости от нужного языка include ('../lang/ru.php'); include ('../lang/en.php'); а нужные слова в самом шаблоне в виде переменных $L['glavnaj'] и .т.д.
Вариант 3 как нормальные прогеры делают
Ты бы прочитал сначала внимательно. Это не вариант3 а вариант 2 у меня. И я уже выразил консерн свой - это лишний запрос в базу данных. Поэтому и планирую использовать Монгу.
Да все просто для шаблонов.
1 шаблон, к которому подключается нужный файл в зависмости от нужного языка include ('../lang/ru.php'); include ('../lang/en.php'); а нужные слова в самом шаблоне в виде переменных $L['glavnaj'] и .т.д.
зачем мне разные шаблоны? достаточно одного с разным контекстом.
Да все просто для шаблонов.
1 шаблон, к которому подключается нужный файл в зависмости от нужного языка include ('../lang/ru.php'); include ('../lang/en.php'); а нужные слова в самом шаблоне в виде переменных $L['glavnaj'] и .т.д.
Именно так у меня реализовано на многих сайтах