- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева

Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Как вообще организовывается мультиязычность контента? Озадачился над реализацией, думаю, как лучше?
Вариант 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-ах:
Да все просто для шаблонов.
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'] и .т.д.
Именно так у меня реализовано на многих сайтах