Pull to refresh

Comments 17

ух ты! ссылки на документацию!
поверхностная статья для тех кто никогда в жизни не занимался локазизацией интерфейсов даже для языковой пары RU/EN.
Пустой рекламный перевод, суть которого дать ссылку на сайт конторы в начале и адрес конторы в конце.
По поводу URL для локализации. Не всегда необходим свой URL для каждого языка. Мне даже больше нравится подход, когда где-то внутри хранится текущий язык (в cookie, например). При первом заходе на сайт определять этот язык автоматически. Таким образом будет одинаковая ссылка для филиппинца и русского. Но у каждого будет на своём языке. И русский сможет отправить ссылку немцу и она откроется не на русском, а на немецком. Для примера, так сделано в Tuffle.
А если необходимо именно на том языке на котором ты смотришь? Правильнее чтобы ссылка содержала идентификатор языка, а при переключении языка сайт переходил на версию страницы с требуемым языком.
А вот скажите, в каком практическом случае (хотя я не отрицаю их), может понадобиться такой случай, чтобы было именно на том языке? Да, такие ситауции могут быть, но в основном совсем наоборот, человеку нужен именно контент на его языке.
Ну например, браузер автоматически определил язык как китайский, и что я увижу — кучку иероглифов?!
1) Очень странно что твой браузер определит китайский, если ты его не знаешь
2) Рекомендуется делать смену языка на самом видном месте, чтоб его можно сменить язык совсем не знаю текущего.
Второй пример, индексация контента поисковыми роботами
В современном мире поисковые роботы умеют индексировать мультиязычный контент, нужно всего лишь пару мета-тегов добавить
Прокси-серверы, а также кэш браузера в таком случае будут против. Тут можно на заголовок Accept-Language завязаться, но тогда пользователь не сможет поменять язык на самом сайте.

Можно, конечно, использовать смешанный вариант — смотреть на заголовок, а если пользователь сменил язык — то записывать его в URL.
Разве добавление поддоменов/поддиректорий не является сегодня атавизмом? Контекст сервера хранит дефолтную локаль, а куки клиента указывают на предпочтительную, в результате чего всегда доступна текущая локаль пользователя. Содержимое страницы либо меняется языковыми метками при перегрузке, либо уже есть фреймворки «из коробки» на js, позволяющие динамически поменять текст на метках (и графическое сопровождение). Текущий язык отображается на странице.
Кстати, со статическим графическим сопровождением все тоже весьма неплохо, если организовать хранение графики на сервере упорядоченно: ссылки будут иметь вид src=«path/${lang}/some_picture.png», сервер подставляет язык и картинка с нужной языковой приявязкой отобразится на странице (понятно, многое зависит от платформы, но шаблонизаторы есть у всех).
Мне кажется, Вы слегка сами себе противоречите: с одной стороны «Разве добавление поддоменов/поддиректорий не является сегодня атавизмом?», и при этом: ссылки будут иметь вид src=«path/${lang}/some_picture.png». Понятно, что можно заранее подготовить локализованные картинки и разложить их в поддиректории по языкам, но если уж отказываться от поддиректорий, то внешне это должно выглядеть одинаково, что для URL всей страницы, что для отдельных ее элементов
В принципе, да, согласен, определенное противоречие есть. Просто подходил с точки зрения практичности, хотя пару манипуляций на сервере легко исправили этот нюанс — то есть абсолютный путь к статике на сервере может определяться в том числе на основе локали из контекста сервера, а публичный url к нему — единый. И это было бы правильно, и «в одном стиле». Банальный недосмотр ))).
Европеоидные советы. под ту же Азию надо менять само визуальное представление, например (макеты и верстка совсем другие).
Кроме совета о размерах элементов ничего нового или оригинального не узнал. Слишком много букаф для такого откровения
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2004
Website
alconost.com
Employees
201–500 employees
Registered

Habr blog