Ага, добрался я до этой странички! Кстати нашёл её что характерно с английского сайта.
url alias - синоним - не согласен! Блин даже в голову ничего не приходит путного, но смотрю на английский вариант, смотрю на русский и понимаю, что должно быть как-то по-другому. Дословно alias - это псевдоним, как вы знаете, но с этим вариантом тоже читается не гладко
assigned (node) - связанный (материал) - интересно, а почему в английском варианте не использовали linked в таком случае или referenced? Assign - переводили всегда как назначить. В чём тонкая разница между assigned и linked в данном случае? Осталось ощущение, что чего-то недопоняли при переводе.
(to) attach - прикрепить сами же писали выше, что присоединить
(blog) entry, (blog) post - запись в блоге - entry бывает переводят не только как запись, но и как точку входа. Я не разбираюсь в том как сделаны блоги в Drupal, но вы уверены, что в данном случае стоит переводить entry как "запись"?
blogapi - API для блогов - не согласен! Блоггеры - это те кто пишут сообщения в блоги, а не сами блоги. Для обычных блоггеров API не нужен. Поэтому "блог-API" передавало бы смысл лучше. Или "API блогов".
body - текст (в смысле "текст сообщения", например) Ни в коем случае! Только ТЕЛО сообщения. Текст сообщения состоит из заголовков (headers) и собственно body (тела). Это если не считать ещё subject и signature.
breadcrumbs - навигационная линейка (это т.н. "хлебные крошки"). Предлагаю ещё более понятный вариант: "Навигационная цепочка". Потому как на линейку по внешнему виду это смахивает мало
(to) cache - кешировать всё-таки "кэшировать". Термин практически уже всосался в русский язык, так давайте писать правильно.
checkbox - выбор опций - предложил бы вообще не переводить. Или в зависимости от контекста переводить понятными и простыми русскими словами, типа: "отметьте галочками нужные пункты".
configuration - настройка. Долгое время я был сторонником именно этого варианта. Но вот только как быть с config file? "Файл настроек"? Хорошо: "config variable"? "Настроечная переменная"? Уже хуже! Так что я постепенно всё-таки склоняюсь к слову "конфигурация". Благо оно тоже уже ни у кого ступора не вызывает и стало практически русским
content - содержимое, материалы - материалы нужно убрать.
help - справка - помощь! Понимаю, что звучит не очень, но и в английском это всё-таки помощь! Хотя в данном случае не так принципиально.
item - пункт или элемент
label - название Бывает, что удачней переводится как метка, но это от контекста зависит
legacy - совместимость Ни в коем случае! Наследие или Наследство. Совместимость - это conformance
links - ссылки в зависимости от контекста может переводиться и как связи
locale - язык - да Боже упаси! Локаль включает в себя не только такие понятия как язык, но и формат и тип валюты, формат даты/времени, способы сортировки (порядок букв алфавита) и т.д. Так что "локаль" или уж как это названо в Виндах "Региональные установки"
login - имя (как значение поля "your login") Тогда уж давайте уточнять "имя для входа"
logs - системные журналы просто журналы. Системные - это будет "system logs"
moderated - проверяется, модерируется Обычно пишется "moderated forum" - модерируемый форум. Так что слово "проверяется" я бы убрал.

Пока всё. Убегаю на работу. Потом продолжу.
Вопрос к хозяину странички - а покрасивей это оформить всё нельзя? Ведь не так трудно, да?

Спасибо за комментарии. А то я уж думал, что никто эту страницу не читает.
Не за что. Я новичок в Drupal, но что сразу бросается в глаза это отстуствие и невероятная запутанность русских док/переводов. Знаю, что если мне хочется положительных сдвигов, то надо заняться самому. Вот начал заниматься. У вас насколько я знаю самый полный перевод Drupal 5.x из всего того, что я нашёл. Поэтому я предлагаю свою помощь в его добивании, обсуждении словаря терминов и приведении этого всего к общему знаменателю.

Про данные переводы. Да, конечно, многое в них остается спорным. Я не претендую на окончательность этих вариантов. Это всего лишь рекомендации (хотя вот Axel, к примеру, высказывался за жесткую однозначность подобного словарика). Более того, даже в моих переводах Drupal5.1 и модулей многое переведено не дословно и не строго "по словарю", а исходя из контекста или языковой практики.
Главное делать, а далее регулярно поддерживать. Я согласен с Axel в плане однозначности - надо приводить всё к единому варианту, иначе пониманию в работе это не будет способствовать. Да перевод - это весьма непросто (сам ими занимался и знаю каково это), но дорогу осилит только идущий!

или тот же "язык" вместо "региональных настроек"
Я подсмотрел в Bitrix такой термин как "Локализация". Может его тогда лучше использовать? Да Drupal ПОКА не содержит других языковых настроек, но это ПОКА! Ведь и английский вариант почему-то говорит о locale, а не о languages

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

Нет. Помоему так делать нельзя. Объясню почему. Мы имем дело с продуктом! Наша задача не стоит в объяснении каждому на понятном ему уровне. Наша задача стоит в создании логичной, понятной и непротиворечивой документации для тех, кто хочет в этом разобраться! Есть некий набор терминов, которые просто нужно выучить, а наша задача сделать глоссарий и там уже понятно их объяснить, но использовать бы будем всё-таки термины, а не их объяснение. Иначе мы потом сами запутаемся во всём.

- body - текст. Вот хороший пример разницы между общеупотребительным и техническим. Говорите ли ли вы в обыденной жизни "дорогая, я только что прочитал тело статьи..."?
Нет. Но я могу сказать - исправь тело сообщения, имея в виду, что не надо править тему, заголовок и список адресатов! Вы правы, в каком-то контексте "текст" будет более адекватным переводом, но опять же сошлюсь на первоисточник, почему ТАМ говорят именно body, а не message или post?

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

Далее:
оptional - дополнительно - необязательный, потому как иначе было бы additional
path - псевдоним - путь. это классическое определение. Я мельком видел, что английский термин используется для чего-то похожего на псевдоним, но всё-таки вроде бы в Drupal, path используется как просто "чистый путь" бещ "?q=" не так ли?

(to) promote - разместить на главной - возможно удачней было бы "анонсировать?"
referrer - источник отсылки - ссылающийся
sticky - закреплено - приклеено, прилеплено
watchdog - регистратор - обычно это "сторож". Не знаю в каком смысле используется в Drupal
weblink - ссылка - тогда уж веб-ссылка
widgets – элементы - уточним "элементы GUI"

Axel, согласен! Нужен ЕДИНЫЙ словарь и ЕДИНАЯ позиция. Потому как загрузив один перевод я вижу "Мой журнал", а другой "Блог" Или "Тема в админке"

Но мне кажется, что рекламно-пиаровский аспект не столь важен здесь, сколько просто технический факт размещения на frontpage. Возможно, я ошибаюсь.
Я почему про анонс сказал, потому что я не до конца понял - в случае флажка мы размещаем на главной ЦЕЛИКОМ или только делаем сокращённый анонс о появлении материала? Если ЦЕЛИКОМ, тогда ваш вариант, действительно, более правильный.

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

watchdog - регистратор - обычно это "сторож". Не знаю в каком смысле используется в Drupal
Обсуждалось. В Drupal он, вроде бы, ничего не сторожит, а просто фиксирует факт изменений и регистрирует их в журнале (в логах)
Тогда согласен, ваш вариант удачней.

- sticky - закреплено - приклеено, прилеплено
Возможно, это "вкусовщина", но на мой слух "приклеено" - звучит слишком "вещественно" (прикреплено с помощью клея), а "прилеплено" - имеет оттенок разговорности, вульгаризации
Попробую объяснить в чём я вижу разницу. Закрепление - это как бы закрепление функции за кем-то за чем-то. Типа мы закрепили за Ивановым обязанность бегать за вином в магазин. А вот прилеплено или приклеено - это ассоциируется с листком, который приклеили к стеклу! Термин sticky как раз используется обычно именно в этом смысле.

И ещё. "node" переводить как материал, конечно, для понимания можно, но как тогда переводить вот такое:
Content in Drupal is created in individual "nodes". Содержимое в Drupal создаётся в отдельных материалах? Да, конечно, в данном случае можно извернуться и сказать, что "Содержимое в Drupal создаётся в виде типов материалов", но боюсь как бы потом такой перевод не вылез боком

В переводе документации - да, в переводе интерфейса - нет. Создавая сайт для строителей, я не собираюсь обучать их особенностям терминологии веб-разработчиков и программистов. Когда я еду в троллейбусе, мне вполне достаточно называть "рогами" штанги для подвода электричества
Вы правы! Когда вы ЕДЕТЕ, но не вы везёте. Если вы ИСПОЛЬЗУЕТЕ инструмент, то должны его знать. Это относится не только к Drupal, но и к Word, Excel и т.д. Неважно кто использует Excel строитель или кладовщик, но таблица она и есть таблица, а не сетка и не "та хреновина". Такой же подход должен быть и здесь по моему глубокому убеждению!

Кстати теперь я понял почему использован термин "node" и пожалуй появилось желание настаивать именно на переводе "node" как "узел". Дело в том, что "node" - это сущность, которая может включать в себя другие сущности, а вот такая сущность как "комментарий" не может включать в себя другие сущности и поэтому узлом не является. Но если использовать "материал", то это обезличено - и комментарий и node - всё материалы и ВАЖНАЯ часть их отличия просто ускользнёт от понимания новичка!

Тип узла - каталог
Также как есть такие типы узлов, как подшивка (book), заметка (story) и так далее.
И кстати даже упомнятый термин "Инфоблок" и то лучше чем "Материал". И кстати например в Bitrix используется именно такая формулировка - типы инфоблоков содержат инфоблоки, которые в свою очередь содержат конкретные элементы данного инфоблока. Это так, к слову.

Вот я и говорю - "вкусовщина": мне нравится так, а вам - нет. Или наоборот. Нам надо определиться с процедурой принятия того или иного варианта перевода. Как это делать? Голосованием? Будет "средняя температура по палате". Да и не факт, что тот вариант перевода, который понравится здесь на сайте, будет понятен "публике", посещающей наши сайты.
А мы разве пишем для публики, которая посещает сайты? Помоему мы пишем для публики, которая хочет разобраться! Наша задача помочь им в этом деле. Для этого можно использовать термин, который не просто выглядит понятно, а максимально отражает смысл. А расшифровать этот термин всегда можно в глоссарии.

Да, вы правы, я сам не знаю, что делать в случае когда у нас разное мнение! Если нас будет только двое, да пусть даже 4-ро, то это точно будет средняя температура по больнице. С другой стороны бесконечных прений, когда 20 человек начинают каждый про своё - мне бы тоже не хотелось. Тупик?

Добавьте себе в словарик:
summary - сводка. Это в смысле node summary

Dan, я перевожу там где 2-е не мешает 3-му. Насчёт сторожа я ведь согласился, когда мне объяснили, что оно делает

Dan, это намёк?
Кстати по поводу перевода. Посмотри на черновик:
http://wiki.drupal.ru/doc/terminology
и скажи есть ли там где-то такой дословный перевод, который бы искажал смысл?
Это перевод оригинального материала с drupal.org. Я понимаю, что не Тургенев, но на мой скромный взгляд во всяком случае читать это вполне можно и даже извлечь из этого что-то полезное.

А в форуме ты тоже будешь говорить, что это обсуждение - является документом?
Возможно ты не прочувствовал. Заостряю внимание.
Для узлов ТИПА "заметка".
Понимаешь, есть узел, но узел - это некая сущность-абстракция, которая всё что может - включать в себя другие узлы - это свойство любого ТИПА узла.
А есть ТИПЫ узла. Эти типы могут быть разными "подшивка", "заметка", "документ", "каталог", "новости" и так далее. А комментарий - это просто другая сущность! Проще пареной репы! Всё великолепно укладывается в голове. Идём далее - есть ТИПЫ узлов, а есть конкретные экземпляры этого типа, т.е. подшивка "Как я провёл лето", заметка "Как правильно толочь воду в ступе", каталог "Прайс лист компании", новости "Новости с фронта переводчиков Drupal".
Всё очень логично и понятно!

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

Но если с точки зрения понимания, то как объяснить, что документ может включать скажем форум? Материал несколько лучше, но как объяснить, что статья - это материал, а комментарий к ней - это уже не материал?

это проблема архитектуры системы. так же можно спросить "если у вас в Drupal'е узлы - это всё что угодно, то почему комментарии - не узлы?"
Нельзя так спросить, потому что узлы не всё что угодно, например комментарий - не узел! Это ты пытаешься сказать, что всё должно называться документом или материалом.

Это те самые "исключения, которые подтверждают правило".
Так комментарий здесь приведёт только в качестве примера. Просто надо понимать и дать понять любому пользователю, что есть сущности, которые могут включать в себя другие (узлы) и есть сущности, которые этого не могут делать! А не всё назвается документами или материалами и никаких гвоздей!

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

Вот пожалуйста! Вчера спорили по поводу "body":
Исходник:
Administrators can also define custom blocks. These blocks consist of a title, a description, and a body which can be as long as you wish.

Перевод из .po файла:
Администратор может определить специальные блоки. Эти блоки состоят из заголовка, описания и текста любой длины.

Простите, но почему в теле (body) блока может быть только "текст"?

Вы не поняли, я не про это спрашивал! Я спросил есть ли ноды, которые не содержат в себе информации, а только сами включают в себя другие ноды. Если они не содержат информации, то какой же это материал?

Хорошо! Уговорили! Пусть node - это будет материал. В глоссарии объясним подробно.
Просматривал вчера перевод drupal. Видимо он очень старый, потому что там очень много как ошибок, так и несоблюдения соглашений по переводу терминов.
Например, материалом там называется также и content, post и ещё что-то (уже забыл)
Post переводится местами как "сообщение", местами как "публикация"
Английское "usually" почему-то переводится "как правило", хотя всегда было "обычно".
Вопрос - кому кидать замеченные ошибки и где будем обсуждать спорные места в переводе?

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

ryurix, а железную дорогу вы "чугункой" не называете? К вопросу об электропочте. Термин E-mail не нужно переводить. Просто E-mail.

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

"Create a new user account." переводить "Зарегистрировать пользователя."
Создание новой учётной записи ещё не означает регистрацию пользователя. Хотя бы потому, что надо пройти эту процедуру регистрации до конца - например через подтверждение по E-mail.

"User login" переводить "Авторизация",
Вы совершенно не понимаете что такое "Авторизация" и "Идентификация". Очень советую исправить этот пробел, чтобы не выглядеть нелепо.

Что касается "Log in" и "Log out", то это вход в систему и выход из неё соответственно и даже не имеют никакого отношения ни к Авторизации ни к Идентификации.

А в моей технической интерпретации watchdog переводиться как сторожевой таймер