Loadырь

Что я не так делаю?

Начните с описания каждого слова

создал

перетаскиваю виджет

Делаю все как

Может кто уже делал.

Однозначно кто-то уже сделал.

Виджет выводит все метки из контента

Списком, плиткой, на карте и какой?
В общем как-то, интереснее, расскажите о вашей задумке.

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

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

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

Не совсем. Статья в основных полях формы должна писаться на основном языке сайта, переводы в подключаемых.
Писать может один человек. Переводить на другие языки могут другие — специально обученные люди — переводчики.

При этом если у нас 3 языка то в форме все "переводные поля" количественно увеличиваются в 3 раза? Получается своеобразная простыня из полей?

Да если у вас 3 языка, то все текстосодержащие поля утраиваются (если у данного пользователя есть доступ ко всем переводам в настройках компонента). Но выглядит это не столь удручающе, как произносится. Обычно французу можно дать доступ к заполнению переводов fr и en, но uk для него будет лишним, поэтому он его и не увидит и будет только 2 поля для ввода из скажем 8.
Можно конечно сделать как озвученный мной первый вариант мультиязычности, но тогда придётся дублировать и заполнять полностью всю форму со всеми непереводимыми полями (например числовыми и дублировать картинки), столько раз сколько есть языков.

Вы считаете что он случайно забрел на этот сайт? Скорее всего действие пользователя было более чем осознанное — он знал что попадет в иностранное окружение.

Обычно на такие сайты попадают либо по прямой наводке, либо из поисковика. В первом случае он знает или предполагает, что его ждёт, во втором поисковик сам даст ему инфу о вашем сайте заполненую на его родном языке. И перейдя из поисковика он не почувствует большого дискомфорта.

Контент и должен оставаться на языке оригинала!

Почему? Это если нет качественного (человеческого) перевода, то да. Машинный перевод лучше не использовать для таких целей. А если есть грамотный перевод, то почему нет?

Да, появляются ошибки и untitled в БД. Я бы отнес это к багам и либо просто сообщил разработчикам, либо отправил коммит. Вы уже изучали код, почему так происходит?

Это не баг, это текущий "вектор" развития cms в направлении "мультиязычности", о которой я писал выше, что движок один, а у англичанина — английский сайт, у русского — русский.
Есть идея для решения данного вопроса. Но это второй этап. Как я говорил компонент должен пройти три этапа перед включением в дистриб — "Огонь, вода и ржавые трубы". Мы сейчас на этапе "Ржавые трубы". Следующий этап — "Вода" — (который возможно, наступит по результатам обсуждения данной темы) — "Общение с разработчиками Fuze, r2 и пр. на предмет внесения изменений в код ядра, с учётом нового вектора развития мультиязычности cms." После этого наступит этап "Огонь", когда сообщество (или заинтересованные в этом люди) протестируют cms с новым функционалом. И только потом наступит долгожданное… Если конечно, всё не закончится на этом этапе, в этой теме.

З.Ы. Что-то я уже начал "сдаваться" от этой идеи. Думал меня листов на 5-6 хватит.
Предлагаю поставить ограничение по времени существования данной темы, скажем до конца мая. А там как решится "да-да, нет-нет"
На вид так вроде всё сообщество тут высказалось. Осталось "победить" только одного "несогласного" .

категории пользователей — это уже пользовательский контент, который не должен переводиться

Включите английский в настройках сайта и создайте пару тройку категорий, но русскими буквами.

перевода интерфейса вполне достаточно, а контент и все связанное с ним переводить не надо

Я так понимаю, что вам как владельцу сайт достаточно того, чтобы было несколько языковых вариаций движка. То есть англичанин берёт движок выставляет в настройках сайта en и пошёл клепать контент на английском. Украинец берёт движок, выставляет в настройках сайта uk и пошёл клепать контент. Русский — тут ему повезло, выбирать в настройках ничего не надо, сразу пошёл клепать контент. Но это не мультиязычность сайта. Я знаю лишь два вида мультиязычности.
1. Когда для разного населения выдают разный контент на их языке. Вот тут нужно наличие en|uk|ru в урле.
2. Когда для разного населения выдают один и тот же контент, но на их языке. Вот тут наличие языка в урле не обязательно. Для поисковиков достаточно указать линк на hreflang.
Я пытаюсь пробить второй вариант.
Теперь смотрим что мы имеем. У англичанина — английский сайт, у украинца — украинский, у русского — русский. Русский заходит к англичанину на сайт и что он там видит? Правильно английский сайт. И если на украинском сайте он мало-помалу по знакомым буквам, что-то сообразит в английском сайте он долго не задержится. Так вот даже если он в сессии или каким-то другим способом изменит системный язык английского сайта на русский, то весь контент, все меню, вся навигация так и останется на английском языке, на русский переведутся лишь несколько фраз с фронта и чуть поболее в админке. А всё потому, что английский пилил англичанин. И другого варианта у него нет.

Что предлагаю я.
1. В настройках сайта указывается основной язык сайта. Не важно какой и для кого. Это основной. Все поля форм заполняются на этом языке. Не нарушается при этом работа при отключенном компоненте перевода.
2. Добавляем дополнительные поля для ввода переводов текстовых данных.
3. Сохраняем эти данные в БД и по надобности выдаём пользователю при их наличии.

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

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

Например при создании категории или записи это получение slug. Будучи на английском языке у вас slug у всех созданных или редактируемых категорий станет одинаковым и будет отличаться лишь уровнем вложенности слова untitled/untitled. С записями та же проблема.

Fuze или r2. Что вы думаете о функционале

Может пока сами определимся, тогда им будет меньше шансов нам отказать.

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

Есть!!! В лисе на демосайте поймал))

Молодец, каков будет вердикт?

Val, вот шифровка

— Набрал 2 раза слово тест
— 4 раза нажал на ентер
— 1 раз нажал на backspace
— 2 раза набрал слово тест
— нажал ентер
— еще 2 раза набрал слово тест

забиваем согласно инструкции и нажимаем кнопку просмотра кода.

Смотрю согласных стало больше. Можно и тему уже прикрывать.

маленькии проблемы но все таки проблемы

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

А насчет вопроса темы у Вас случайно нет предположений?

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

А есть кусок текста в котором получаются такие траблы. Что-то я воспроизвести не могу.

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

boanro, а я периодически подумываю замутить tinyMCE по "полной". С разделением по доступам к функциям редактора для групп пользователей.

Единственное так и на разобрался как сделать чтобы подхватывался размер пресета из настроек

Как-то так