Ветка сайта на ином языке: поддомен или директория?

/en/
/ru/
ибо тогда будет возможность добавлять поддомен действительно когда это нужно
cabinet.domain.com/en/, а не cabinet.en.domain.com

Ну такой необходимости точно не возникнет. Какие ещё мысли?

Поддомен, или вообще другой домен второго уровня.

PS Плохо быть анонимусом! Регаться пришлось. dk-

Нахера тогда баниться было нужно?

А если тупо сделать наверху кнопку выбора языка? Или поисковики не смогут проиндексировать?

А если тупо сделать наверху кнопку выбора языка?

И что эта кнопка должна будет делать, редиректить куда-то или менять контент на текущей странице жсом?

Если тупо выставлять куку типа LANG=en и релоадить страницу? А сервер уже отдаёт в нужной локале в зависимости от куки. Это плохой вариант?

Наверно, да...

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

может есть какие-то мета теги чтобы указать язык контента

Есть, например тут: https://yandex.ru/support/webmaster/yandex-indexing/locale-pages.xml

2ТС: сделать лучше так, как советуют разработчики.

Помоему это не просто плохой, а ужасный вариант.

Тренирую самодисциплину.

И что эта кнопка должна будет делать, редиректить куда-то или менять контент на текущей странице жсом?

Поначалу они мне жсом и сделали. Выглядит то круто. Но толку мало. Не дать ссылку на конкретного языка страницу, и проблем у тех, у кого нестандартные сочетания системы\браузера\настроек.

Походу надо соглашаться с поддоменом.

а ужасный вариант.

Окей, а почему?

Почему плохо, в джанге это один из вариантов, например: https://docs.djangoproject.com/es/1.9/topics/i18n/translation/#how-django-dis...

лучше domain.ru, домен.рф для русского языка, и domain.com для всего остального.

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

заходишь на сайт, а там wordpress живёт на blog.domain.com, какой-нибудь phpbb живёт на forum.domain.com: с точки зрения безопасности это абсолютно правильно и верно, хостить уязвимые cms по разным виртуалкам, а у виртуалок разные IP, и без разделения на поддомены никак не обойтись. нет, конечно, можно и nginx настроить. чтобы он проксировал запросы с /blog/ на одну виртуалку, запросы с /forum/ на другую, и обойтись без создания поддоменов... но почему-то так мало кто делает, хз почему.

суть в том, что чем больше чего-то, то тем больше это обесценивается. и ваш домен вскоре превратиться в мусор с кучей не нужных A/AAAA-записей по соседству с нужными NS, MX, SRV, TXT...

будучи ретроградом, считаю, что поддомены нужно оставлять для системных демонов, служб, сервисов... а не для говёных cms и боже упаси, не ради «ещё одного раздела на сайте», как в случае с en/ru языками.

если вы категорически против регистрации второго домена в .RU и/или .COM зоне, то тогда только domain.com/ru/, domain.com/en/, ну это моё мнение.

поддомены оставьте для более важных вещей.

Спасибо за ссылку, просветился. Подозревал что что-то такое должно быть, но руки не доходили поглядеть самому.

- гемор с гуглом
- как выше уже сказали, урл на конкретную страницу не дашь (если только костылить с гет параметрами или #, что еще более ужасно)
- у кого-то вообще куки выключены

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

обслуживание этой схемы с точки зрения веб-сервера типа nginx - те еще костыли.

При чём тут nginx? Кэширование?

1. поисковик не сможет нормально проиндексировать
2. когда нужно дать ссылку, то человек будет настраивать локализацию. Это как с поиском к примеру, нужно чтобы все параметры сразу были в урле

Кэширование

Ага.

когда нужно дать ссылку, то человек будет настраивать локализацию.

1) Он это делает один раз

2) мне часто попадаются ссылки не в той локале. Т.е., скажем, поляки шлют ссылки на сайт которые открываются на польском, к примеру. Т.е., я бы сказал что это, скорее, проблема чем преимущество.

Кстати, на сайте появится РНР теперь. Я правильно понимаю, что нужно городить солянку из nginx, а за ним апач для скриптов?

Неправильно понимаешь, юзай nginx + php-fpm.

P.S. Посмотри как это сделано в твоем любимом online.net https://www.online.net/en https://www.online.net/fr

Я бы сказал что если кэширование пошло на стороне nginx то это уже костыли.

нужно городить солянку из nginx, а за ним апач для скриптов?

Если сайт расчитан на работу со всякими .htaccess то да :). Если сайт не днище то пускать php через fast-cgi враппер какой-нить.

Я бы сказал что если кэширование пошло на стороне nginx то это уже костыли.

Оо, то есть ты хочешь сказать, что кеширование на бекенде быстрее и лучше, чем сразу на фронте?

Если сайт расчитан на работу со всякими .htaccess то да :). Если сайт не днище то пускать php через fast-cgi враппер какой-нить.

У него же свой сервер, то что нужно вынесет в конфиг nginx.

кеширование на бекенде быстрее и лучше, чем сразу на фронте?

Nginx может только целиком кэшировать всю страницу. А что если юзер , скажем, залогинен и нужно показывать его имя? Или выводить прочие персональные вещи, а-ля список последних покупок или ещё что. Или какие-то вещи специфичные для определённого региона.

Кэширование на nginx подходит только для очень нетребовательных вещей когда у нас один контент для всех.

то что нужно вынесет в конфиг nginx.

Смотря что за движок там. Если какой-нить битрикс то сомневаюсь. А так, да, я такое делал, но мало ли что там изменят при обновлении сайта. Руками следить что .htaccess не менялся? Впрочем, я так понимаю, сейчас мало кто уже так делает сайты.

Кэширование на nginx подходит только для очень нетребовательных вещей когда у нас один контент для всех.

Понятно, но у него как раз такой случай.

Руками следить что .htaccess не менялся?

Как я понимаю, у него девелоперы девелопят на сервере, сами все и сделают.

Впрочем, я так понимаю, сейчас мало кто уже так делает сайты.

Угу, апач давно не нужен.

Правда, я видел какой-то модуль для nginx который умел «рендерить» html и вставлять блоки из redis... Но, имхо, такой гемор и усложнение себя оправдывает только на очень больших проектах, либо когда бэкенд говно и программисты не знают как нормально прикрутить кэширование.

либо когда бэкенд говно и программисты не знают как нормально прикрутить кэширование.

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

Делай как просят разработчики. Хотя, если бы не разработчики, то я бы делал папками.

Wikipedia
не согласна
ни с кем.
Шутка.
А если серьезно — Spoofing вот дело сказал. Хотя и нет единого мнения на этот счет, но компания должна иметь возможность выкупать отдельные корневые домены для каждой страны. А для бичей и линки есть.
Помимо разных языков есть еще сотни факторов, когда контент может быть разным (разные цены на одну продукцию в разных регионах, разные условия работы для разных видов клиентов, и т.д. и т.п.), а функционал один.
[кличко_mode]Ну домены третьего уровня — это как-бы подуровни, как модули, ну понимаете. Типа там модуль каталога, модуль панели для аналитиков, модуль глобального поиска, ну это все.[/кличко_mode]
Но по факту, сейчас домены третьего уровня используются для чего угодно. Я вот лично не знаю, может быть есть какая-то спецификация — для чего рекомендуется использовать домены N-уровня. Поделитесь информацией кто не жадный.

На самом деле, тут просто trade-off между скоростью, функциональностью и трудоёмкостью. Единого правильного решения не существует.

Много лет назад, например, для одного информационного сайта мы кэшировали главную страницу. Тупо только её потому что 1) на неё ложился весь трафик, люди дальше главной редко ходили 2) остальные страницы были персонализированы (форум, etc). Но и этого хватало, сайт ожил.

А так я тоже смотрю со своей колокольни. Если «типичный сайт» не может отдавать несколько сотен qps без всякого кэширования (этого хватает чтобы покрыть большинство интернет-проектов) то я считаю что сделано хреново. Но, к сожалению, тяжесть фреймворков зачастую кладёт даже простые сайты гораздо раньше.

Spoofing вот дело сказал.

Нет. Какие еще «поддомены оставьте для более важных вещей.»? Что это за бред?
Еще забыл сказать, что для гугла лучше все таки поддомен на старом домене сделать, чем регистрировать свежий.

Spoofing вот дело сказал.

Нет. Какие еще «поддомены оставьте для более важных вещей.»? Что это за бред?

Это же не для всех слов верно. Я описал это сразу после фразы.

Хотя и нет единого мнения на этот счет, но компания должна иметь возможность выкупать отдельные корневые домены для каждой страны.

Т.е. это относится к первым словам.

лучше domain.ru, домен.рф для русского языка, и domain.com для всего остального.

И то, для каждой страны нужно приобретать свой домен. Google знает в этом толк
Germany
France
Russia
И т.д. и т.п. Как я сказал выше — для бичей и линки есть.

Еще забыл сказать, что для гугла лучше все таки поддомен на старом домене сделать, чем регистрировать свежий.

Аргументируйте, пожалуйста.

Спуфинг херню сказал. Мне на визитках по два домена писать потом? А так домен.ру, а на самом сайте в шапке возможность переключить язык (плюс автоопределение языка для посетителя при первом заходе).

Спуфинг херню сказал. Мне на визитках по два домена писать потом?

Еще один любитель читать между строк? Читай еще раз, медленно и вдумчиво.

Хотя и нет единого мнения на этот счет, но компания должна иметь возможность выкупать отдельные корневые домены для каждой страны. А для бичей и линки есть.

Ключевые слова - компания, бичи, линки.

Nginx может только целиком кэшировать всю страницу. А что если юзер , скажем, залогинен и нужно показывать его имя?

эм, нет. я тут ругаю SSI, благодаря ей можно легко закэшировать отдельные блоки, как это сделал я в своём ЖЖ.

http://i.imgur.com/lrFGRMc.png

поясню скриншот.

в шапке сайта, на каждой странице, находится блок с авторизацией пользователя, ещё в этом блоке есть IP-адрес посетителя.

то есть, нам надо кэшировать: страницу целиком + авторизацию + IP-адрес, — выходит жирновато на одного анонимуса который зашёл на сайт один раз и вышел, а для него аж целая страница сгенерилась! ага...

поэтому каждая страница состоит из трёх частей: основной контент, который для всех общий, + блок авторизации, + строка с IP-адресом.

справа в vim, сверху вниз, можно увидеть SSI: из шапки дёргается <!--# include virtual="/session_id.php" -->, в нём дёргается <!--# include virtual="/remote_addr.php" --> (последний на самом деле можно было заменить на echo var=«REMOTE_ADDR», который SSI, но для чистоты эксперимента я осознанно предпочёл «костыль» в виде php ради одной строки IP-адреса).

слева открыт конфиг nginx, там каждый блок указан вручную, который кэшируется: /index.php основной контент сайта, блок авторизации /session_id.php, и IP-адрес /remote_addr.php, — каждый в отдельности кэшируется, и складывается в /dev/shm, теперь посмотрите на консоль вверху справа, там выхлоп find: итого мы имеем три файла, — контент - просто контент, авторизация с ключём $cookie_sessionid, ip с ключём $remote_addr (смотрите левее fastcgi_cache_key на каждый файл). все эти блоки складываются при помощи SSI в одну страницу и отдаются пользователю. содержимое блоков и ключ видно из выхлопа cat.

ну и внизу бенчмарк производительности ЖЖ.

без кэширования, на чистом php, раздел /blog/ выдавал 300 rps. но теперь, на закэшированной статике при помощи ssi nginx обрабатывает от 1600 rps — 2200 rps! прикиньте, было 300, стало 2000 в среднем. при этом абсолютно ничего не изменилось, динамика продолжает работать, когда надо!

тестируется на 150мбит'ном Wi-Fi между двумя ноутбуками: скорость доходит до 50мбит, но всё упирается в процессор сервера.

хочу 4-х ядерный ноутбук. =)

Хоти https://www.online.net/en/dedicated-server/dedibox-xc

Правда опять с ССД кончились. Я 2го марта успел один купить. Было доступно 40. Теперь нету.

На сколько это было бы медленнее если бы страница собиралась на стороне php целиком? Ведь ничто не мешает тоже самое сделать без nginx.

Аргументируйте, пожалуйста.

У старого домена возраст и условный траст выше, чем у свежерегнутого. Пусть этот эффект для сабдоменов и слабже, но он все равно есть.

Они же теперь такие на scaleway.com дают.

Ты еще 50 раз напиши эту простыню в каждом треде.

€23.99month
8 Dedicated x86 64bit Cores
32GB Memory
50GB SSD Disk
250GB Direct SSD Disk
1 Flexible public IPv4
800Mbit/s Internet bandwidth
5Gbit/s Internal bandwidth

50GB SSD Disk
250GB Direct SSD Disk

Что я не понимаю и в чем развод? Вроде типа железный сервак...

Так то вкуснее выходит. Мне 150гб ссд таки мало.

Что я не понимаю и в чем развод? Вроде типа железный сервак...

Ты про онлайн.нет так же говорил сначала :)
https://blog.scaleway.com/2016/03/08/c2-insanely-affordable-x64-servers/
«Развод» в том, что теперь появились крутые фишки - api, снапшоты и тд. Следующие буду тут брать, если останутся.

50GB SSD Disk 250GB Direct SSD Disk

Так это два ссд в серваке? Или 50 в нем, а 250 на каком-то общем ресурсе? (Правда тогда по иопсам жопа же будет).

Инвайт есть?)

Про ssd еще такое есть:

Volume are available per 50GB increments up to 150GB, with a maximum of 15 volumes per server.
Volumes are billed €1 /month per additional 50GB of SSD

На старшем тарифе выделенный ssd диск можно, видимо.
Инвайта нет, я думал их убрали. Очень хочу поюзать сам, но задач пока нет, все железо в онлайн.нет стоит. Поищу инвайт, если надо.

У старого домена возраст и условный траст выше

Ах, вы об этом. Ну это бесспорно. Только вышеобозначенное мною условие должно вводиться сразу же, на стадии проектирования, иначе будут костыли, редиректы и т.д. и т.п.
Если же какой-либо функционал не был запланирован для продвижения, то данный фактор имеет место быть. Но на самом деле это лишь временное ограничение, и при правильной организации не несет никаких ни недостатков, ни преимуществ. Любая крупная компания об этом знает, поэтому вводит отдельные домены без страха потерять что-либо.
К слову сказать, существуют еще и люди, которые готовы удавиться, если какие-либо страницы выпадут из выдачи. Лично знал строительную компанию в Екатеринбурге, которая тащила из проекта в проект кучи старых ссылок, отчего, в конце-концов они дотащили их до такой степени, что у них была аж отдельная база для редиректов. И каждый новый проект должен был ее учитывать. Город, кровь, похоть, шиза вообщем.
Вообще продвижение — не лучший аргумент, лучший аргумент — изначально чистое проектирование.

Читаю их сайт и все равно не могу понять: 50+250 идет в базе за 24 евро (дикая халява) или тут можно докупать до этого размера? А если докупать, то какой принцип? Некий общий на несколько хостов ссд делится между ними? Жопа же.

Кстати в онлайнете там 150гб ссдшки не говно вроде, какое-то интеловское серверное типа.

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

Вообще продвижение — не лучший аргумент, лучший аргумент — изначально чистое проектирование.

Вообще продвижение — не лучший аргумент для технического ресурса, лучший аргумент — изначально чистое проектирование.

Я не знаю, еще не юзал их. В любом случае, это в первую очередь альтернатива облачным vds, как я понимаю.

We're also introducing a new type of SSD on our C2L offer: Direct SSD. Direct SSDs (DSSD) are directly connected SSDs to the server through a SATA port to remove all bottlenecks. DSSDs are made for distributed database or data intensive applications. The C2L comes with 250GB of Direct SSD. Keep in mind that DSSD are tied to the physical server, they will be erased when you stop your server from the control panel.

Вроде как выделенный в комплекте на старшем тарифе.