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

Короче, Склифасовский, поддомен или каталог?)

google имеет домены в каждой стране

intel.com и intel.ru имеет оба варианта, а так же у них открывается каталог /ru/

голосую за каталог.

Попросил инвайты себе и тебе, должны скинуть на твое info@артстудио3д

Расскажи потом о впечатлениях если будешь юзать.

Ну для вашего варианта,я думаю, каталог. Это будет и проще, и фактор возраста домена останется. Вы же сами сказали что это будут сайты визитки. Тогда не стоит усложнять себе жизнь. Как там это называется? Ах да, KISS.

Пасиба! Надеюсь, придет. А то я на эту же почту форму на их сайте заполнил.

Не придет, давай второе мыло.

Облом, кончились. Удаляй мыло, или жди пока ветку потрут за личную переписку :)

Как теперь жить то?!

dk-, а этот твой сайт посвященный фото на вордпрессе сделан? Прост, тоже о сайтике задумался. И кто его делал, где хостишь? : ] /newpunkies

Вариант с директорий выглядит более приемлимым, плюс не нужен wildcard сертификат. Если на сайте есть что-то типо личного кабинета и используется CMS, то можно иметь таблицу с языками и отдавать нужные значения при генерации страницы. Язык наверно лучше детектить по geoip, но в случае чего откатываться на «Accept-Language» заголовок. Хотя вариант, с заголовком скорей всего будет более приемлимый, потому-что вариант с geoip, может раздражать некоторых пользователей. Субдомены как мне кажется лучше использовать для разных тематик или в случае если сайт на другой версии языка поддерживает отдельная группа, а вариант с покупкой отдельного домена в нужной tld для них невозможен. Да может быть вообще отдельный файл с локализациями в проекте, особено если нужно поддерживать специфичные языки.

Не, там голый хтмл пока. Вот такой: http://startbootstrap.com/template-overviews/modern-business/

Руками поправил нужное.

Живет тут: https://www.online.net/en/dedicated-server/dedibox-xc

Можно сделать наверху кнопку переключения языка. Выбранный язык писать в куки и отдавать страницу на нужном языке в зависимости от кук, на одном url, да. При этом по умолчанию отдавать страницу на предпочитаемом (юзером) языке, а можно и на основе IP попробовать угадать. Но возможность переключить всё равно должна быть у пользователя и не запрятана никуда.

Переключалка, само собой в шапке сайта на видном месте.

Но варианты с куками и прочим - все кривые. Как дать ссылку на конкретном языке? Как индексироваться?

Разницы нет, как удобней, так и делай. Я бы через /lang/ сделал, чего плодить лишние сущности.

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

Спасибо! Годный шаблон, только хостинг дороговат. И кстати в каком банке предпринимательский счет обслуживаешь и какой бы порекомендовал?

Как дать ссылку на конкретном языке?

Можно дать возможность указывать язык в get-параметрах, ?lang=ru, например.

Как индексироваться?

С этим сложнее, да.

По сабжу, если без кук, а обязательно чтобы были разные URL для индексации, то принципиальной разницы между поддоменом и элементом между слешами нет. Делай, как кажется эстетичнее или монетку брось. Я бы сделал не поддоменами, а через sitename.org/ru и sitename.org/en и т. д.

Я тоже склоняюсь к каталогу. Чтоб домен был всего один. Домен то старый, и в дорвеях не замешанный.

Я в ПСБ живу сейчас.

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

Если платежек много, то выгоднее купить тариф на котором Нное их количество включено в абонентку. Чтоб не платить % за перевод.

сам тоже к такому же выводу пришел :] , скорее всего пока первый вариант ближе: Если операций мало, выводы крупные и разовые, то устроит минимальный пакет. Выбирать по абонентке.

Кстати (не реклама!11), почему во всех банках ИП заставляют какой-то особый счет регать? ИП вообще может бухгалтерию не вести это во-первых, во-вторых все деньги ИП это его личные деньги, т.е. физ. лица, зачем тут особая плата? Можно ли например для предпринимательской деятельности счет как для физ. лица открыть и по нему УСН 6% вместо ндфл платить?

ПС я думаю тинькофф банк юзать, они мне видятся более адекватными в этом плане:

https://www.tinkoff.ru/rko/search/form/otkrytie-raschetnogo-scheta/

dk-, может тебе тоже будет полезно, глянь не замануха ли этот тинькофф банк? У тебя хоть опыт есть, а то даже мне юристу сложно в этом разбираться... Правда еще толком не брался за это, других дел полно...

ППС у ПСБ куча расшифровок :]

тиньков крутой банк.

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

можно и nginx настроить. чтобы он проксировал запросы с /blog/ на одну виртуалку, запросы с /forum/ на другую, и обойтись без создания поддоменов... но почему-то так мало кто делает, хз почему.

Потому что это лютый фейл с точки зрения безопасности. XSS на /wpblog сразу компрометирует /биллинг/панель. Кроме того, пофантазируй на тему поддерживаемости сабдиректорий различными CMS и прочими системами, работе COOKIE (коллизии ибо фиг знает, какие название кук и другие параметры использует 3rd party CMS X; возможно, лишние заголовки, почему, думаешь, статику на отдельный домен выносят). И прочий геморрой, который нафиг не сдался, ибо можно и нужно использовать сабдомен, а не эстетствовать по поводу количества A, CNAME, whatever записей.

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

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

Язык наверно лучше детектить по geoip

Все кто это делает, должны гореть в аду. Заходишь на какой-нибудь сайт, а там, например:

في الحوسبة، والتدويل والتعريب (هجاء الصحيحة الأخرى هي التدويل والتعريب) وسيلة للتكيف برامج الكمبيوتر لغات مختلفة، والاختلافات الإقليمية والمتطلبات الفنية للسوق المستهدفة. التدويل هو عملية تصميم تطبيق البرمجيات بحيث يحتمل أن يتم تكييفها لمختلف اللغات والمناطق دون التغييرات الهندسية. التعريب هو عملية تكييف برنامج دولي لمنطقة أو لغة معينة عن طريق إضافة مكونات لغة محددة وترجمة النص. التعريب (التي يحتمل أن يؤديها عدة مرات، لغات مختلفة) يستخدم البنية التحتية أو المرونة التي توفرها التدويل (والتي يتم تنفيذها من الناحية المثالية مرة واحدة فقط، أو باعتبارها جزءا لا يتجزأ من التنمية الجارية).

Смотрю у них РКО для бизнеса появилось. Раньше не было вроде.

Но стремно как-то. ИП в 3-4ю очередь на возврат попадают, если банку каюк.

Спуфи, оставляй свои влажные фантазии на своём локалхосте.

Долго маялись с выбором. Были варианты и куков и поддерикторий. Хуже того - на сайте еще и регионы... В итоге пришли к тому что должны быть разные домены/поддомены. Не буду сейчас вываливать все за и против, просто рекомендую поддомены.

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

Microsoft, AMD, Blizzard и многие другие смотрят на тебя с недоумением.

Тоже долго маялись. Решили что регион детектится по ip, а язык по локале браузера. Регион и язык не зависят друг от друга. Каждому языку соотвествует свой поддомен, а регион может быть включен любой на любом поддомене. Все можно переключить в шапке и вручную.

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

Да ладно. Если отличия твоих юзеров в куках, а не сессии, то отлично работает. Просто надо указать ему куки от которых зависит кэш.

Смотря что за движок там. Если какой-нить битрикс то сомневаюсь.

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

С точки зрения seo подкаталоги предпочтительней.

Но, к сожалению, тяжесть фреймворков зачастую кладёт даже простые сайты гораздо раньше.

Может я не видел тяжелых фреймворков, я то работаю преимущественно с битрикс ;) Но то что вижу я - сайт кладет либо кривая архитектура, либо говнореализация, либо плохая архитектура + говнореализация ну или плохая архитектура еще два раза и плохая реализация еще три. Давеча пришлось рефакторить решение импорта данных с другого ресурса. 900 единиц данных импортировались около 2 часов, а потом я убила процесс. Да, там сложная и запутанная архитеткура, а API источника данных такой, что данные невозможно получать за 1 запрос. После рефакторинга 1200 единиц данных импортировались 7 секунд. Вот и представь какой должна была быть изначальная реализация... Фреймворк и архитектура остались прежними.

Так ты столкнешься с 2 проблемами - шаринг и индексирование поисковиками.

Просто надо указать ему куки от которых зависит кэш.

У меня другое представление о таком типе кэширования. Для меня это всё равно что ускорять программу путём отображения клиенту скриншота :). Нужен хотя бы способ инвалидировать кэш со стороны бэкенда. Но простым сервисам это не нужно :).

Что вызывает сомнения?

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

Может я не видел тяжелых фреймворков, я то работаю преимущественно с битрикс

Ха-ха, шутку оценил. Но да, если статически отрендерить страницы и отдавать их то оно может и заработает. Типичная инсталляция битрикса по-прежнему создаёт over 100k файлов на диске?

Ключевое слово — выкупать. А как это реализовано на уровне приложений, в-принципе, не важно для клиента. На этом нужно поставить жирный такой акцент. Важно чтобы клиент из Германии, например, не задумывался что ему за папку, и с каким имененем нужно написать чтобы попасть на сайт, а просто писал nameCompany.{привычный_для_его_страны_домен_корневого_уровня(de)} Ну и само собой для любой крупной компании авто-определялки и прочие мелкие игрушки как-бэ сами собой подразумеваться должны, чтобы клиент, если знает основное зеркало компании (microsoft.com, скажем) вообще ни о чем не задумывался.
https://www.microsoft.de/
http://blizzard.de/
https://www.microsoft.fr/
http://blizzard.fr/
...etc...
Конечно же, не все компании так делают, но вообще как там говорят — «чем богаче, тем жаднее»? Большинство гигантов готово ухватиться за любую соломинку, лишь бы не потерять «потенциального» клиента. А выкупание разных доменов (не только по типу домена первого уровня, а просто похожих, доменов с ошибками, вот это все) это только скребок по поверхности.

Нужен хотя бы способ инвалидировать кэш со стороны бэкенда. Но простым сервисам это не нужно :).

Нужно чтобы он был достаточно коротким по времени. Если у тебя требуется достаточно долгое кэширование на уровне сервера это значит что у тебя сайт не способен нормально отработать запрос. Подумай сам, что значит кэширование на серваке с периодом в час? Это что - твой сайт не в состоянии обработать больше 1 запроса в час? На серваке нужне только быстрый кэш, чтобы например превратить 1000 qps в 1 qps или даже в 0.1 qps, а почти любые данные не устареют за 10 секунд. Ну а если это так - ищу другое решение.

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

Только сегодня прикрутил кэш на сайт которому уже 8 лет. Битрикс не обновлялся. Сайту резко полегчало. Там просто надо его уметь готовить. Использование кэша на битрикс на уровне CMS действительно не всегда удобно и хорошо. А на старых версиях вообще трэш. Но на уровне фреймворка все работает на ура и сколько себя помню - всегда так работало.

Типичная инсталляция битрикса по-прежнему создаёт over 100k файлов на диске?

Ну это да. Однако именно в этом я никогда не видел большой проблемы. Немножко странный роутинг для 2016 года, устаревший лет этак на 10, но и только. Это пережить лично мне гораздо проще чем User::whereNameOrEmailOrPhoneOrAddressOrSurnameOrAllahOrSky (это не битрикс если чо, а модная хипстерская поделка и оригинал не лучше: whereNameAndEmailOrPhone).

разбаньте меня пжлст, через пару месяцев буду кучу «интересных» вопросов задавать :~]] /newpunkies

User::whereNameOrEmailOrPhoneOrAddressOrSurnameOrAllahOrSky (это не битрикс если чо, а модная хипстерская поделка и оригинал не лучше: whereNameAndEmailOrPhone).

User::whereNameOrEmailOrPhoneOrAddressOrSurnameOrAllahOrSky

Такое, без шуток, еще существует? :)

ага, в конце 15го года. Почитал про него и правда крутой банк, не думаю, что он бабахнет...

Нужно чтобы он был достаточно коротким по времени.

Это то что я называю говнокэшированием. Кэш должен быть не «коротким», а инвалидироваться когда данные изменились. Да, я тоже делал затычки с «коротким кэшем» тщательно выбирая между «только бы сервер не здох» и «только бы посетители не просекли что данные старые». Сделать как надо значительно сложнее чем подкрутить nginx, я знаю. На это в принципе никто не закладывается в начале разработке, а потом уже поезд уехал.

Использование кэша на битрикс на уровне CMS действительно не всегда удобно и хорошо. А на старых версиях вообще трэш.

У меня опыт только со старым битриксом. Без кэша на двухголовом ксеоне оно жало что-то вроде 2qps на ядро. С кэшем аж целых 10 или типа того :). Но, конечно, при отключении всяких фееричный модулей типа «лог посещений кладём в базу» или какого-нить модуля погоды могло резко полегчать. С тех пор много воды утекло, знаю. Но стало ли оно кардинально быстрее — ты мне скажи.

Только сегодня коллега показывал. Оно там автогенерируемое как я понял, но я только одного не понял - почему там так можно: User::whereNameAndEmail('jon', 'jon@theWall.com')->first(); а так нельзя: User::whereNameAndEmail('jon', 'jon@theWall.com')->oneHundredFiftySecond();

Органично бы смотрелось.

Это то что я называю говнокэшированием. Кэш должен быть не «коротким», а инвалидироваться когда данные изменились.

Вы как-то упоминали, ЕМНИП, что работали с битриксом, вообще если вы работали с PHP, то должны знать что большинство людей, сидящих на нем, вообще не знают каких-то там слов invalidate/level-cache/somemagic. У них есть просто контент, который они сохраняют (целыми страницами) в файлы, и устанавливают на них время. А потом на известных форумах по PHP утсраивают баталии о оптимальном «времени жизни кэша». Если вы вдруг скажите такие людям что кэш может быть частичным, или что кэш можно хранить прямо в раме — боюсь, у этих людей произойдет сбой системы.
К слову, это не вброс. Вот прям реально знавал в свое время таких людей. Я думал что они вымерли уже сейчас. Но я жестоко ошибался, они даже на ЛОР'е есть (Шок).

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

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

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

Я надеюсь вы пошутили. Я не спец. в PHP, конечно. Но когда я вижу User -> я подразумеваю под этим ООП, а сл-но — модель. И не верю что модель может иметь какие-то специфические методы (вообще неважно что они там делают и как, модель это просто модель, ну максимум через доп. прослойку она может для вас еще как AR поработать, но никак не быть генератором говна). В любых схемах проектирования есть возможность делать это отдельно от модели. Во всяких популярных MVC там, для этого есть компоненты. Вот пусть они генерируют специфичное говно, но модель должна быть чиста как младенец (за исключением своих прямых обязанностей). Жирная модель для меня еще хуже жирных контроллеров. Мне просто плохо становится, когда я вижу как над бедной схемкой для хранилища данных издеваются всякие извращенцы :)

юзать битрикс как фреймворк с удобной админкой

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

форум как был трудно кастомизируемым говном так и остался

Некоторые вещи не меняются...

Вы как-то упоминали, ЕМНИП, что работали с битриксом, вообще если вы работали с PHP, то должны знать что большинство людей, сидящих на нем, вообще не знают каких-то там слов invalidate/level-cache/somemagic.

У битрикс давно есть инвалидируемый кэш. Его там называют тэгированным. Вот бы его еще кто-то использовал. Впрочем я за то чтобы кэш оставался многоуровневым - кэш на сервере/кэш выхлопа/кэш данных/кэш запросов. Причем кэш данных тоже может быть многоуровневым. Плюс для не инвалидируемого кэша (а и его надо использовать когда надо) должны быть выбираться правильные интервалы, дабы они не истекали все разом. Вобщем кэш это сложная и долгая история.

кэш можно хранить прямо в раме

Ты сейчас про кэш в раме или про мемоизацию?

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

До сих пор толком не знаю как оно работает, так как идет под нож сразу после установки.

вообще не знают каких-то там слов

Раньше для этого тупо не было нормальных инструментов. Щас много фреймворков новых навороченных появилось, они поднабрались из django, рельсов и прочего. В них всё есть. Было бы желание... Но я стараюсь не держать всех php-разработчиков за дураков. Среди них есть толковые ребята, причём, среди моих знакомых. У меня уже не получается их троллить «а вот у вас этого нет».

Да я и сам иногда на js «пописываю», хотя клялся этого не делать. Правда, я юзаю самые последние навороты, с ними не так больно :). У них даже yield есть :). Неужели тебе callback hell ушёл в прошлое... Ушла эпоха :).