dwd

В чем беда то? Зачем вы себя мучаете? Настройте крон на сайте и включите задачу в планировщике. Попросите техподдержку хостинга это сделать, там работы на 5 минут.

Дополнение использует геокодер Яндекса для определения координат, а для отображения используйте чего хотите, координаты у всех одинаковы.

Выходит это парсер для всего, в том числе и для мапса.

Элементарно. В одной таблице хранятся и заголовки полей и подсказки и заголовки fieldset-ов, просто они имеют разные ctype

http://img-fotki.yandex.ru/get/51322/109657871.7/0_56a5d0_d4b09a47_orig.png
все заголовки связанные с профилем имеют item_id = 0, скажите, а вы переводили значения до обновления 1.1?

Не понял вопроса

Мистика да и только. Только что установил свежую копию системы, скачал из каталога дополнений компонент(версия 1.1.1), установил, залил папку res в корень сайта и перевел заголовок Анкета - http://img-fotki.yandex.ru/get/194425/109657871.7/0_56a5cd_48f0f411_orig.png. Все работает !!!!!!

Вообще мистика какая-то. Ясно одно - нужная запись в БД не найдена. Попробуйте посмотреть что у вас в таблице - http://img-fotki.yandex.ru/get/51057/109657871.7/0_56a5a2_4cbb0914_orig.png, а я пока поставлю новый сайт на локалке и проверю на нем.

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

строка ~ 75
замените на
и все должно заработать.

Дата рождения не переводится, так и должно быть. Это не название поля( http://img-fotki.yandex.ru/get/171750/109657871.6/0_56a508_f6855365_orig.png) и хранится она черт знает где и ради нее писать столько же кода сколько ради всех остальных заголовков мне было лень. Лично я удаляю это поле сразу, при регистрации просить вводить дату это признак дурного тона.)) Все остальное должно перевестись.

1. В остальных формах(добавить контент, добавить категорию) у вас все переводится? Заголовки fieldset-ов все переведены?
2. Попробуйте заменить в файле forms.tpl.php(строка ~ 63)
и (строка ~ 75)
на
посмотреть на результат.

У вас вообще перевод форм не работает, я не вижу ни одного переведенного поля - http://img-fotki.yandex.ru/get/112776/109657871.6/0_56a507_980436c3_orig.png, вы файлик form.tpl.php в папку какого шаблона закинули?

У меня на тестовом сайте языка 4. Это никак ни на что не влияет. У вас их может быть 53 и все будут работать.

Хорошо, заголовок не перевелся, это вы уже и раньше говорили. Что еще не перевелось? "так далее" это что такое? Чего из вас все клещами тянуть приходится? Если хотите чтоб вам помогли опишите подробнее, скриншотик сделайте. Можете мне на почту скинуть, можете прислать ваш файлик form.tpl.php, надо ж как-то ставить диагноз.

Кстати, я правильно вас понял? Не переведены все поля группы? Или же не переводится только заголовок группы?

Полное описание вставок есть в файле readme.txt в архиве с компонентом. Я не знаю, что именно вы хотите там найти, но если интересно, то за перевод всех форм сайта отвечает одна единственная вставка в файле templates/default/assets/ui/form.tpl.php (строка ~ 170-180) и примерно строк 500 кода в файле system/controllers/languages/model.php, обслуживающих эту вставку. Я кстати поинтересовался у людей, использующих компонент, ваша проблема носит единичный характер, ни у кого таких проблем нет.

Пройдите по ссылке http://ваш_сайт/admin/controllers/edit/languages/content/userfields/userfields и переведите все значения. Алгоритм перевода абсолютно всех форм на сайте един, поэтому если у вас переводятся все другие формы то думаю проблема заключается в том, что вы просто не перевели значения.

Первый раз об этом слышу:
http://img-fotki.yandex.ru/get/174613/109657871.6/0_56a4af_7a0d0ab6_orig.png
http://img-fotki.yandex.ru/get/198488/109657871.6/0_56a4ae_b1dbb04b_orig.png

В системе есть такая возможность. При создании поля вы можете указать какие группы пользователей будут видеть его при добавлении/редактировании записи:

Ну так я про это и не говорю. Я говорю про то, что надо создать механизм управления существующими правилами. Чтобы на базе существующих в системе/компоненте правил пользователь мог создавать свои. Я ж выше так и писал:
"Существуют их обработчики. Со временем добавите новые. А для начала не надо ничего глобально дописывать/переделывать. просто дайте пользователям возможность переопределять данные правила в зависимости от ряда условий.".
При создании типа контента или разработчиком стороннего компонента изначально создается базовый набор правил. А гибкость заключается в возможности их дифференциального использования в разных участках типа контента/компонента. В этой категории хочу, в этой не хочу. Общий ход моей мысли вижу вы уже поняли.