Готовая локализация без базы( бета версия)

Главные вкладки

Аватар пользователя jason32 jason32 11 сентября 2006 в 13:45

Итак, сделал я локализацию без базы. Сделано немного - запросы к базе ещё остались, но их стало порядка 10-20 против 200-400 ранее. Пока изменена лишь одна функция + сделан конвертер из базы. У меня всё прекрасно сработало.
Итак - файл [b]common.inc[/b]

Было :

<?php

function t($string, $args = 0) {
global $locale;

if (function_exists('locale') && $locale != 'en') {
$string = locale($string);
}

if (!$args) {
return $string;
}
else {
return strtr($string, $args);
}
}
?>

Стало :

<?php

function t($string, $args = 0) {
global $locale;
global $lang;
if (isset($lang[$string])) $string=stripslashes($lang[$string]);
elseif (isset($lang[addslashes($string)])) $string=stripslashes($lang[addslashes($string)]);
else
if (function_exists('locale') && $locale != 'en') {
$string = locale($string);
}
if (!$args) {
return $string;
}
else {
return strtr($string, $args);
}
}
?>

+ [b]converter.php[/b]
<?php
<?php
// converter.php
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
//////////названия таблиц////////////////////////////

$table_meta='locales_meta';
$table_sources='locales_source';
$table_target='locales_target';

////////////////////////////////////
$lang=array();
$lang_en=array();
$sql="Select * from $table_meta where `isdefault`=1";
$res=mysql_query($sql) or die(mysql_error());
if ($row=mysql_fetch_array($res))
{
$is_default=$row['locale'];
}
else die('Нет значения по умолчанию');
$sql="Select `lid`,`source` from $table_sources ";
$res=mysql_query($sql) or die(mysql_error());
while ($row=mysql_fetch_array($res))
{
$lang_en[$row['lid']]=$row['source'];
}

$sql="Select `lid`,`translation`,`locale` from $table_target where `locale`=\"$is_default\"";
$res=mysql_query($sql) or die(' '.mysql_error());
while ($row=mysql_fetch_array($res))
{
$id=addslashes($lang_en[$row['lid']]);
if (!empty($row['translation']))
{
$locale_id=addslashes($row['translation']);
$lang[$id]=$locale_id;
}
else $lang[$id]=$id;
}
$locale_file="<?
";
foreach ($lang as $sources=> $target)
{
$locale_file.='$lang[\''.$sources.'\']=\''.$target."';
";
}
$locale_file.='?>';
if (!is_dir('locale')) mkdir('locale',0755);
$fp=fopen('locale/russian.php','w');
fwrite($fp,$locale_file);
fclose($fp);
?>
[b]Необходимые условия[/b]: нужно закинуть файл conveter.php в корень. Если папка locale с файлом russian.php не появилась - значит необходимо вручную её создать.
В index.php первым оператором прописать  include('locale/russian.php');
и всё должно заработать.
После этого запускаем converter.php и тестим Smile
После инсталяции очередного перевода модуля нужно будет только запустить Конвертер и всё.

Комментарии

Аватар пользователя B.X B.X 11 сентября 2006 в 20:26

а в файле russian.php что будет? какие ему CHMOD выставлять? Это я так понимаю, надо:
1. включить модуль locale (если он выключен).
2. добавить через него файлы перевода.
3. запустить converter.php
4. выключить модуль locale (или не нужно его выключать)?
5. после каждого загруженного (через locale) перевода для модуля включать converter.php

Аватар пользователя jason32 jason32 12 сентября 2006 в 8:38

Quote:
а в файле russian.php что будет? какие ему CHMOD выставлять?

Ну 777, думаю, ничего плохого не сделает.
Quote:

1. включить модуль locale (если он выключен).
2. добавить через него файлы перевода.
3. запустить converter.php
4. выключить модуль locale (или не нужно его выключать)?

Первые три - ДА , 4 пункт -НЕТ, просто при отсутствии перевода в russian.php Друпал будет лезть в базу - у меня ещё не всё почищено - запросов 10-20 к базе периодически случаются, но очень редко. В общем, на любителя.

Аватар пользователя B.X B.X 12 сентября 2006 в 19:11

да, было бы хорошо, кстати, если бы там был не один файл russian.php, а чтобы это было по модулям разбито (тогда меньше, по идее, времени будет тратиться на чтение этого файла)... ведь если модулей много, то этот файл разрастётся донельзя...
да, было бы хорошо, если бы модуль locale можно было бы отключить совсем... а что никак этого не добиться?
да, и хорошо бы этот скрипт в виде модуля, конечно, было бы сделать...

Аватар пользователя axel axel 13 сентября 2006 в 0:01

Чего-то как-то сложно. А просто замены locale в t() на свою функцию не достаточно оказалось? К drupal 4.3-4.5 я делал такую подмену для работы с gettext. Кстати, gettext имхо предпочтительнее, поскольку может обеспечить большую скорость работы, чем просто текстовый файл с переводами (если к po-файлам добавить mo-индексы).

--
Axel,
Darcs-репозиторий разработок для Drupal

Аватар пользователя rgb rgb 13 сентября 2006 в 8:40

О! Axel появился Smile

В форуме как раз про gettext.module было упоминание недавно и призыв к Вам поделиться мнением по данному вопросу.

Насколько целесообразным оказалось использование такого модуля? Отчего он не получил развития? Какие-то причины технического плана повлияли на это?

Аватар пользователя axel axel 14 сентября 2006 в 22:08

Это уже объясняли в девелоперской рассылке - выигрыш от gettext не всегда заметен и вообще не всегда имеет место. Особенно в конфигурации, когда всё на одном хосте. И когда mysql имеет достаточно памяти в своём распоряжении (чтобы не создавать временных таблиц на диске при сложных запросах и т.д.). Считать эффективность по числу запросов к базе - это ошибочный подход. Поиск в проиндексированной базе в большом объеме данных порой эффективнее чем перелопачивание текстовых файлов. Собственно всё равно ведь всё из файлов читается, СУБД лишь обеспечивает интерфейс для поиска и чтения. И в ряде случаев этот интерфейс эффективней, чем работа с непосредственно файлами хранящимися на диске. Также, сотня мелких запросов выполненных в рамках одного соединения может порой быть эффективней одного сложного запроса с кучей соединений к разным таблицам.

Есть случаи, когда gettext сильно спасает - у меня это было на хостинге Infobox и Drupal 4.3, был там период когда БД работала не особо быстро. Но это было давно - и друпал с тех по развился, и хостер не раз апгрейднулся. Сейчас для меня лично проблема неактуальна, поэтому я забросил дописывание модуля. Хотя если такая штука как полноценное использование gettext будет в ядре друпала - это будет плюсом движку. Всё равно для импорта/экспорта этот формат уже используется.

Вот хранить переводы в инклюдах или текстовых файлах - с одной стороны проще, с другой стороны нестандартно и полагаю есть изобретение велосипеда. Каких-то выигрышей в сравнении с gettext я тут не вижу. Библиотека gettext распространена в самом разном софте, для работы с po-файлами есть куча утилит, друпал этот формат понимает - надо только адаптировать его к его непосредственному использованию.

--
Axel,
Darcs-репозиторий разработок для Drupal

Аватар пользователя smile smile 14 сентября 2006 в 11:04

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

Аватар пользователя kiev1 kiev1 16 сентября 2006 в 0:38

а в друпале вообще с "генерацией страницы ноды" мистика - там таакие огромадные запросы с проверками кеша выходят - что mysql им давится. Поэтому если сравнивать то не с одной нодой а с обычным каким-нибудь mysql запросом.

Аватар пользователя B.X B.X 13 сентября 2006 в 1:54

так Аксель, а твой модуль работает? было бы неплохо чтобы он был рабочим для 4.7, кстати на друпал.ру этот модуль работает locale_gettext? или стандартный стоит?

Аватар пользователя axel axel 15 сентября 2006 в 15:03

На drupal.ru работает стандартный locale. Меня его взаимодействие с БД пока что устраивает.

--
Axel,
Darcs-репозиторий разработок для Drupal

Аватар пользователя rgb rgb 13 сентября 2006 в 21:43

Quote:
Я правда в базах данных полный ноль, чтобы понимать.

Идея там простая - добавить к одной из таблиц, индекс, что бы выборка данных (для ф-ционирования модуля локализации) проходила быстрее.

Аватар пользователя B.X B.X 13 сентября 2006 в 17:01

всё это костыли... ничего не решится, пока будет этот механизм хранения ненужных данных (не динамических) в БД.

Аватар пользователя smile smile 14 сентября 2006 в 10:58

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

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

Аватар пользователя rgb rgb 14 сентября 2006 в 12:04

Quote:
померяйте время генерации страницы ноды например. при первом и втором способе (с базой и без базы). вполне обьективная статистика получается я вам скажу.

Угу. Только надо мерять с помошью (как минимум) ab и учитывать ОС и файловую систему, на которой проводятся тесты. Кроме того, не плохо было бы указать и текущие настройки MySQL, Apache и PHP (опять же - как минимум) ну и железо и память... И замерить расход памяти, загруженность процессора и дисковой подсистемы.

Что-то ещё забыл, что должно влиять на производительность?

Аватар пользователя smile smile 14 сентября 2006 в 12:21

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

кстати я чет не уловил - друпал только на vps и дедиках живет?

Аватар пользователя Гость Гость (не проверено) 14 сентября 2006 в 14:12

а у меня не работает, пишет что синтаксическая ошибка:
Parse error: syntax error, unexpected T_VARIABLE in ...\includes\common.inc on line 602

Аватар пользователя jason32 jason32 14 сентября 2006 в 15:35

Quote:
а у меня не работает, пишет что синтаксическая ошибка:
Parse error: syntax error, unexpected T_VARIABLE in …\includes\common.inc on line 602

Должно работать - приведи кусок кода с 601 по 603 строчку - может ты где ошибся?

Аватар пользователя Гость Гость (не проверено) 15 сентября 2006 в 2:27

а там и есть твой код с 599 по 615(старый + твои теги)

599 function t($string, $args = 0) {
600 global $locale;
601 global $lang;
602 if (isset($lang[$string]) $string=$lang[$string];
603 else
...
... if (function_exists('locale') && $locale != 'en') {
... $string = locale($string);
... }
... if (!$args) {
return $string;
}
else {
return strtr($string, $args);
}
}

ошибку не смог поправить для меня пока загадка (наверное как обычно - всё перед носом)

Аватар пользователя rgb rgb 15 сентября 2006 в 10:18

Ну если тут написано как у Вас в файле, то на 602 строке не хватает закрывающей скобки.

<?php
..
global $lang;
if (isset($lang[$string])) $string=$lang[$string];
//                       ^
else
...
?>

UPD: пока писал, автор и сам поравился Smile

Аватар пользователя jason32 jason32 14 сентября 2006 в 15:37

Quote:
Угу. Только надо мерять с помошью (как минимум) ab и учитывать ОС и файловую систему, на которой проводятся тесты. Кроме того, не плохо было бы указать и текущие настройки MySQL, Apache и PHP (опять же - как минимум) ну и железо и память… И замерить расход памяти, загруженность процессора и дисковой подсистемы.

Что-то ещё забыл, что должно влиять на производительность?

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

Аватар пользователя rgb rgb 15 сентября 2006 в 10:12

Quote:
Это мне как-то напоминает стоны спортивных комментаторов про плохое поле, дождь и тд, на что находится резонный ответ - “обе команды в равных условиях”.

Тут не спорю Smile Вопрос только в том, что в нашем случае у каждого из нас свои условия, специфика и требования. Посему говорить, что персональный сайт Василия Петрова и сайте он-лайн продавца Петра Васильева находятся в одинаковых условиях - не корректно.

Этим свом высказыванием я хотел сказать банальнейшую вещь: тесты - это весьма условный показатель и они валидны только для конкретного сайта в конкретных условиях.

Quote:
Я уже говорил - если копать глубоко, то и в базе дойдем до их физического представления.

Не - туда нам пока не надо - туда мы не пойдём пока Smile

Аватар пользователя B.X B.X 14 сентября 2006 в 18:32

[b]jason32[/b], а что насчёт вопроса Акселя?
насчёт gettext вы не смотрели? был патч хороший gettext_locale... работал он вообще без БД и без модуля locale, нужны были только .po файлы...
[i]вот этот патч для версии 4.4, 4.5:[/i]

<?php
diff -c /home/axel/src/drupal-4.3.2/includes/common.inc includes/common.inc
*** /home/axel/src/drupal-4.3.2/includes/common.inc 2003-10-23 00:20:34.000000000 +0400
--- includes/common.inc 2004-02-24 00:53:58.000000000 +0300
***************
*** 1,5 ****
--- 1,6 ----
<?php
// $Id: common.inc,v 1.260 2003/10/22 20:20:34 dries Exp $
+ // applied drupal.ru locale patch v0.3

function conf_init() {

***************
*** 164,194 ****
}

function locale_init() {
! global $languages, $user;
! if ($user->uid && $languages[$user->language]) {
! return $user->language;
! }
! else {
! return key($languages);
}
}

function t($string, $args = 0) {
! global $languages;
!
! /*
! ** About the usage of t(). We try to keep strings whole as much as
! ** possible and are unafraid of HTML markup within translation strings
! ** if necessary. The suggested syntax for a link embedded within a
! ** translation string is for example:
! **
! ** $msg = t("You must login below or create a new
! ** account
before viewing the next page.", array("%url"
! ** => url("user/register")));
! */
!
! $string = ($languages && module_exist("locale") ? locale($string) : $string);

if (!$args) {
return $string;
}
--- 165,200 ----
}

function locale_init() {
! // drupal.ru locale patch v0.3 BEGIN
! global $drupal_locales;
! $lang = "en"; // default language
! $lang_keys = array_keys($drupal_locales);
! $accepted_langs = explode(",", $_SERVER["HTTP_ACCEPT_LANGUAGE"]);
! foreach ($accepted_langs as $lang_item) {
! $alang = explode(";", $lang_item);
! if (in_array($alang[0], $lang_keys)) {
! $lang = $alang[0];
! break;
! }
}
+ $GLOBALS["user_locale"]= $drupal_locales[$lang];
+ return $lang;
+ // drupal.ru locale patch END
}

function t($string, $args = 0) {
! // drupal.ru locale patch v0.3 BEGIN
! global $user_locale;
! setlocale(LC_ALL, $user_locale);
! putenv("LANG=$user_locale");
! $bd = bindtextdomain("default", "./locale");
! $td = textdomain("default");

+ if($string) {
+ $string = gettext($string);
+ }
+ // drupal.ru locale patch END
+
if (!$args) {
return $string;
}
diff -c /home/axel/src/drupal-4.3.2/includes/conf.php includes/conf.php
*** /home/axel/src/drupal-4.3.2/includes/conf.php 2003-07-10 21:46:41.000000000 +0400
--- includes/conf.php 2004-02-16 13:08:38.000000000 +0300
***************
*** 44,49 ****
--- 44,53 ----
#
# Languages / translation / internationalization:
#
+ # drupal.ru locale patch v0.2 BEGIN
+ $drupal_locales = array("ru" => "ru_RU.utf8", "en" => "C");
+ # drupal.ru locale patch END
+ #
# The first language listed in this associative array will
# automatically become the default language. You can add a language
# but make sure your SQL table, called locales is updated
?>

Аватар пользователя dyp@drupal.org dyp@drupal.org 14 сентября 2006 в 22:40

Quote:
Это уже объясняли в девелоперской рассылке - выигрыш от gettext не всегда заметен и вообще не всегда имеет место.

У друпала есть проблема с обращениями к базе. У хостеров обычно стоит ограничение на их колличество, а выделенный сервак (даже VPS) могут позволить сеье не все. ИМХО даже если выйгрыш от gettext будет не большим или его не будет по крайней мере сократиться кол-во коннектов.

Аватар пользователя B.X B.X 15 сентября 2006 в 1:41

[b]"Библиотека gettext распространена в самом разном софте, для работы с po-файлами есть куча утилит, друпал этот формат понимает - надо только адаптировать его к его непосредственному использованию."[/b]
да и ещё есть одно "но"... не на всех хостингах php установлен с getext'ом...
и также соглашусь с предыдущим комментарием, что если запросов к базе и так много и их количество ещё и ограничего, а система кэширования часто просто [url=http://www.drupal.ru/node/1564]не работает[/url] или работает не так как нужно, то надо что-то делать...

Аватар пользователя axel axel 15 сентября 2006 в 15:05

Если у хостера неудачно настроена СУБД и PHP предлагается без gettext (часто и без mbstring) - это повод сменить хостера. Благо выбирать есть из чего.

--
Axel,
Darcs-репозиторий разработок для Drupal

Аватар пользователя rariteth rariteth 15 сентября 2006 в 2:39

а поподробней можно, что-то я не понимаю, вроде всё прально, а может этот russian.php надо сделать самому? тогда в каком формате.... я с друпала не слезу очень понравилась, около 50 КМС-ок перепробывал - эта пока лидирует, назревает проэкт и хотелось бы хостера не подвести

Аватар пользователя rariteth rariteth 15 сентября 2006 в 2:47

это понятно. вобщем помогите плзз вот всё что в первом посту я сделал, но не работает... ошибки анонимом(мною) на 601 строке появляются, пока каментю... так как это работает?

Аватар пользователя Shedko Shedko 15 сентября 2006 в 3:10

Когда проверял этот модуль у себя (на локальном Денвере Smile ), то заметил такую зависимость, если заменить сразу функцию t() на новую, то converter.php не работает :-), как только возвращаю предыдущую функцию (та которая в оригинальном ядре), то converter.php создает этот russian.php, но только потом этот метод перевода все равно не захотел работать ?

Есть идеи ?


После создания russian.php опять возвращал функцию t() в предложенный вариант.

Аватар пользователя jason32 jason32 15 сентября 2006 в 10:11

Сорри, перед всеми извиняюсь, выложил с маленькой ошибочкой в 602 строчке

if (isset($lang[$string])[b][color=red])[/color][/b]$string=$lang[$string];

- скобочку забыл.У себу то сразу пофиксил, а тут...

Аватар пользователя jason32 jason32 15 сентября 2006 в 10:13

Quote:
Вопрос только в том, что в нашем случае у каждого из нас свои условия, специфика и требования. Посему говорить, что персональный сайт Василия Петрова и сайте он-лайн продавца Петра Васильева находятся в одинаковых условиях - не корректно.

Я про измерения производительности на одном хосте говорю - например, на вашем попрбуйте и померьте, изменилось ли время генерации страницы - я не предлагаю сравнивать свой collocation и ваш бесплатный хостинг

Аватар пользователя rgb rgb 15 сентября 2006 в 10:31

Quote:
Я про измерения производительности на одном хосте говорю

То понятно...

Я другое имел ввиду: даже если на "моём бесплатном" время изменится, не факт, что на "вашем collocation-е" это произойдёт.

В любом случае, думаю что не стоит обсуждение _этого_ вопроса развивать далее. Wink

Аватар пользователя jason32 jason32 15 сентября 2006 в 10:16

Quote:
Когда проверял этот модуль у себя (на локальном Денвере ), то заметил такую зависимость, если заменить сразу функцию t() на новую, то converter.php не работает , как только возвращаю предыдущую функцию (та которая в оригинальном ядре), то converter.php создает этот russian.php, но только потом этот метод перевода все равно не захотел работать ?

Это вы извините где то ошибаетесь. [b]Converter.php [/b] вообще не использует стандартных функций( ну или почти) - он просто лезет в базу и берет оттуда данные.Функция t() нигде не вызывается.

Аватар пользователя jason32 jason32 15 сентября 2006 в 10:27

to[b] Axel[/b]

Quote:
Чего-то как-то сложно. А просто замены locale в t() на свою функцию не достаточно оказалось? К drupal 4.3-4.5 я делал такую подмену для работы с gettext. Кстати, gettext имхо предпочтительнее, поскольку может обеспечить большую скорость работы, чем просто текстовый файл с переводами (если к po-файлам добавить mo-индексы).

Не думаю, что gettext предпочтительнее. Само упоминание индексов уже говорит о том, что идут запросы к po-файлам , что не может быть быстрее простого единовременного include(). Да, вот если бы я, каждый раз когда нужен перевод , открывал russian.php через fopen ? там бы искал нужный текст и тд и тп - тогда да, не спорю, gettext бы рулил. Но у меня проще , хотя и менее универсально. Для модуля не пойдет, но как работоспособный и простой хак - вполне.

Аватар пользователя axel axel 15 сентября 2006 в 15:14

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

--
Axel,
Darcs-репозиторий разработок для Drupal

Аватар пользователя jason32 jason32 15 сентября 2006 в 14:06

Обновил функцию t()

Quote:
if (isset($lang[$string])) $string=stripslashes($lang[$string]);
elseif (isset($lang[addslashes($string)])) $string=stripslashes($lang[addslashes($string)]);

- без неё глючило в строках с кавычками

Аватар пользователя B.X B.X 15 сентября 2006 в 15:55

[b]"На drupal.ru работает стандартный locale. Меня его взаимодействие с БД пока что устраивает."[/b]
понятно, но у тебя отдельный сервер, хотя и с несколькими проектами... так вроде?
[b]"Если у хостера неудачно настроена СУБД и PHP предлагается без gettext (часто и без mbstring) - это повод сменить хостера."[/b]
я просто про то, что gettext не так важен, чтобы из-за него меня хостера, а вот текстовые файлы вообще универсальны и не требуют ничего...
[b]"Согласен, как простой хак для отдельно взятого языка (особенно если выкинуть ещё из переводов хелпы и все длинные строки) - будет быстро работать и вполне эффективно по ресурсам."[/b]
кстати, насколько я понял, это изменение всё равно позволяет модулю locale обращаться к базе данных, он просто минимизирует это обращение, так что не всё так плохо...

Аватар пользователя rariteth rariteth 16 сентября 2006 в 14:23

как сделать на основе этого модуль?
я что-то пока вообще не очень понимаю как тут модели делать, понимаю что легко - делают кому не лень, а есть так сказать бланк для модуля, или где можно почитать про это?

Аватар пользователя jason32 jason32 25 сентября 2006 в 19:37

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

Аватар пользователя kiev1 kiev1 6 января 2007 в 4:38

у меня на каждую страничку по сотне запросов из таблицы cache даже если отключить кеш в настройках сайта
что делать?

Аватар пользователя B.X B.X 6 января 2007 в 10:28

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

Аватар пользователя kiev1 kiev1 6 января 2007 в 10:46

да у меня свой сервер и есть, но просто неприлично когда все так плохо в друпал.
а что нельзя просто отключить вообще обращения к таблице cache? ведь на сотню запросов убавится на страницу

Аватар пользователя B.X B.X 6 января 2007 в 13:31

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

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

Аватар пользователя Easter Easter 23 января 2007 в 11:15

Набрел на эту тему. И есть вопрос. Если я использую Друпал версии 4.7.5, то актуальна ли для него замена locale и иже с ними на то, что описано здесь? И еще вопрос, где можно почитать внятные туториалы как писать модули?