Comments 22
Получается, у вас CloudFlare -> сервер переводчик -> главный сервер, и по сути переводчик проксирует и модифицирует контент для CloudFlare?
Как решается проблема 2 часового кеша? ведь запросив hello.php через CF из штатов я получу английский текст, а запросив из франции, если кто-то запросил (с местных pop 'ов) с английской локалью, я получу английский вариант, вместо французского. А чистить кеш по АПИ — у них лимит на колво запросов.
Для модификации контента на стороне nginx средствами nginx есть ngx_http_substitutions_filter_module, правда придется поиграть с location и переменными, чтобы логику реализовать. Я просто испольщую lang=ru или через cookies.
Как решается проблема 2 часового кеша? ведь запросив hello.php через CF из штатов я получу английский текст, а запросив из франции, если кто-то запросил (с местных pop 'ов) с английской локалью, я получу английский вариант, вместо французского. А чистить кеш по АПИ — у них лимит на колво запросов.
Для модификации контента на стороне nginx средствами nginx есть ngx_http_substitutions_filter_module, правда придется поиграть с location и переменными, чтобы логику реализовать. Я просто испольщую lang=ru или через cookies.
Сервер-переводчик может стоять по обе стороны от CloudFlare, в общем-то.
Разные языковые версии привязаны либо к разным доменам (domain.es, domain.ru и так далее), либо URI (/es/news, /ru/news и так далее) — поэтому описанной проблемы с кэшем не будет. Кэш всегда использует полный адрес как ID объекта. Другой адрес — другой объект.
Указанный модуль для nginx работает несколько примитивно — он построчно считывает буфер и применяет regular expressions. Таким способом гибкий выбор места (селекторы) реализовать нельзя — текущая строка не знает о следующей строке. Ну и самое главное — сомневаюсь, что кто-то захочет 10 тысяч правил в конфигурацию NGINX добавлять ;-) Это решение слишком низкоуровневое
Разные языковые версии привязаны либо к разным доменам (domain.es, domain.ru и так далее), либо URI (/es/news, /ru/news и так далее) — поэтому описанной проблемы с кэшем не будет. Кэш всегда использует полный адрес как ID объекта. Другой адрес — другой объект.
Указанный модуль для nginx работает несколько примитивно — он построчно считывает буфер и применяет regular expressions. Таким способом гибкий выбор места (селекторы) реализовать нельзя — текущая строка не знает о следующей строке. Ну и самое главное — сомневаюсь, что кто-то захочет 10 тысяч правил в конфигурацию NGINX добавлять ;-) Это решение слишком низкоуровневое
Сервер-переводчик может стоять по обе стороны от CloudFlare, в общем-то.
Если перед — тогда какой смысл от CF? Галочки ради? Если после — смотрите мой коммент. Так что стоять-то может, только безтолку.
либо URI (/es/news, /ru/news и так далее) — поэтому описанной проблемы с кэшем не будет
Тогда какой вообще смысл от этой статьи?
Вы рассматриваете пачку способов, рассуждаете в JS
Поделиться ссылкой в социальных сетях также будет невозможно;
Затем решение с CDN, читатель настроен на разрешение недостатков предыдущих вариантов. Почему там тоже не указали тот же самый минус?
Ведь example.com/about будет выдавать всегда один и тот же язык из кеша CDN'а, так как адрес не изменен. А постановка серверов *перед CDN — это самый настоящий бред. Во-первых если надо скрыть адрес конечного сервера, то "переводчика" хватит, во-вторых — напоминает решение, когда человек не умеет пользоваться кешем и не понимает для чего нужен CDN.
*отредактировал
1) Если перед – нет, не ради галочки, а чтобы пользователю меньше движений делать. Представим кейс, что есть веб-сайт http://direct.site.ru, есть обёрнутый в CF https://www.site.ru. Пользователь решил добавить https://www.site.es, у него стоит выбор – выбрать как origin direct.site.ru или www.site.ru. Оба сайта (напрямую и через CF) возвращают один и тот же контент за исключением случаев, когда оригинальный сайт лежит (тут CF может показать свою красивую ошибку). Таким образом, разница сравнительно небольшая – переводить ответ от оригинального сервера или переводить ответ от edge-точки CF.
2) Смысл статьи – предложить новый метод локализации, который сейчас практически не используется вообще никем.
3) Тут Вы неправильно немного поняли концепцию, и частично виноват я сам. У каждого переведенного сайта отличаются адреса всех страниц. На выбор пользователя – это может быть домен, может быть URI.
Неважно куда приходит запрос на, скажем, site.es/index – на CloudFlare, CloudFont, CDN77 или мой собственный edge-сервер. Адрес site.es/index уникально идентифицирует конкретную страницу на конкретном языке.
2) Смысл статьи – предложить новый метод локализации, который сейчас практически не используется вообще никем.
3) Тут Вы неправильно немного поняли концепцию, и частично виноват я сам. У каждого переведенного сайта отличаются адреса всех страниц. На выбор пользователя – это может быть домен, может быть URI.
Неважно куда приходит запрос на, скажем, site.es/index – на CloudFlare, CloudFont, CDN77 или мой собственный edge-сервер. Адрес site.es/index уникально идентифицирует конкретную страницу на конкретном языке.
Общий вопрос:
Зачем проксировать траффик через CF, если можно сразу напрямую на переводчика? Нагрузки на канал и на сервер это не снизит (так как у нас или ИПшники CF, или ИПшник переводчика как allow).
Частный вопрос:
CF -> конечный сервер который отдает RU для RU домена и ES для ES домена. Классическая схема. Если нельзя никак вставить косыль переводов в конечный сервер, то переводчик нужно разместить между CF и конечным сервером (когда переводчик проксирует ответы на CF). Иначе теряется весь смысл CDN.
Но этим вы америку не открыли, а это просто обычная схема использовалия CF.
Но это все работает у вас в случае разных доменных зон или поддоменов (ru.example.com, es.example.com).
Но в случае одно единственного домена (example.com) нельзя стабильно отдавать двум пользователям кешируемый контент на 2х разных языках через GET запрос (POST'ы не кешируют) в CF для одной и той же страницы. И если такое удалось — это все дело в pop'ах (точки забора контента) и юзерам проксировался ответ, забранный через разные сервера.
Это CDN. А сервер *после CDN — это не CDN решение, а увеличение задержек.
Если перед – нет, не ради галочки, а чтобы пользователю меньше движений делать.
Зачем проксировать траффик через CF, если можно сразу напрямую на переводчика? Нагрузки на канал и на сервер это не снизит (так как у нас или ИПшники CF, или ИПшник переводчика как allow).
Частный вопрос:
решил добавить www.site.es
domain.es, domain.ru и так далее
CF -> конечный сервер который отдает RU для RU домена и ES для ES домена. Классическая схема. Если нельзя никак вставить косыль переводов в конечный сервер, то переводчик нужно разместить между CF и конечным сервером (когда переводчик проксирует ответы на CF). Иначе теряется весь смысл CDN.
Но этим вы америку не открыли, а это просто обычная схема использовалия CF.
Но это все работает у вас в случае разных доменных зон или поддоменов (ru.example.com, es.example.com).
Но в случае одно единственного домена (example.com) нельзя стабильно отдавать двум пользователям кешируемый контент на 2х разных языках через GET запрос (POST'ы не кешируют) в CF для одной и той же страницы. И если такое удалось — это все дело в pop'ах (точки забора контента) и юзерам проксировался ответ, забранный через разные сервера.
Это CDN. А сервер *после CDN — это не CDN решение, а увеличение задержек.
перед — после, правлю опечатки.
В общем — перед СДН — ОК. После СДН — это не решение и потеря преимущества.
В общем — перед СДН — ОК. После СДН — это не решение и потеря преимущества.
CF — translater — server = OK
translater — CF — server = NOT OK
translater — CF — server = NOT OK
А что если CDN-переводчик сам неплохо кэширует? :-) кэширующий CDN – дело тривиальное, поэтому их так много сегодня.
Пользователи, которые любят CF и лояльны к нему, остаются как: CF – translator – origin, а кто-то кто нашёл сервис отдельно и не знает про CF может просто: translator – origin
Схема translator – CF – origin просто как пример была дана, как доказательство, что по большому счету – разницы то нет откуда вернулся HTML контент, его можно перевести. Это нерационально, но это гибкость дает
Пользователи, которые любят CF и лояльны к нему, остаются как: CF – translator – origin, а кто-то кто нашёл сервис отдельно и не знает про CF может просто: translator – origin
Схема translator – CF – origin просто как пример была дана, как доказательство, что по большому счету – разницы то нет откуда вернулся HTML контент, его можно перевести. Это нерационально, но это гибкость дает
Давайте по порядку:
Теперь переводчик уже не сервер, а CDN сеть… вы определитесь!
Тогда удалите текст про CDN, так как он нужен здесь как козе баян.
Просто вдумаеться в сие безобразие: CF проксирует и кеширует ответы от origin на… translator, который раздает контент всем оставшимся.
Это использование CDN-кешируюшего сервера как просто кеширующего сервера, добавление в схему лишнего звена (раз CDN вам не нужен), когда для задачи (кеширование ответов и передачи на translator) хватит обычного nginx!
Ответьте мне, зачем вы в вашей статье используете термины CDN, когда зарубаете на корню саму идую и все преимущества CDN?
А что если CDN-переводчик сам неплохо кэширует?
Теперь переводчик уже не сервер, а CDN сеть… вы определитесь!
Схема translator – CF – origin просто как пример была дана, как доказательство, что по большому счету – разницы то нет откуда вернулся HTML контент
Тогда удалите текст про CDN, так как он нужен здесь как козе баян.
Просто вдумаеться в сие безобразие: CF проксирует и кеширует ответы от origin на… translator, который раздает контент всем оставшимся.
Это использование CDN-кешируюшего сервера как просто кеширующего сервера, добавление в схему лишнего звена (раз CDN вам не нужен), когда для задачи (кеширование ответов и передачи на translator) хватит обычного nginx!
Ответьте мне, зачем вы в вашей статье используете термины CDN, когда зарубаете на корню саму идую и все преимущества CDN?
Потому что предложенная модель – это CDN, это content delivery network.
Имеется оригинальный сервер с контентом, имеется сеть пограничных серверов (с функцией перевода), которые контент распространяют.
CloudFlare – это CDN, который умеет оптимизировать картинки, минимизировать JavaScript, вставлять Google Analytics. Тут предлагается CDN, который умеет парсить HTML/JavaScript и заменять в нём тексты.
Цепочка CF<->переводчик упомянута только для подчеркивания гибкости, поддержки legacy клиентов и так далее. Это не является рекомендацией, просто это работает.
Термин использован правильно!
Имеется оригинальный сервер с контентом, имеется сеть пограничных серверов (с функцией перевода), которые контент распространяют.
CloudFlare – это CDN, который умеет оптимизировать картинки, минимизировать JavaScript, вставлять Google Analytics. Тут предлагается CDN, который умеет парсить HTML/JavaScript и заменять в нём тексты.
Цепочка CF<->переводчик упомянута только для подчеркивания гибкости, поддержки legacy клиентов и так далее. Это не является рекомендацией, просто это работает.
Термин использован правильно!
Потому что предложенная модель – это CDN, это content delivery network.
При использовании схемы: сервер translator — CF — origin это больше не CDN. Это вредный совет, как убить преимушества CDN и раздавать данные клиентам с одного сервера.
Прошу учесть, что если, к примеру, Вы добавляете эстонский язык на сайте, то Вам не особо критично будет иметь глобальную сеть PoP от CloudFlare.
Я согласен, что это нерационально во многих случаях. Просто это будет работать, если кому-то уж сильно так надо :)
Я согласен, что это нерационально во многих случаях. Просто это будет работать, если кому-то уж сильно так надо :)
Тогда убираем текст и отсылки к CDN. Текущий заголовок: "Альтернативный способ локализации веб-сайтов: мутирующий контент CDN". Можно изменить на "Альтернативный способ локализации веб-сайтов: мутирующий контент".
Потому, что в случае сервером переводчиком, который проксирует и модифицирует контент от CDN сети CF никаким CDN и не пахнет, а пахнет неумением использовать кеш.
Теперь если речь идет и вашей собственной сети CDN из 40+ серверов как минимум — где об этом инфа в статье, раз уж пиарите свой продукт? Где примеры конфигов?
Ничего этого в статье нету.
У вас даже не указан частный случай с доменными зонами, который в видео показывается. Чертовски желтый заголовок и влажная фантазия "прикручу ка я CDN в свой велосипед, и пусть все считают что тут CDN!".
Далее:
Резать преимущества CDN — это не нерационально, а это просто идиотизм. Если человеку надо перевести свой сайт на другой язык в другой доменной зоне, он это сделает до CDN. Так как у такого человека есть доступ к инфраструктуре проекта. Он же не последний придурок, чтобы проксировать ответ от сервера через CDN на сервер переводчик и снова на CDN, чтобы клиенты получили ответ.
Парень из Кореи добавил английский язык на свой сайт таким же макаром, вам из австралии не особо критично с огромным пингом?
Потому, что в случае сервером переводчиком, который проксирует и модифицирует контент от CDN сети CF никаким CDN и не пахнет, а пахнет неумением использовать кеш.
Теперь если речь идет и вашей собственной сети CDN из 40+ серверов как минимум — где об этом инфа в статье, раз уж пиарите свой продукт? Где примеры конфигов?
Ничего этого в статье нету.
У вас даже не указан частный случай с доменными зонами, который в видео показывается. Чертовски желтый заголовок и влажная фантазия "прикручу ка я CDN в свой велосипед, и пусть все считают что тут CDN!".
Далее:
Я согласен, что это нерационально во многих случаях. Просто это будет работать, если кому-то уж сильно так надо :)
Резать преимущества CDN — это не нерационально, а это просто идиотизм. Если человеку надо перевести свой сайт на другой язык в другой доменной зоне, он это сделает до CDN. Так как у такого человека есть доступ к инфраструктуре проекта. Он же не последний придурок, чтобы проксировать ответ от сервера через CDN на сервер переводчик и снова на CDN, чтобы клиенты получили ответ.
добавляете эстонский язык на сайте, то Вам не особо критично будет иметь глобальную сеть PoP от CloudFlare.
Парень из Кореи добавил английский язык на свой сайт таким же макаром, вам из австралии не особо критично с огромным пингом?
UFO just landed and posted this here
Вы совершенно правы, но тут проблема частично решается предлагаемым параметром 'контекст'. Если 'welcome' попалось внутри меню — пусть это будет "Приветствие", а если внутри параграфа — хочу "Добро пожаловать". Это, вероятно, не универсальное решение, но уже шаг вперед.
Перевод от API — за ним можно ставить онлайн-рынок переводчиков вроде Gengo, там качество контролируется, можно закреплять конкретных переводчиков, оспаривать тексты и так далее. Скорее всего, спустя месяц работы у большинства клиентов проблема отпадет — переводчики привыкнут к требованиям
Перевод от API — за ним можно ставить онлайн-рынок переводчиков вроде Gengo, там качество контролируется, можно закреплять конкретных переводчиков, оспаривать тексты и так далее. Скорее всего, спустя месяц работы у большинства клиентов проблема отпадет — переводчики привыкнут к требованиям
Запросить в репозитории переведённый текст, передав как параметры исходный текст и контекст.
контекст было бы удобно задавать вроде URL:selector
Навскидку такие минусы:
— Верстка поменялась — половина переводов не работает.
— Перевод фраз с переменными числами, разные словоформы для разных чисел — 2 files, 10 files / 2 файла, 10 файлов
— Локализация дат — месяц-день-год или день-месяц-год
— Перевод многозначных слов типа "on", "from" или "to". Можно каждое такое слово оборачивать в span с определенным классом, но это кажется не очень удобным решением.
Это ожидаемые вопросы и они решаемые ;-)
1) Если правильная конвенция по именам в CSS — верстка ничего ломать не будет. Если конвенции нет, то при смене дизайна или верстки достаточно в правилах адреса переписать.
2) Во-первых, это вполне себе решается в данной модели. Во-вторых, таких сценариев достаточно немного и они повторяются от сайта к сайту — вероятно, можно сделать какое-то общее решение.
3) Тоже самое, что в 2.
4) Если подобные слова используются где-то по отдельности, не как часть фразы – это может быть проблемой. Но думаю, что можно найти рациональное решение.
1) Если правильная конвенция по именам в CSS — верстка ничего ломать не будет. Если конвенции нет, то при смене дизайна или верстки достаточно в правилах адреса переписать.
2) Во-первых, это вполне себе решается в данной модели. Во-вторых, таких сценариев достаточно немного и они повторяются от сайта к сайту — вероятно, можно сделать какое-то общее решение.
3) Тоже самое, что в 2.
4) Если подобные слова используются где-то по отдельности, не как часть фразы – это может быть проблемой. Но думаю, что можно найти рациональное решение.
Таких сценариев больше, чем кажется. "Поле {fieldname} должно быть заполнено". Вместо {fieldname} может быть какое угодно название, при этом в верстке это просто одно строка текста. "Привет, {username}". "Привет" переводить надо, {username} нет. По пробелу разбивать?
Это может подойти для простых сайтов с парой страниц, но не более. Для сложных проще управлять переводами на своем сервере, чем на удаленном CDN.
Это может подойти для простых сайтов с парой страниц, но не более. Для сложных проще управлять переводами на своем сервере, чем на удаленном CDN.
Одно из рациональных решений, что приходит в голову – API получает N запросов на перевод строк, которые находятся в одном и том же месте и совпадают на процент X. Приложение понимает, что это, наверное, строка с переменной и предлагает пользователю быстро это подтвердить.
С другой стороны, этот пост-рендерный взгляд на ресурс позволяет нормально переводить тексты из БД, а не из словарей. Скажем, у нас онлайн-магазин, и мы хотим показывать "Матрёшка" как "Babushka" на английском сайте. Большинство разработчиков сейчас добавят дополнительное значение где-то в хранилище данных, таким образом далее усложняя локализацию – теперь у нас часть переводов в файлах, часть в базах.
А с точки зрения CDN – это обыкновенный текст, переводить и редактировать его можно вместе со всем остальным. Мне кажется, это достаточно удобно.
С другой стороны, этот пост-рендерный взгляд на ресурс позволяет нормально переводить тексты из БД, а не из словарей. Скажем, у нас онлайн-магазин, и мы хотим показывать "Матрёшка" как "Babushka" на английском сайте. Большинство разработчиков сейчас добавят дополнительное значение где-то в хранилище данных, таким образом далее усложняя локализацию – теперь у нас часть переводов в файлах, часть в базах.
А с точки зрения CDN – это обыкновенный текст, переводить и редактировать его можно вместе со всем остальным. Мне кажется, это достаточно удобно.
По моему, это очень крутая идея.
минусы есть — вы отдаете переводы (а соответственно и ответственность за них) вендорам (читай — Api) и полностью теряете над ними контроль. А еще у проекта появляется еще одна зависимость. имхо
Согласен, но так можно сказать про любой SaaS вообще. Плата за удобство и гибкость – как раз вынесение за рамки приложения, это как две стороны одной монеты.
Можно добавить на стороне CDN возможность выгрузки всех переводов в удобных форматах, чтобы уверить пользователя, что его не привязали. Захотел – сделал себе экспорт в текстовые файлы и ушёл.
Контроль, кстати, не полностью теряется. Предполагается, что клиент может через панель управления контролировать все переводы, оспаривать варианты, требовать повышения качества и так далее. Клиент всегда прав, CDN просто пытается сделать его жизнь проще.
Можно добавить на стороне CDN возможность выгрузки всех переводов в удобных форматах, чтобы уверить пользователя, что его не привязали. Захотел – сделал себе экспорт в текстовые файлы и ушёл.
Контроль, кстати, не полностью теряется. Предполагается, что клиент может через панель управления контролировать все переводы, оспаривать варианты, требовать повышения качества и так далее. Клиент всегда прав, CDN просто пытается сделать его жизнь проще.
Sign up to leave a comment.
Альтернативный способ локализации веб-сайтов: мутирующий контент CDN