ЖЖ-логия: русификация ЖЖ
Sep. 11th, 2001 01:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaЭта запись обращена в первую очередь к программистам, а также специалистам по проблемам языков и кодировок на веб-страницах и в веб-проектах. Но и ко всем вообще, кто хочет высказать своё мнение.
Уважаемые программисты-специалисты!
Сейчас идёт обсуждение того, как улучшить и приспособить ЖЖ для нужд юзеров, пишущих и читающих на самых разных языках, кроме английского. Общее отношение к этой задаче у разработчиков и админов ЖЖ (в частности, у главного decision-maker'а![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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?
Какие вопросы надо решить:
Уважаемые программисты-специалисты!
Сейчас идёт обсуждение того, как улучшить и приспособить ЖЖ для нужд юзеров, пишущих и читающих на самых разных языках, кроме английского. Общее отношение к этой задаче у разработчиков и админов ЖЖ (в частности, у главного 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. Если у кого-то есть желание присоединиться к команде разработчиков ЖЖ, то они все тусуются в этих двух местах:![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif)
lj_dev и http://lists.livejournal.com .
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2001-09-11 06:08 am (UTC)Notification æå íóæíî ïîñûëàòü â çàêàçàííîé êîäèðîâêå - î÷åíü ÷àñòî KOI8 èëè win1251 - äàëåêî íå ëó÷øåå ðåøåíèå.
no subject
Date: 2001-09-11 06:18 am (UTC)no subject
Date: 2001-09-12 04:05 pm (UTC)Åñëè óæ ââîäèòü UTF-8 â áàçó äàííûõ, òî ïîíÿòíî, ÷òî ýòî äëÿ âñåõ. Ïðåäïîëîæèì, ñäåëàëè ýòî. È ÷òî òåïåðü âûäàâàòü þçåðó, ê-é íå õî÷åò âèäåòü Þíèêîä? Êàê è êóäà åìó ïåðåâîäèòü? Êèäàòü åìó íå charser=utf8, à HTML-entities? Èëè ïûòàòüñÿ ïåðåâîäèòü â êîäèðîâêó åãî âûáîðà, òåðÿÿ ïî ïóòè íå âïîëçàþùèå â íå¸ ñèìâîëû?
Ïîìîãèòå ìíå, ÿ íå ñîâñåì ïîíèìàþ, êàê ëó÷øå ýòî ñäåëàòü. Ñàìîå ãëàâíîå äëÿ ìåíÿ - èçáåæàòü nightmare scenario, ïðè êîòîðîì Áðàä ïî ìîåé ðåêîìåíäàöèè ïåðåâîäèò âñþ áàçó äàííûõ íà Þíèêîä, à ïîòîì îêàçûâàåòñÿ, ÷òî áîëüøîìó êîëè÷åñòâó þçåðîâ ýòî âñ¸ ëîìàåò. ß æ òîãäà çàñòðåëþñü îò ñòûäà ;)
no subject
Date: 2001-09-13 05:50 am (UTC)òî åñòü, ðåçþìèðóÿ - â íîðìàëüíûõ ðåàëèçàöèÿõ database character set îïðåäåëÿåò íå òî, â ÷åì áóäåò êîíòåíò _âûâîäèòüñÿ_, à òî, â ÷åì îí áóäåò _õðàíèòüñÿ_. èñïîëüçîâàíèå utf-8 â êà÷åñòâå DB character set íå âûíóæäàåò ê åãî èñïîëüçîâàíèþ â êà÷åñòâå êëèåíòñêîãî, à ïîçâîëÿåò åãî èñïîëüçîâàíèå â êà÷åñòâå êëèåíòñêîãî. âîò êàê-òî òàê.
ìàëî òîãî