А быстрое решение для добавления файлов из папок -
/admin/content/media/import
и втянуть файлы в Media Library из заданной директории по заданному шаблону (*.jpg и т.п.).
При этом ограничение PHP на максимальный размер файла не действует.

"Для любого блока" не получится, каждый блок нужно настраивать отдельно.
Есть два варианта: (1) сделать два блока, английский и русский; (2) сделать один многоязычный блок, в котором постоянное содержание перевести один раз с помощью системы перевода строк интерфейса, а если выводится вид, то добавить к фильтрам "i18n content negotiation". По поводу изображений нужно придумать критерий отбора.

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

Напрашивается ответ: "Считаю, что можно".

А если нужен более подробный ответ, то лучше задавать более конкретный вопрос.
Вот, допустим, сайт мини-конференции:
http://camp09.drupal.ua.
Сделан на трёх языках.
Можно сделать сайт по образу и подобию, можно другой. Или третий, или четвёртый.

Вспугнули, блин.
А вдруг бы таки написал скрипт...

Напиши лучше скрипт.

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

Если флажок должен быть виден, куда он должен показывать?

На тему симметризации мне пока ничего не подсказали - ни на drupal.ru (1, 2), ни на drupal.org (1, 2).

В чём в данном случае должна заключаться гибкость системы и грамотность навигации?
В том, что для любого нейтрального по языку контента логотип, заголовок, менюшки, блоки, ссылки и прочий интерфейс должны выводиться _только_ на дефолтном языке? И что при этом должно происходить с переключателем языка? Должен ли он быть на странице с нейтральным контентом (а) вообще не виден, (б) неактивен, или (в) псевдоактивен (то бишь как бы активен, но на самом деле не переключать ни контента, ни интерфейса, ни URL)?

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

Тут дело хозяйское. Хотите делать ноду нейтральной - делайте, не хотите - делайте одноязычной, а в качестве перевода поставьте "ещё не переведено на немецкий" или "немецкой версии нет в наличии". С приложением далее англоязычной версии или без.
Аналогично и с видами. Хотите ставьте фильтр по языку, хотите - нет, чтобы на альтернативном языке находилось то же самое или не находилось ничего, как оно лучше по логике и по смыслу.
Я вообще считаю, что сайт делается в первую очередь для людей, и только во вторую - для роботов.

А как должен вести себя Друпал в данной ситуации?
Переключаться на http://www.site.com/photogallery/95?
А какой при этом должен выводиться логотип, заголовок, меню, блоки и всё остальное - английский или немецкий?
По-моему, даже если картинка одна и та же, то окружение у неё разное. Так что я бы назвал это не багой, а фичей.

Штатные модули лежат в /modules, дополнительные в старых версиях друпала копировались туда же, а теперь их для порядку рекомендуется класть в /sites/all/modules.
У каждого модуля там своя директория, очищать не надо.
Если ни черта не понятно, стоит наконец почитать RTFM :).

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

С такими хостерами, у которых на сервере часы неправильно выставлены, мне пока сталкиваться не приходилось...

О, спасибо. Пока не нужен, но вмемориз.

Когда-то был модуль htmlwrap, но его забросили на 4.7.x версии.

Ну тогда попробуй ATCK какой-нибудь.

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

Я бы такие вещи делал не через таксономию, а через CCK.
Имя ноды
- название параметра 1
- значение 1
- название параметра 2
- значение 1
- значение 2
- значение 3
и так далее.
И получается оно штатными средствами, даже при обычном выводе ноды совсем без view.

В общем, чего-то я не понимаю с этими Per language terms.

Следует? Раньше я использовал общие термины, и всё, что я от них хотел, в общем-то работало (если не углубляться в некоторые моменты, которых при отсутствии Views и CCK не возникает). А теперь в естествоиспытательных целях попробовал Per language terms с переводом, и у меня этот вариант вообще работает некорректно (не вижу никакого эффекта от объявления категорий переводами друг друга) - возможно, из-за взаимодействия с 6.x-1.x-dev версией i18n, или не знаю почему.