Комментарии 17
ух ты! ссылки на документацию!
поверхностная статья для тех кто никогда в жизни не занимался локазизацией интерфейсов даже для языковой пары RU/EN.
Пустой рекламный перевод, суть которого дать ссылку на сайт конторы в начале и адрес конторы в конце.
Лучше почитате ресурсы W3C про локализацию — Internationalization Techniques: Authoring HTML & CSS
По поводу URL для локализации. Не всегда необходим свой URL для каждого языка. Мне даже больше нравится подход, когда где-то внутри хранится текущий язык (в cookie, например). При первом заходе на сайт определять этот язык автоматически. Таким образом будет одинаковая ссылка для филиппинца и русского. Но у каждого будет на своём языке. И русский сможет отправить ссылку немцу и она откроется не на русском, а на немецком. Для примера, так сделано в Tuffle.
А если необходимо именно на том языке на котором ты смотришь? Правильнее чтобы ссылка содержала идентификатор языка, а при переключении языка сайт переходил на версию страницы с требуемым языком.
А вот скажите, в каком практическом случае (хотя я не отрицаю их), может понадобиться такой случай, чтобы было именно на том языке? Да, такие ситауции могут быть, но в основном совсем наоборот, человеку нужен именно контент на его языке.
Прокси-серверы, а также кэш браузера в таком случае будут против. Тут можно на заголовок
Можно, конечно, использовать смешанный вариант — смотреть на заголовок, а если пользователь сменил язык — то записывать его в URL.
Accept-Language завязаться, но тогда пользователь не сможет поменять язык на самом сайте.Можно, конечно, использовать смешанный вариант — смотреть на заголовок, а если пользователь сменил язык — то записывать его в URL.
Разве добавление поддоменов/поддиректорий не является сегодня атавизмом? Контекст сервера хранит дефолтную локаль, а куки клиента указывают на предпочтительную, в результате чего всегда доступна текущая локаль пользователя. Содержимое страницы либо меняется языковыми метками при перегрузке, либо уже есть фреймворки «из коробки» на js, позволяющие динамически поменять текст на метках (и графическое сопровождение). Текущий язык отображается на странице.
Кстати, со статическим графическим сопровождением все тоже весьма неплохо, если организовать хранение графики на сервере упорядоченно: ссылки будут иметь вид src=«path/${lang}/some_picture.png», сервер подставляет язык и картинка с нужной языковой приявязкой отобразится на странице (понятно, многое зависит от платформы, но шаблонизаторы есть у всех).
Кстати, со статическим графическим сопровождением все тоже весьма неплохо, если организовать хранение графики на сервере упорядоченно: ссылки будут иметь вид src=«path/${lang}/some_picture.png», сервер подставляет язык и картинка с нужной языковой приявязкой отобразится на странице (понятно, многое зависит от платформы, но шаблонизаторы есть у всех).
Мне кажется, Вы слегка сами себе противоречите: с одной стороны «Разве добавление поддоменов/поддиректорий не является сегодня атавизмом?», и при этом: ссылки будут иметь вид src=«path/${lang}/some_picture.png». Понятно, что можно заранее подготовить локализованные картинки и разложить их в поддиректории по языкам, но если уж отказываться от поддиректорий, то внешне это должно выглядеть одинаково, что для URL всей страницы, что для отдельных ее элементов
В принципе, да, согласен, определенное противоречие есть. Просто подходил с точки зрения практичности, хотя пару манипуляций на сервере легко исправили этот нюанс — то есть абсолютный путь к статике на сервере может определяться в том числе на основе локали из контекста сервера, а публичный url к нему — единый. И это было бы правильно, и «в одном стиле». Банальный недосмотр ))).
Европеоидные советы. под ту же Азию надо менять само визуальное представление, например (макеты и верстка совсем другие).
Кроме совета о размерах элементов ничего нового или оригинального не узнал. Слишком много букаф для такого откровения
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как создавать сайты, готовые к локализации