
Компонент "Языки" теперь стал поистине тотальным. Данное обновление коснулось в основном двух немаловажных аспектов — переводу форм и географических объектов. Теперь ваши пользователи могут видеть на родном для себя языке не только контент, категории, теги, но и формы регистрации, редактирования профиля, загрузки фото, создания категорий и добавления записей. Переведено практически все, до чего можно было дотянуться — заголовки fieldset-ов, заголовки полей, подсказки к полям, содержимое списков полей, списков категорий, списков групп и т.д.
Помимо перевода добавлена возможность управлять добавлением контента — доступно 3 варианта добавления контента на сайт:
— Стандартный(весь контент добавляется на сайт в том виде, в котором его ввел пользователь)
— Автоперевод(контент, добавленный пользователем будет автоматически переведен на все языки)
— Полный контроль(пользователь может полностью контролировать процесс добавления контента и его перевода)
Для разных групп пользователей предусмотрена своя настройка контроля форм, что позволит не нагружая пользователя обязательностью перевода сделать это вместо него. Вы сами решаете кто может использовать расширенные формы добавления контента, а кто нет.
По просьбам трудящихся реализован перевод названий стран, регионов, городов. Теперь везде, где требуется выбор/отображение города будет использоваться язык страницы. Перевод базы названий за вами, на это у меня, к сожалению, нет ни времени, ни столь обширных географических познаний. Для работы данной возможности и создания баз объектов на других языках вы можете использовать как таблицы БД из русской версии системы, так и из англоязычной. Главное, чтобы они были идентичны установленным в системе. Обо всем подробнее в небольшом видео-обзоре:
Компонент полностью бесплатен, однако любые пожертвования будут восприняты мной как степень заинтересованности сообщества в улучшении компонента и будут стимулировать меня к его развитию. Поблагодарить можно по реквизитам, указанным в профиле или воспользовавшись кнопками на этой странице.
Автор работает с большим опережением, внедряет то, что даже не успеваю предложить (например, варианты выбора авто- и модерируемых- переводов - просто класс!).
Кто за? Ставьте плюс компоненту и его разработчику. Завалите его плюсами, чтобы это было убедительным аргументом для создателей замечательного Инстанта
В системе изначально нет четкой границы между ядром и шаблоном. Если разработчики читают комментарии, думаю они поймут о чем я. Нет такого места, где все переменные собраны, структурированы и подготовлены к выдаче в шаблон. Что-то приходится выдергивать в одном месте, что-то в другом. Вкладки групп и профилей, наборы, свойства, поля форм и многие другие вещи живут своей жизнью вообще не подозревая, что у системы есть ядро. Свойства при выводе объявлений получаются и выводятся прямо в шаблоне минуя контроллер, а при добавлении объявления при помощи ajax-запроса, в формах эти же свойства рендерятся прямо в html. И т.д. и т.п.
И пусть написанное мной будет воспринято адекватно. Я знаю как нелегко продумать архитектуру столь крупного и функционального продукта. И справились разработчики с этим на отлично. На мой взгляд описанное мной выше это единственный минус 2-й ветки Инстанта, все остальное реализовано разработчиками в лучшем виде и я даже не знаю стоит ли обращать внимание разработчиков на данный вопрос, ведь подобный функционал практически не востребован сообществом, а вы призываете их основательно перелопатить код системы.
Нужно ли это всему сообществу? Или повлечет за собой только кучу ненужной работы - перекраивание шаблонов, переписывание компонентов, виджетов? Рады ли будут этому пользователи системы? Ведь для тех, кому это не нужно это только головная боль, а таких большинство.
1. Нужна ли многоязычность Инстанту? На этот вопрос ответили еще год назад! нужна и очень!
2. Заинтересованы ли сами разработчики в наличии многоязычности у родного движка? На этот вопрос тоже уже дан ответ при разработке компонента Мультиязычность. Да нужна.
Все это было до появления нового компонента "Языки", который оказался полной неожиданностью для многих и заставил пересматривать подход к многоязыковости Инстанта. В связи с этим возникают следующие вопросы:
3. Нужен ли компонент "Язык" Инстанту? Если он лучше других, тогда конечно нужен! Но использовать его как дополнительный функционал при столь тесном переплетении с кодом движка очень и очень проблематично...
4. Интересен ли компонент "Языки" разработчикам Инстанта - на этот вопрос отвечать им. Выскажу свое мнение, что скорее всего интересен, тем более, что интеграция в движек просится сама. Достойный компонент уже сейчас, практически как спрут вгрызается в код Инстанта. Но до полной интеграции еще много работы! А поэтому если разработчик сам поможет с интеграцией компонента "Языки" в Инстант, то кто будет против?
В итоге вопрос интеграции "Языков" в Инстант - это вопрос желания тесного взаимодействия обеих сторон. Как то так.
Это мое личное мнение. А мы потребители, конечно обеими руками ЗА.
С Наступающим вас!
Проблема появляется после замены templates/default/assets/ui/form.tpl.php.
Модуль обновлял с первой версии по инструкции.
Пробовал и ручное добавление необходимых правок, так и замену файлами из папки res. Куда копать в этом случае?
2. Проверьте разные формы на сайте. При выводе каких возникает ошибка, а при выводе каких нет. 3.
Судя по тому, что пользуются компонентом многие, а проблема только у вас значит проблема скорее всего либо в сторонних компонентах, либо в самописных полях. Трудно делать предположения вслепую.
Не выводятся абсолютно все поля, включая админку. Сторонние компоненты в админке отключил - эффекто не дало. Отключил даже все остальные компаненты, которые имеют такую возможность, вплоть до собственно компонента "языки", что в общем то тоже не помогло. Версия Instant - 2.6.1
Самописные поля отключать пока не пробовал, как попробую - дополню комментарий.
Если код начинался с
в php.ini должна быть включена опция short_open_tag,
А стандарт разрешает использовать и <?php, и короткие теги <?
http://www.php-fig.org/psr/psr-1/
Когда в настройках сайта включаю функцию «Сжимать HTML», то перевод не срабатывает.
Этот файл содержит код, удаленный из файла templates/default/assets/ui/form.tpl.php
Поиск по переводу не работает
Привожу пример на скриншётах.
1. Статья на Русском:
2. Та же статья из той же категории но как видно на скриншёте названия категорий в виджете в сайдбаре изменились на несоответствующие данной категории статей.
Причем, при переходе на русский (исходный) язык виджет работает опять правильно, но на переводимом языке вот такая ситуация. (инстант 271). Что посоветуете?
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
1. В остальных формах(добавить контент, добавить категорию) у вас все переводится? Заголовки fieldset-ов все переведены?
2. Попробуйте заменить в файле forms.tpl.php(строка ~ 63)
forms.tpl.php * form.tpl.php
все заголовки связанные с профилем имеют item_id = 0, скажите, а вы переводили значения до обновления 1.1?
Заменились системные файлы самого движка на новые и это естественно повлияло на работоспособность компонента.
Хотелось узнать, будет ли обновление компонента «Языки» под последнюю версию Инстант?
Если есть другие плагины, то можете получить ошибку 500. Полностью падает кмс.
http://img-fotki.yandex.ru/get/201221/109657871.c/0_56b808_74093e7e_orig.png - на других страницах сайта.
Включайте режим отладки, читайте ошибку.
Кстати, это считается в корень или не в корень?
В принципе, проблема не критичная, без виджета активности жить можно. Если она у меня одного такая, то и бог с ней
Платежные системы переводить не стал, у иностранцев они другие. Так же не было нигде языковой константы для вкладки в профиле "Личный кабинет" она пока осталась без перевода, как решу - дополню этот комментарий. На странице, куда вы перейдете по ссылке, можно ознакомится с текстом перевода, а внизу поста скачать прикрепленный файл billingeng.php
Пользуйтесь.
просто добавить в нее ваш (код) или заменить ?
После замены <?php echo $field->getInput($value); ?> в файле templates/default/assets/ui/form.tpl.php у полей вырезается символ "1" как в содержании полей, так и в принципе при выводе. Например: Если в поле была опция 1, она вырезается полностью, если было 1+2, остается только +2, если в свойствах chosen было прописано width='100%', в вывод попадает width='00%'.
Куда можно покопать в этом случае?
Думаю причину стоит искать в другом месте. Версия системы на скрине - 2.7.1
Что интересно, если добавить нумерацию, то выводится нормально.
Еще небольшой вопрос, Вы обновляли у себя системные файлы модели и поля для geo до версии 2.7.1? Если да, можете выложить обновленную версию?
Стандартную базу мне кажется особого смысла переводить нет, в ней много чего не хватает, поэтому думаю каждый самостоятельно её дорабатывает под свои нужды, поэтому для меня тут главное именно возможность подцепить перевод :)
Я тут себе хотел подключить редактор Tiny MCE к текстовым полям, но при переходе на Tiny MCE текстовые поля перестали переводиться. Это проблема редактора, или надо вносить какие-то изменения в самом компоненте Языки?
Кнопки перевода с tinymce работать не будут это факт, а сам редактор показываться должен без проблем. Компонент языки никак на это не влияет.
http://img-fotki.yandex.ru/get/196486/109657871.11/0_56e038_a2eccd95_orig.png
Ее надо править под tinymce
И второй вопрос:
При переводе поля типа text в контенте теряются символы перевода строки <br> т.е. имеем исходный текст расположенный в столбик:
До нажатия кнопки "Перевести": http://img-fotki.yandex.ru/get/43843/109657871.14/0_56f80e_5fbe1a87_orig.png
После нажатия кнопки: http://img-fotki.yandex.ru/get/105020/109657871.14/0_56f80f_25ab20b3_orig.png
Имеется в виду следующее:
при записи (на этом этапе) в таблицу Языков переведенного поля типа text (именно этого поля) - в форме этого поля не видно сразу br, но они то есть и после перевода исчезают.
Чтобы смоделировать ситуацию попробуйте скопировать из html редактора в поле ввода текста от text набор строчек с <br>
Отвечаю как понимаю ситуацию: на ваших скринах всё верно, но если поле будет типа text , то там редактора не должно быть а только форма, вот в этой форме и расположенные ранее в столбик слова фактически имеют между собой <br> но ведь мы их (брейки) не видим (т к режим не html)
При переводе этого и перевод правильно (казалось бы) расположен в столбик, но если запишем результат и посмотрим запись контента вживую - получаем потерю построчного расположения (а при сравнении в инспекторе результирующего html как и при сравнении записи в исходной базе поля и переведенной видна пропажа <br>.
брейки, о которых говорил стали выводиться корректно - строки не соединяются -)
... но другие html теги выводит в виде символов в тестах, т.е. в выводимом коде они например, виде
Спасибо!
Приятно работать с профессионалом!
Если что замечу - сообщу (странно, что никто раньше не заметил) - я тщательный тестер ( ещё не было секунд проверить ваши вкладки и парсер -) )
Исходный текст: http://img-fotki.yandex.ru/get/9814/109657871.14/0_56f811_314b720_orig.png
Перевод: http://img-fotki.yandex.ru/get/198026/109657871.14/0_56f810_aee8bc6a_orig.png
Кстати, в таблице languages_fields поле title было varchar (128) - оказалось маловато для сколько-нибудь реального списка выбора - подкорректировал на varchar (192) т.к. туда записываются эти списки и изначально их срезало.
Кто-то ставил на 2.7.1? Правильно работает? К примеру, связи не "улетучиваются"?
Спасибо!
Может здесь что-то посоветуете?
За компонент таки огромное спасибо!
cmsCore::getLanguageName();// текущий язык страницы
Еще от автора
Компонент «Продажа полей» для ICMS 2
Компонент «Мотивация пользователей» для ICMS 2
Поле «Поддерживаю!» для ICMS 2
InstantCMS Team
Связь с нами
Email dev@instantcms.ru
Делаем полезные Интернет проекты с 2008 года 💫
О проекте
Поддержка
Дополнения