?

Log in

ЖЖ-логия: русификация ЖЖ - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

ЖЖ-логия: русификация ЖЖ [сент. 11, 2001|01:33 pm]
Anatoly Vorobey
Эта запись обращена в первую очередь к программистам, а также специалистам по проблемам языков и кодировок на веб-страницах и в веб-проектах. Но и ко всем вообще, кто хочет высказать своё мнение.

Уважаемые программисты-специалисты!

Сейчас идёт обсуждение того, как улучшить и приспособить ЖЖ для нужд юзеров, пишущих и читающих на самых разных языках, кроме английского. Общее отношение к этой задаче у разработчиков и админов ЖЖ (в частности, у главного decision-maker'а bradfitz) самое положительное, все хотят это сделать. Просто до сих пор руки не доходили этим заниматься.

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

Можно разделить проблему на две части.

1. Русификация юзер-интерфейса (и вообще локализация его на разные языки).
2. Поддержка кодировок и языков в записях и комментах ЖЖ, в частности, на уровнях хранения
в базе данных и передачи браузеру юзера.

Проблема 1. относительно несложная. В одном из своих предыдущих проектов bradfitz уже сделал схему поддержки многоязыкового интерфейса, которая скорее всего будет приспособлена для целей ЖЖ. См. http://www.freevote.com . Переводить менюшки, страницы и т.п. с английского на русский (и другие языки) должна будет небольшая команда (команды) добровольцев. Для каждого языка (так мне сейчас представляется, если можно лучше - поправьте) будет храниться своё название кодировки, к-е будет прописываться в атрибуте HEAD каждой служебной HTML-страницы (служебная страница = всё, кроме дневников и дружеских с календарными лент. Т.е. то, что кончается на .bml).

Основные сложности заключаются во второй проблеме. Как дела обстоят сейчас? Любой текст записывается в базу данных в виде 8-битного потока. Если он туда был отправлен в какой-то кодировке, то потом, чтобы его правильно посмотреть, у юзера эта кодировка должна быть правильно прописана. Например, в русском ЖЖ мы де-факто стандартизировались на cp-1251.

Кроме того, время от времени IE по каким-то своим причинам посылает серверу ЖЖ не 8-битный текст, а переводит все русские буквы в Юникод и посылает их в виде HTML-entities типа Ӓ Серверу на это плевать, он их в таком же виде записывает в БД и выбрасывает потом юзеру.

Чего хотелось бы добиться?
1. The Right Thing. Главным критерием bradfitz'а и остальных здесь является сделать не как попроще, чтобы отвязаться, а как правильно, в соответствии со стандартами, и чтобы юзерам было поудобней.
2. Любой текст, записываемый в БД, должен быть идентифицирован с точки зрения его кодировки. Т.е. например он либо сразу должен быть в Юникоде, либо, если это 8-битный текст, вместе с ним должна быть записана информация о кодировке и/или языке.
3. Желательно придумать решение, позволяющее многоязыковость в пределах одной страницы. Например, я запишу себе в друзья японца, француза и русского; хотелось бы их записи все видеть правильно на одной френдовой ленте.

Какие пока придуманы варианты?

На входе:
1) Брать тот же восьмибитный поток от браузера, но не забывать про информацию о кодировке (если я правильно помню, браузер прописывает её в HTTP-заголовках?). Хранить информацию в базе данных в том же виде, что и сейчас, плюс кодировка для каждой записи/комментария.
2) Брать восьмибитный поток от браузера и переводить его в чистый Юникод при помощи информации о кодировке. После этого в базе данных хранить одним из двух способов:
2а) перевести все Юникод-символы больше 128 в HTML-entities типа Ӓ , полученный текст хранить как восьмибитный поток, как и раньше.
2б) хранить в БД сам Юникод как-он-есть, например в кодировке UTF-8.

На выходе:
3) Брать текст вместе с кодировкой, записанный в варианте 1) выше, и выкидывать его наружу без изменений. Кодировку прописывать в заголовок страницы. Этот вариант, однако, не позволяет соседствовать на одной странице записям/комментариям на разных языках/в разных кодировках.
4) Брать текст из БД, как бы он там ни был записан, переводить его в Юникод (если он ещё не в Юникоде), из Юникода в HTML-entities, и в таком виде кидать юзеру. Недостатки: больше траффика (но страницы зипуются сервером, если браузер это понимает, так что это, возможно, не так страшно); все ли браузеры правильно поймут и покажут HTML-entities?
5) Брать текст из БД, как бы он там ни был записан, переводить его в Юникод (если он ещё не там), и кидать его в UTF-8 юзеру, прописав UTF-8 в качестве кодировки на странице. Недостатки: все ли браузеры правильно понимают и интерпретируют кодировку UTF-8?

Какие вопросы надо решить:
  • Какие из вышеприведенных опций стоит выбрать?
  • А может быть, есть другие варианты, которые можно предложить?
  • Какие существуют проблемы с популярными браузерами? В этой области я вообще ничего не знаю, так что особенно нужна помощь. Особенно важно: можем ли мы положиться на то, что браузер всегда передаёт серверу правильную информацию о кодировке, когда он кидает ему текст из формы? Правильно ли себя в этой области ведут Эксплорер, Нетскейп, Опера и т.п.? Нужно ли что-то специально прописывать в форме? Этот вопрос особенно важен потому, что нужно решить, можем ли мы расчитывать на то, что всегда сможем корректно перевести входные данные в Юникод.
  • Тот же вопрос, но о браузерах на выходе. Что они понимают, а что нет, из предложенных ршений?
  • Ну и вообще любые предложения и замечания.

    Спасибо!

    P.S. Если у кого-то есть желание присоединиться к команде разработчиков ЖЖ, то они все тусуются в этих двух местах: lj_dev и http://lists.livejournal.com .
СсылкаОтветить

Comments:
[User Picture]From: a_v
2001-09-11 03:41 am

Encodage

Согласен, лихтов бе-иврит, например, совершенно неудобно, да и с французским сложности из-за акцентированных букв. Постараюсь подумать!
(Ответить) (Thread)
[User Picture]From: kukutz
2001-09-11 04:01 am
Я не знаю, КАК, но мой IE показывал мне на одной странице и khatul (иврит), и русский всех остальных...
(Ответить) (Thread)
[User Picture]From: avva
2001-09-11 04:50 am
Ага, я знаю как. khatul заставлял свой IE посылать свои записи как HTML-entities. Но это работало только в одну сторону, т.к. Ваши русские записи (и все остальные русские записи) были в восьмибитной кодировке. Если бы их попытался читать кто-то с компьютером, настроенным на иврит, он увидел бы мусор.
(Ответить) (Parent) (Thread)
[User Picture]From: sova
2001-09-11 07:55 am
I see his discussion fine (all three languages) on Windows 98 Hebrew Enabled, IE 5.01, encoding set to Cyrillic
(Ответить) (Parent) (Thread)
[User Picture]From: amzin
2001-09-11 05:33 am

Угу, но вот тут начинаются проблемы...

(Ответить) (Parent) (Thread)
[User Picture]From: stas
2001-09-11 06:27 am

Re: Угу, но вот тут начинаются проблемы...

У меня видно и греческий и иврит...
(Ответить) (Parent) (Thread)
From: ex_eremei502
2001-09-11 04:43 am
Анатолий,

речь идет о сугубо технической стороне дела или также и об удобстве для пользователя на чисто "чайницком" уровне? Если второе в рамках этой темы уместно, готов высказать посильные соображения.
(Ответить) (Thread)
[User Picture]From: avva
2001-09-11 04:48 am
Михаил,

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

(НБ. Прошу прощения за молчание в политической теме, всё-таки для меня разговоры о политике играют отчётливо вторичную роль, и был очень занят эти пару дней. Постараюсь ответить в ближайшее время).
(Ответить) (Parent) (Thread)
From: ex_eremei502
2001-10-28 05:19 am

Лучше поздно, чем никогда

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

1. Не хватает опции "подписки" на конкретный топик и все реплаи, чтобы отслеживать ход интересной дискуссии в чужом дневнике в тех случаях, когда реплай идет не мне.

2. Не хватает опции "подписки" на все постинги конкретного автора - не только дневниковые, но и в "ветках". (Кроме сознательно закрытых, разумеется.) То есть, чтобы я мог, допустим, посмотреть все открытые постинги Икса в их последовательности.

3. В Update Journal тоже не хватает опции Preview. Сначала я даже не мог поверить, что ее нет; вроде, напрашивается, да и в "ветках" есть. Но за два месяца так и не нашел.

4. Очень помогли бы еще два поисковика: (1) по упоминанию имени юзера или ника в чужих постингах и (2) - по ключевому слову. Подписка на упоминание собственного имени и/или ника тоже не помешала бы.

5. Отключив анонимусов в своем дневнике, в чужом я от них не защищен, если только не защищен сам хозяин топика (опять же, если я не зевнул эту опцию). Хорошо бы сделать так, чтоб первичными были установки автора, а не хозяина дневника.

6. Хотя бы для платных юзеров выделить по 2-3 мег для картинок. А в идеале бы для всех. Не у всех есть свои ХП, а со многих грузить картинки невозможно (как с моего Гео, например).

7. Сделать возможным просматривать топик с большим количеством постингов без "складушек", т.е. как единую ленту без отсылок и заужений.

8. Наконец, хорошо бы получать мэйлы по динамике френдс и френдс оф. К примеру, kot Вас вырубил, а pes, напротив, включил. Это, вроде бы, есть в клиенте, но не всем он нравится или понятен.

Вот, вроде, и все.
(Ответить) (Parent) (Thread)
[User Picture]From: arkanoid
2001-09-11 05:01 am

Кстати хотелось бы видеть почтовые нотификации в честном koi8-r plaintext 8bit.
(Ответить) (Thread)
[User Picture]From: xfyre
2001-09-11 05:40 am

хорошо хоть ты транслит не просишь ;)
(Ответить) (Parent) (Thread)
[User Picture]From: xfyre
2001-09-11 05:54 am
все решения кроме Unicode (то есть, конкретно UTF-8) являются идеологически неполноценными, потому что не позволяют смешивать разные языки в пределах одной страницы. с другой стороны, использование UTF-8 накладывает некоторые проблемы с браузерной и/или шрифтовой совместимостью. практически отсутствуют проблемы у MSIE >= 4.x, вроде бы все нормально у NN >= 4.x. при этом у пользователя должен быть установлен хотя бы один "натуральный" Unicode-шрифт с поддержкой всех этих языков (пример - Lucida Sans Unicode)

пример сайта по принципу "чистый UTF-8" - вот тут - все и хранится, и отображается именно в этой кодировке. проект у нас запущен уже три месяца как, вроде пока серьезных жалоб не было. прямо на этом сайте и можно, выбирая различные переводы, проверить все интересующие браузеры.

рендеринг в любом браузере практически гарантированно будет происходить корректно, если наличествует meta http-equiv="content-type" с указанным charset=utf-8

я полагаю, что в связи с потенциальными проблемами опцию "Unicode LJ" нужно сделать отключаемой на уровне настроек пользователя. с выдачей соответственных каждому случаю предупреждений относительно возможности-невозможности многоязычной френдовой ленты, предупреждения по поводу Unicode-шрифтов и т.д.
в идеальном варианте эта настройка вообще должна быть одной из настроек для специального раздела, типа, Locale settings, содержащего настройки языка интерфейса по умолчанию, способа форматирования дат, часовой пояс, предпочтительную кодировку для веба и почты (см. коммент arkanoid, а также эту самую отключаемую опцию Unicode

(Ответить) (Thread)
[User Picture]From: arkanoid
2001-09-11 06:04 am

Да, кстати - сделать принудительный unicode - так я сразу с мабилы ничего посмотреть не смогу :(
(Ответить) (Parent) (Thread)
[User Picture]From: auto194419
2001-09-11 06:09 am
Пользуйся рендерящей проксёй. Это наименьшая из проблем.
(Ответить) (Parent) (Thread)
[User Picture]From: arkanoid
2001-09-11 06:16 am

Муторно.. btw есть публичные?
(Ответить) (Parent) (Thread)
[User Picture]From: xfyre
2001-09-11 06:15 am
я ж написал специально - Unicode должна быть отключаемой. да и потом, у мабил по-моему нормальные отношения как минимум с UCS-16
(Ответить) (Parent) (Thread)
[User Picture]From: arkanoid
2001-09-11 06:25 am

C ucs-16 нормальные отношения у _некоторых_ мабил, которые умеют _wap_, а не html.
(Ответить) (Parent) (Thread)
[User Picture]From: avva
2001-09-12 04:09 pm
А что конкретно умеют мабилы? Какие страницы они могут смотреть?

Если тот же Юникод посылать в виде Ӓ , они справятся или нет?
(Ответить) (Parent) (Thread)
[User Picture]From: arkanoid
2001-09-13 02:48 am

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

Думаю, что такие устройства еще есть и кроме мабил.
(Ответить) (Parent) (Thread)
[User Picture]From: stas
2001-09-11 06:32 am
В Мозилле тексты на байбл-центре видны нормально, кроме надписи внизу про Internet Explorer - она каким-то сверхуродским шрифтом изображена. То же и внутри - половина текстов нормальным Ариэлем, а другая - каким-то уродством.
(Ответить) (Parent) (Thread)
[User Picture]From: trurle
2001-09-11 06:04 am
Надо ли использовать атрибут HEAD? Если в БД уже прописана кодировка, то ведь вроде бы лучше прописать ее в HTTP заголовках?
(Ответить) (Thread)
[User Picture]From: xfyre
2001-09-11 06:17 am
если имеется в виду meta http-equiv - надо.
загадка природы, но прописывания charset в HTTP-заголовок оказывается недостаточно для принудительного рендеринга страницы в указанной кодировке

почему - не спрашивайте ;)
(Ответить) (Parent) (Thread)
[User Picture]From: auto194419
2001-09-11 06:08 am
Мне кажется, наиболее верно - хранить в UTF-8, и в ней и показывать всегда! Все современные browsers умеют нормально её отображать.

Notification же нужно посылать в заказанной кодировке - очень часто KOI8 или win1251 - далеко не лучшее решение.
(Ответить) (Thread)
[User Picture]From: xfyre
2001-09-11 06:18 am
положим, не все. порядка 95%, я думаю, но для интерактивного ресурса и 5% терять негоже. см. выше.
(Ответить) (Parent) (Thread)
[User Picture]From: avva
2001-09-12 04:05 pm
Понимаете, не совсем ясно, как сделать UTF8 опциональным для *некоторых* юзеров.

Если уж вводить UTF-8 в базу данных, то понятно, что это для всех. Предположим, сделали это. И что теперь выдавать юзеру, к-й не хочет видеть Юникод? Как и куда ему переводить? Кидать ему не charser=utf8, а HTML-entities? Или пытаться переводить в кодировку его выбора, теряя по пути не вползающие в неё символы?

Помогите мне, я не совсем понимаю, как лучше это сделать. Самое главное для меня - избежать nightmare scenario, при котором Брад по моей рекомендации переводит всю базу данных на Юникод, а потом оказывается, что большому количеству юзеров это всё ломает. Я ж тогда застрелюсь от стыда ;)
(Ответить) (Parent) (Thread)
[User Picture]From: xfyre
2001-09-13 05:50 am
charset базы данных и charset, в котором контент выводится и/или вводится в БД - две большие разницы. это хорошо видно на примере Oracle - character set там задается при создании БД, а пользователь работает с тем, что у него определено переменной окружения NLS_LANG (под пользователем я в данном случае имею в виду скрипт, занимающийся рендерингом контента). перекодировка происходит на лету средствами БД. я почти уверен, что в других реализациях это тоже возможно.

то есть, резюмируя - в нормальных реализациях database character set определяет не то, в чем будет контент _выводиться_, а то, в чем он будет _храниться_. использование utf-8 в качестве DB character set не вынуждает к его использованию в качестве клиентского, а позволяет его использование в качестве клиентского. вот как-то так.
(Ответить) (Parent) (Thread)
[User Picture]From: vadimkle
2001-09-11 06:19 am

мало того

мне нотификация каким-то неясным образом приходит в KOI8 - так и ответ, если я его делаю прямо из письма оказывается в ней же и, соответственно, не читается.
(Ответить) (Parent) (Thread)
[User Picture]From: sova
2001-09-11 08:06 am
Одно конкретное предложение. Уже ясно, что есть 2 проблемы:

1) Тяжелая и концептуальная -- внутреннее представление текста в БД.

2) Более простая -- как его посылать пользователю.

В этой связи предлагаю: кому-нибудь умному создать N тестовых страниц с разными вариантами кодировок, их сочетаний, META-tags, styles, entities, и т.д., во всех вариантах, с образцами (GIFами) того, как это должно выглядеть. Выложить эту радость на ЖЖ, разлекламировать, и выяснить, что и в какой конфигурации (browser, encoding, OS, OS language, something else??) работает.

Возможно, что результаты этого опроса сразу отбросят довольно много вариантов решений.
(Ответить) (Thread)