Локализация html-страницы средствами CSS

[petruha]

Весьма оригинальный подход, но

Поисковые движки вряд ли проиндексируют тексты, записанные таким образом

— весомый минус.

[JustLuckyGuy]

ну почему-же? может наоборот стоит таким способом скрывать меню и другие не важные для контента вещи от поисковиков? тогда и по основным словам в статье будет находиться лучше.

[Veterinar]

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

[Stepanow]

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

[silkleo]

Боюсь, что это один из наиболее весомых минусов.

[mobilz]

присковики и js не могли долгое время сканировать, и pdf не читали итп.
Если применять технику активно, поисковики первые, кто подтянется. Точнее первым будет гугл, а остальные тут же схавают технику.

[j1nn]

вопрос, захочется ли именно вам (или вашему клиенту) быть первым

[lampslave]

Только отбились от оформления в HTML, так теперь норовят сам контент в CSS засунуть. Вот скажите, зачем забивать гвозди микроскопом? content предназначен для автоматических счётчиков и всяких разных меток, для оформления наконец. Никакого основного контента там быть не должно!

[silkleo]

Основной контент в него запихнуть и не получится. Хотя бы из-за разметки (болд, италик). А вот некоторые навигационные элементы… почему бы и нет? Если, например, названия классов сделать сокращенными, то вполне можно таким макаром сверстать какой-нибудь мобильный интерфейс в целях экономии траффика. Насколько мне известно, и мобильный Сафари, и мобильный Хром умеют кешировать CSS-файлы.

[lampslave]

Италик не проблема. Проблема в том, что это неправильно. Точно так же, как и применение классов типа .bold .float-left и т.п.

[silkleo]

Я предпочитаю оценивать правильность или неправильность конкретного решения исходя из условий поставленной задачи.

[lampslave]

Довольно странно отдавать мобильному браузеру английский html и русский css вместо русского html. Какая-то неправильная экономия.

[silkleo]

Что такое «русский хтмл»?

[lampslave]

Русский текст в html.

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

И ещё возникает проблема поддержки. Редактировать html (визуально) может любой. Для редактирования css нужен уже более подготовленный человек.

[silkleo]

Старые мобильные браузеры действительно могут не поддерживать content. Я это упомянул среди минусов. Мобильные Хром и Сафари точно поддерживают. Насчет браузера, встроенного в Мобильную Винду не знаю. Не было пока возможности проверить.

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

[lampslave]

А у Оперы Мини как с этим дела?

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

[silkleo]

На iPhone Opera Mini свойство content поддерживает. Вряд ли на других платформах с этим браузером ситуация обстоит иначе.

[lampslave]

Спасибо, буду знать.

[kastaneda]

мобильный хром?

[silkleo]

Я так зову браузер, встроенный по умолчанию в Андроид.

[Enuriru]

А почему вы считаете не правильным применение таких классов? Создав класс .red весьма удобно его применять везде, где надо сделать текст красным, и не плодя при этом дополнительные классы.

[silkleo]

Во-первых, на все цвета и случаи классов не напасешься.

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

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

[lampslave]

>.row-odd .row-even .last .first — костыльно, но допустимо, псевдоклассы ещё не все изобрели
Вообще-то изобрели, но поддерживаются они не везде.

[lampslave]

Если кто-то мне не верит, сильно рекомендую ознакомиться с селекторами CSS3. Там есть возможность выбирать и чётные, и нечётные, и первые, и последние элементы.

[norfild]

Зачем контент страницы хранить в CSS файлах 0_о

[silkleo]

Например, в целях экономии трафика для мобильных интерфейсов. Один из вариантов.

[GeniyZ]

Есть ещё один весомый плюс — частичное кеширование контента на стороне браузера!

И ещё отвечу сразу многим выше написавшим, что не надо мешать контент и оформление:
А вы положите этот каскадник отдельно от оформления — и не смешивайте их. Положите его в каталог locales, назовите его russian.css, если это для русских, а оформление храните отдельно. Раз не надо мешать — так и не мешайте =)
А индексировать поисковикам навигацию, например, и так не надо — они и сами пытаются её фильтровать. А таким образом локализовывать, допустим, статьи целиком — конечно не самый лучший вариант.

[garex]

Можно еще чуть проще сделать и стопицот кроссбраузерно:

[style] .lang {display: none} body.ru lang.en, body.ru lang.ru {display: block} [/style]
[body class=«ru»]
[div class=«menuitem»]
[span class=«lang en»]Menu[/span][span class=«lang ru»]Меню[/span]
[div/]

зы: Но все-таки микроскоп надо беречь :)

[garex]

+1

[Veterinar]

Милостивый Аполлон, сжалься и ослепи меня своими стрелами.

[k12th]

А как насчет локализации с помощью DTD?

[silkleo]

Можно пример?

[k12th]

Извольте:) Для этого достаточно открыть в FF страницу about:mozilla и посмотреть, как она устроена.

Кстати, в этом варианте нет проблемы с <em/>.

[silkleo]

Хм. Занятно, спасибо за наводку.

[helvar]

Подход интересный, но имеет очень ограниченное применение. Локализация — это не только меню, но и все тексты на сайте. А они часто берутся из БД. В этом случае CSS для перевода не помощник.

[silkleo]

Конечно. Данный способ с моей точки зрения подходит (если вообще подходит) лишь для локализации элементов дизайна. Меню, вспомогательные ссылки.

Локализовать таким макаром контент страницы во-первых, довольно неудобно по ряду причин, а во-вторых, не имеет смысла. Дело в том, что меню на сайте на всех страницах +– одинаковое. Именно поэтому его имеет некоторый смысл кешировать через CSS-файл. Содержимое же страниц у нормального сайта уникально.

[mobilz]

а мне кажется, это охуенно

[fcunited]

Лебедев?

[fatal]

Вы скорее всего перепутали XSLT (eXtensible Stylesheet Language Transformations), созданный для преобразования содержимого с CSS (Cascading Style Sheets), созданный для оформления содержимого.

[Wott]

С точки зрения оптимизации файлы css, которые нельзя склеить — зло. Хотя есть альтернативные link и прочее, лучше работать через класс для body и иметь классы в соответствующих «локалях»:

body.lang_en .b-menu__item_name_main .b-menu__curr:after,
body.lang_en .b-menu__item_name_main .b-menu__link:after
{
    content: 'Main Page';
}

body.lang_ru .b-menu__item_name_main .b-menu__curr:after,
body.lang_ru .b-menu__item_name_main .b-menu__link:after
{
    content: 'На главную';
}

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

[silkleo]

Можно и склеивать оба файла в «main.css» по принципу: впереди идет язык по умолчанию, затем подклеивается кастомный язык. Тогда файл будет один (соответственно, будет и один запрос).

[Wott]

lol, и как это прокэшировать? :)

[silkleo]

Учитывая, что на выходе получится обычный css-файл, суть вопроса мне не очень понятна.

[Wott]

Разные пользователи, разные установки, разные файлы.
Один main.css тут просто не получиться — его содержимое будет случайным :)

Я молчу что зависимость от последовательности склейки — самое то по-геморроиться.

[silkleo]

Создаем несколько «склеек»: main.ru.css, main.en.css, main.ua.css. Способов это сделать автоматически — вагон.

Далее остается только получить из куки (ее все равно придется использовать) или из какого-либо иного источника две буковки, обозначающие язык. И соорудить с помощью используемого шаблонизатора конструкцию <link href="/css/main.{% lang %}.css"/>.

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

[Wott]

Ага и получаем несколько разных сборок css, конечно же столько же вариантов html на один запрос и получаем кэш разбухший в несколько раз и вследствие этого в несколько раз больше нагрузку на сервер :)

Продолжайте наступать на чужие грабли. Учиться исключительно на своем — это национальный спорт!

[silkleo]

Чего я никогда не мог понять в людях, так это подобных язвительных пожеланий. Ну, да и ладно.

[FladeX]

Идея весьма интересная, но есть же принцип: «представление — html, оформление — css, поведение — javascript», который в данном случае нарушается.

Но за поиск нестандартных решений автор топика явно заслужил похвал :)

[uglymeta]

Добавлю от себя по одному пункту к плюсам и минусам:
— плюс (на мой взгляд): созданный средствами css текст — не «выделябельный», удобно копирастам, беспокоящимся за лёгкое копирование текста, не нужно городить скрипты для запрета выделения текста
— минус: консольные браузера не понимают эти стилевые правила, отображается пустота.

[lahmatiy]

— плюс (на мой взгляд): созданный средствами css текст — не «выделябельный», удобно копирастам, беспокоящимся за лёгкое копирование текста, не нужно городить скрипты для запрета выделения текста

Он «выделябельный», если начинать выделять не с него, к тому же в IE и Opera он прекрасно копируется (в Opera к тому же это совсем обычный текст).

[adminimus]

За оригинальность, несомненно, пятерка.
Для статичных страниц может быть и можно применить, особенно если это страница-визитка верстальшика.
Для динамических страниц малопригодно. Как, например, можно на css локализовать фразу «Осталось %d элементов» с учетом того, что на английском порядок слов будет другой? А если еще и параметр будет меняться скриптом на лету…
Ну и переводить css придется руками, удобных инструментов для облегчения жизни еще нет.

[muromec]

>Ну и переводить css придется руками, удобных инструментов для облегчения жизни еще нет.

конвертер из PO файлов — как два пальца.

[muromec]

а я такое полгода назад даже хотел сделать (для профилей на exp.io), но мне вовремя дали по рукам.

основной профит от такого извращения в том, что некоторые страницы можно было вообще не рендерить, а отдавать готовый кеш из базы, который достается одним key-value запросом, если бы не чертова локализация менюшек.

[mdss]

коммент в тему
chikuyonok.ru/2010/01/css-content/#comment-2599

[impass]

бессмыслица какая-то
уж лучше XSLT применять, в т.ч. на стороне клиента

[dyakov]

Боролись, боролись с таблицами. И тут на тебе, весь html в css… :-)

[reinkarnator]

Это бессмыслено, мы экономим каплю воды в океане, нежели думать о реальных экономиях. Ну и что мы тут съэкономим? Для вывода теста есть HTML, а для обрамления CSS другого не дано, и не надо.