avva | ЖЖ-логия: русификация ЖЖ

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

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

Сейчас идёт обсуждение того, как улучшить и приспособить ЖЖ для нужд юзеров, пишущих и читающих на самых разных языках, кроме английского. Общее отношение к этой задаче у разработчиков и админов ЖЖ (в частности, у главного 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 .