Квадратики (точнее ромбики) вместо заглавных русских букв

Так кракозябры или квадратики? :) Если пустые квадратики - это означает, что в шрифте не нашлось подходящих символов для отображения этих букв. А в какой теме это вылезает - в стандартной или в какой-то собственной?

--
Axel

Квадратик в опере, знак вопроса в нестшкафе, квадратик+знак вопроса в ИЕ6. Это понятно, что не находится символа в шрифте, непонятно отчего не находится :)
И в стандартных темах, и в собственной. Термы таксономии отображаются таким образом.

Сам с такой штукой не сталкивался. Если шрифт не юникодный все будет квадратиками. Это в одной теме или во всех так вылазит?

--
Axel

Во всех, по крайней мере пробовал те, что стандартно идут с друпалом - chameleon, example, xtemplate, плюс в моей, основанной на xtemplate. Убирал css-сы, то же.

ЗЫ: В предыдущем моем посте заголовок у меня видится "Квадратик в опе�" - квадратик последним. И этот пост "Во всех, по край�" тоже последний символ темы - квадратик. Остальные нормально.

IE 5.5

Кроме того здесь правая колонка налезает и перекрывает сообщения :(

В конце заголовков не квадратики, а ромбики :) Да, у меня они также видны. Это побочные прелести работы в юникоде ;) В Drupal обрезаются заголовки комментариев, чтобы не были очень длинными и для нелатинских юникодных символов это делается не всегда корректно и поскольку в латинских кодировках проблемы нет фиксить ее похоже никто не собирается :) На drupal.org было обсуждение по этому поводу, но не помню уже даже по каким словам его разыскивать :\ (если найду - кину линк). Вот чтобы ромбики были вместо заглавных букв - не видел.

--
Axel

квадратики в заголовках получаются тогда, когда правишь php-текст и там же, в нём, что-то пишешь по-русски (заглавия и пр...), он их преобразует в юникод, а там и получаются квадратики...

Кто-нибудь знает, как использовать вместо модуля locale обычные текстовые файлы? Никто не пробовал? Их и править проще. Да и идиотство это (на мой взгляд) загонять перевод в базу. CSS в файлах, а перевод в базе (в форуме Invision Board например, наоборот), но я считаю, что и так и так одинаково глупо.

Можно использовть mo-файлы для gettext, это быстрее чем парсить тексты. Патчики под это разные есть, по аналогии можно конечно и текстовые файлы адаптировать (примерно как это сделано в *Nuke или Mambo), но зачем?

--
Axel

Чем вообще gettext отличается от locale? И зачем придумывать столько наворотов (вплоть до перекодировки в unicode), когда можно и кодировку и файлы использовать также, как css например?

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

текстовые файлы адаптировать (примерно как это сделано в *Nuke или Mambo), но зачем?
Затем, что в текстовых файлах я могу всё исправлять и редактировать очень просто. В сервере баз данных нет смысла хранить необновляемую информацию, не понимаю я, зачем в базу загонять такую статичную информацию, как языковые данные.

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

С последним утверждением согласен. Хранить все в БД - красивая идея, но не всегда удобная по производительности. Да, править переводы через вебинтерфейс тоже красиво, но во-первых неудобно, во-вторых рано или поздно будут готовые переводы, которые требуется просто установить (хотя подправлять самому часто тоже приходится).

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

> текстовые файлы адаптировать (примерно как это сделано в *Nuke или Mambo)

Действительно зачем? PO-файлы они разве не текстовые? Плюс к ним есть удобные инструменты для ведения переводов и куча утилит для корректного объединения и других манипуляций с PO-форматом. Зачем изобретать велосипед когда есть стандартный и многоплатформенный gettext, работающий при этом одинаково в куче разных языков программирования?

--
Axel

1. Хорошо, gettext - так gettext, хотя он и не везде работает (по вашим утверждениям).
2. Но с unicode я не согласен. Это нравится вам, а мне не нравится. И получается ничего изменить я не могу. Где же эта свобода? Что, так сложно сделать, чтобы всё хранилось в других кодировках? Несложно, но по каким-то религиозным причинам этого делать не хотят.

Да, я могу исправить это, если я программист. А если нет? "Делайте как мы", потому что так правильно? Хм... смешно, но приводить в качестве "правильности" жёстко ограниченную кодировку в свободном продукте - это как раз неправильно. На мой взгляд...

Но везде его можно включить, если потребуется. Главное, что поддержка gettext в PHP имеется.

Хорошо, посмотрите тогда на другие CMS. Как правило большинство авторов там - англоязычные товарисчи, которым проблемы нелатинских кодировок в общем-то до фени (в Drupal я думаю расклад такой же, откуда вылезают все эти глючки). Отсюда вообще интересные проблемы возникают, когда приходится выковыривать со страничек забитые туда ISO8859-1 и менять их на KOI8 или разбирать почему почтовые сообщения приходят в us-ascii? Кстати и Mambo и разные Nuke эти проблемы в свое время не обошли. Ромбики в сообщениях по сравнению с этим - цветочки :) Впрочем, учитывая, что unicode в рунете по-прежнему остается делом будущего - проблемы вылезают и в других местах, например в сборе новостей Drupal считает что все ему подают в UTF-8, когда большинство русскоязычных сайтов предлагают RSS-новости в KOI8 или вообще в cp1251.

Адаптировать к национальной кодировке (тут опять придется определяться - KOI8 выбрать или cp1251?) можно. Теоретически, надо прописать ее в темах, чтобы она отдавалась на страничках и русские переводы соответственно конвертировать. По идее должно работать, впрочем проверить надо бы? Пока не вижу смысла в это лезть, но как-нибудь на досуге можно попробовать. Это не "религиозные" причины, просто меня лично работа в UTF-8 устравивает. Если кому интересны альтернативы - присылайте сюда (врядли это будет интересно на drupal.org) свои наработки.

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

И может быть это покажется снобизмом, :) но кто же еще в вопросах реализации программ должен говорить "делайте как мы", как не технические специалисты в этой области - программеры? :)

--
Axel

И может быть это покажется снобизмом, но кто же еще в вопросах реализации программ должен говорить "делайте как мы", как не технические специалисты в этой области - программеры?
Я не считаю, что технические специалисты вправе указывать мне "как правильно". Существуют другие, более универсальные способы узнать, что правильно, а что нет, например логика. Большинство технических специалистов, к сожалению, страдают её отсутствием (прочитайте, например, моё мнение на эту тему) и это проявляется в том или ином виде...

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

Я не хочу кого-то обидеть или ещё что-то в таком роде (я просто констатирую факты), разработчики проделали огромную работу и сделали отличную cms, но ещё есть проблемы и я не стал бы никому доказывать, что юникод для всех хорошо, просто потому что это юникод... Для одних хорошо, а мне он не нравится... И почему жёсткая установка на юникод предлагается как достоинство, лично я не понимаю. Это как раз проблема, а не достоинство, а проблему надо решать.

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

Стандартом является charset в meta, вот пусть он и будет... А увеличивая и ограничивая свободу пользователя ничего не добьёшься, по-моему примеров этому достаточно.

Вот как сделать, чтобы сайт работал в KOI8-R.

http://drupal.ru/book/view/80

--
Axel

Интересно, почему этот сайт у меня показывается нормально. А сайт постоянно показыввет крякозябры? Или это из-за того, что мой из cvs?

Интересно, почему этот сайт у меня показывается нормально, а мой сайт постоянно показыввет крякозябры? Или это из-за того, что мой из cvs?
О, вот нашёл ошибку. Или это не ошибка? Но я всё-таки думаю, что это какой-то баг. Если можете прореагируйте. Если нажать на edit, но вместе с содержанием изменить название темы, то добавится не как испрвленное, а как новое...

Если это "фича", то странная. Я попробую воспроизвести у себя, напишу тогда багрепорт на drupal.org. Спасибо.

Насчет кракозябр - если ты про эти загадочные квадратики вместо заглавных букв, то не знаю :( Этот сайт работает на Linux, другие установки Drupal я делал еще на FreeBSD, с особенностями работы в Windows и IIS помочь не могу. Попробуй искать на drupal.org, там разные варианты конфигураций у народа попадаются.

--
Axel

По первому вопросу - хорошо бы...
По второму - я имею ввиду, что на моём сайте постоянно я вижу кракозябры от utf-8, то есть, у вас же тоже кодировка utf-8? Так почему на моём сайте браузер не определяет автоматически кодировку, а на вашем определяет?

Какая операционка, вебсервер? Это ты про установку под Win + IIS?

--
Axel

Это уже не важно, просто странно. К вам заходил - нормально определялся
utf-8, а у себя постоянно видел крякозябры. Я потому и спрашивал про другие кодировки, что мне это не нравилось. А наверное в настройках сервера была принудительно установлена кодировка 1251... я думаю так...

Сервер у меня Apache, операционка - Linux... Кстати, та команда, для замещения всех кодировок на cp1251 - хорошо всё сделала. Во всяком случае, многих глюков utf-8 я теперь лишён, да хотя бы того, что названии тем не появляются скобки, div и прочие некрасивые вещи... С этим у меня теперь нормально...

Да и по мелочам лучше стало. Меньше проблем с тегами div table... Ну и конечно, текст стал ровно в два раза компактнее. Ведь к числу недостатков utf-8 можно отнести её размер...

Сам в итоге напоролся на эти загадочные "ромбики" :) Полез смотреть и вышел на эту багу - применение функции ucfirst() в CVS после 4.3. Это попало и в 4.4. Функция не особо как понимает юникод (от PHP ничего хорошего я и не ждал, когда с ним связывался, но замуты реализации откровенно разочаровывают), можно однако явно указать локаль, тогда работает. Т.е. для русского контента либо скрипт должен быть запущен под русской локалью, чего на хостингах я вообще не встречал - обычно юзеру выставлена C, без всяких там излишеств. Либо локаль надо выставлять в самом скрипте, например так:

setlocale(LC_ALL, "ru_RU.utf8")

Если после вызывать ucfirst(), отрабатывает она корректно.

Альтернативный путь, который я использовал - выкидывать эти ucfirst нафиг, тем более в коде они imho большей частью не по делу. Зачем делать capitalize заголовков например, может я этого не хочу?

По ucfirst баг легко нашелся в рассылке drupal-devel и багтреке, вот что думают зарубежные товарисчи по этому вопросу (как я понял, в CVS эта бага поправлена):

http://drupal.org/node/view/5112

http://lists.drupal.org/archives/drupal-devel/2003-12/msg00787.html

--
Axel

Прочел всю тему, да так и не нашел ответа. Правда заметил такую вещь. Уже в 4.6.3 когда сменил тему xtemplate на phptemplate. Тоже было несколько кубиков. Но у меня все легко решилось. Зашел в страницы снова ввел букву и вроде все.

скорее всего стиль шрифта не тот.