Про локализацию сервисов под разные страны.

1. В одной стране может быть (а скорее и очень быстро потребуется) более одного языка. Например, в России потребуется русский и английский.

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

3. Если у Тебя хоть сколько-нибудь нормальный клиент-сайд интерфейс, то переводы потребуется и для него на стороне клиента.

4. Тебе потребуется хранить переводы двух типов - короткие фразы (используются для интерфейсов и поясняющих подписей) и длинные тексты (маркетинг, faq, юридическая документация типа оферты и др).

5. Тебе потребуется перевод картинок на языки (причём для разных стран, опять-таки разные). Причём есть картинки как интерфейсного плана, так и тупо скриншоты. Причём совершенно точно известно, что не все картинки поддадутся автоматизированном наложению генерящихся надписей. И, кстати, для некоторых языков потребуется отдельно доставлять шрифтовые пекеджи.

6. Когда Ты соберёшься передавать тексты в перевод, то для каждого короткого текста потребуется комментарий, который описывает контекст, в котором нужен перевод (одно и тоже слов, как Ты знаешь, может иметь несколько значений). Более того, в такой комментарий потребуется точный перечень мест в интерфейс (и как до него добраться), где оно используется.

7. Во всех переводах (коротких и длинных) надо не забыть проставить макросы для вставки как минимум доменных имён и валют, если они отличаются.

8. Таймзона в БД имеет значение. И вывод времени в нужной таймзоне тоже. В отдельных сложных случаях без костылей не обойтись. Например, по тайландскому летоисчислению, сейчас 2563 год.

9. Проект must be in UTF-8. Иначе вымрешь сразу же.
Вывод чисел с десятичной точкой в разных странах отличается. Будь готов.

10. Поиск по сайту. Каким бы ты не пользовался движком, важно знать, - все европейские языки, включая русский, процессятся специальным стеммером Snowball. Это такая штука, без которой орфография не будет работать вообще. НО для некоторых языков Snowball-а не хватит и движок заточенный под работу с ним станет бесполезной обузой. Чтобы решить проблему поройся по интернету и разберись, какие бывают стеммеры. Да, кстати, для некоторых языков символ пробела (" ") не является разделителем слов (сюрприз!).

11. Никогда не храни исходники текстов в html, - Ты его тупо не сможешь отдать на перевод, который тарифицируется по-символьно. Используй форматы типа wiki-markup или markdown.

12. Никогда не храни в .po файлах (это способ хранения коротких фраз для переводов с использование упомянутого тут всеми gettext) в лексемах что-либо кроме самого текста.

13. Для gettext-а НЕ ИСПОЛЬЗУЙ в качестве идентификаторов лексем русскую фразу, - ты не сможешь такой набор экспортировать на client-side.

UPDATE: Фил Д. просит добавить про RTL, про учёт разной плотности на разных языках, про разные сочетания календаря и отображения цифр на разных языках, про сложность выбора формата перевода (.po не очень удобен), про переводческие системы и так далее..

UPDATE2: Андрей Б. просит добавить про sjw

UPDATE3: Сергей В.: Время в базе всегда должно быть в UTC. А таймзоны — настройка рендеринга. Как темная и светлая тема, например.

Про сортировку забыли всяческих символов с закорючками

Касаемо разделителя слов. Пробел - не самая большая проблема.
Гораздо важнее знаки препинания, дефисы, специальные символы и модификаторы UTF.
Внезапно, й или ё в UTF-8 можно записать несколькими способами. Слово "чёрно-красный", в зависимости от контекста должно искаться не только исключительно как "чёрно-красный", но и "чернокрасный", "чёрнокрасный", "чёрный красный".
Знаки переноса так же должны учитываться, иначе в поиске будет треш.
Кроме того, если речь идёт о русском языке или текстах на русском и английском языках одновременно, необходимо учитывать опечатки в общих буквах для латинского и кириллического алфавитов.
Необходимо уметь обрабатывать сокращения и понимать, где точка используется как знак конца предложения, а где - как элемент сокращения С.С.С.Р., A.C.A.B и т.п.
Всё это очень сложно и большинство разработчиков не имеет достаточного уровня чтобы написать не то, что поиск, а даже токенизатор текста.

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

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

Ну и да: я уже предвижу возражения вида "какая разница, стеммер или лемматизатор", все всё поняли. Но это допустимо только на уровне научпопа для блондинок, а когда врач путает вирусы и бактерии - возникает вопрос о профпригодности.

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

Гораздо круче стеммер не работает в немецком. Какая-то версия Сноуболла из haben (иметь) делала h. Просто, блин одну букву h!!!!

это успех, определённо.

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

Ну какгбе нет. Ламинарный поток - это поток жидкости, для которого число Рейнольдса < 2300.

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

Ну и да: я уже предвижу возражения вида "какая разница, стеммер или лемматизатор", все всё поняли. Но это допустимо только на уровне научпопа для блондинок, а когда врач путает вирусы и бактерии - возникает вопрос о профпригодности.

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

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

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