Пользовательская экспертиза компонента Translate

Взываю к логике)) — не надо утяжелять движок такой функциональностью!

Утежелять — по факту на сегодня это только ассоциативное мнение…

Не вижу никакого смысла проталкивать этот функционал в коробку

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

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

Эмоции… враг конструктивного диалога.

О том и тема! Может не функционал переводчика а решение где будет использовано хранение, добавление, редактирование данных в таблицах базы данных, и выбор данных по условию установленного языка. Это очевидное решение. Перевод может быть как вспомогательная функция при создании=редактировании записи контента.

Функционал, компонент, решение — смысл от этого не меняется)) Я абсолютно не против этого, но я считаю что такое решение (компонент, функционал) в коробке лишний. Как отдельный компонент (пусть даже vip-компонент или официальный компонент) в каталоге расширений — ДА!

Эмоции… враг конструктивного диалога.

Без эмоций)) попробовал провести аналогию почему я считаю такой функционал лишним. Может плохо получилось
Смотрите, цель iCMS — создание сайта для сообществ (либо тематических сайтов и др. сайтов)) ), т.е. на сайте автор или пользователи могут добавлять различный контент и как то взаимодействовать с этим контентом и между собой (комментировать, влиять на рейтинг и др.). Я считаю (возможно ошибочно), что в этом направлении и нужно развивать движок. Перевод контента это параллельная задача, т.е. она конечно же косвенно пересекается с основными целями, но больше подходит для "специального проекта" (я потому и спросил как много мультиязычных сайтов кто держит). Абсолютно так же и графический редактор для картинок — никто же не будет отрицать что удобно при добавлении статьи вставить фотку и тут же ее отредактировать (повернуть, обрезать, отразить, дорисовать рамочки/стрелочки и т.д.). Но этот функционал излишен в рамках основных задач iCMS2. И если кто-то хочет расширить функционал движок не запрещает этого сделать! Тогда зачем добавлять в коробку то, чем будут пользоваться далеко не все и не всегда?

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

одними хуками тут ни как не справиться

Ну не знаю… Перевести контент и интерфейс можно вообще и без хуков и без движка в целом)) (я Google Translate например имею ввиду).
Loadырь, можете объяснить какие конкретно моменты не получится реализовать одними только хуками?

VAL! Я ваше мнение и без развернутой простыни понял. К чему мне так подробно обьяснять?

Прошу прощения, я подумал что криво донёс свою мысль, потому и повторился еще раз… так сказать "те же яйца, только в профиль"

Также, по возможности, прошу высказаться Fuze или r2. Что вы думаете о функционале переключения "языка на лету" и встроенного переводчика в InstantCMS 2? Заранее спасибо!

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

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

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

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

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

Что касается slug, я понимаю, он должен быть одинаков для любого языка. (Предполагаю что при любом раскладе есть основной язык и есть дополнительные.) Если основной русский, тогда, например, для категории (бегать, прыгать, гулять) — slug: begat, prygat, gulyat. (Если основной английский язык, тогда категории будут называться: run, jump, walk и такой же slug: run, jump, walk.) Соответственно при переходе на английский язык переводим title (run, jump, walk), а slug остаётся стандартный (begat, prygat, gulyat).

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

Встает вопрос видения мультиязычного сайта. Нужно первоначально понять и сформулировать как и что должно быть. В моем понимании перевода интерфейса вполне достаточно, а контент и все связанное с ним переводить не надо.
Loadырь, опишите своё видение мультиязычности? Также предлагаю остальным заинтересованным описать своё видение (желательно по пунктам).

Решил всё таки немного пояснить свою точку зрения про

категории являются частью пользовательского контента

Известно, что все языковые файлы хранятся отдельно в ..\system\languages\*.* и движок при рендере html-страницы тянет необходимые названия оттуда.
В случае с упомянутыми категориями значения строк берутся напрямую из БД, а не файлов папки languages. Т.е. чтобы категории полноценно участвовали в языковых переводах, необходимо в БД вместо title хранить языковые константы, на основании которых уже подтягивать соответствующие значения на нужном языке.

Такая концепция не решает вопросов добавления категорий пользователями, но категории пользователей — это уже пользовательский контент, который не должен переводиться. А вышеописанный механизм категорий немного другая сущность =)

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

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

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

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

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

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

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

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

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

Русский заходит к англичанину на сайт и что он там видит? Правильно английский сайт. И если на украинском сайте он мало-помалу по знакомым буквам, что-то сообразит в английском сайте он долго не задержится.

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

весь контент, все меню, вся навигация так и останется на английском языке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я к тому, что доступ на оригинал должен быть. Иногда очень хочется/нужно почитать именно оригинал. В рамках движка и глобально, считаю, удобно делать именно как независимые статьи (оригинал и ее переводы), через биндинги можно показывать любую версию. Человек зашел по ссылке на какую-либо статью, а ему предлагают к ней переводы по своим ссылкам. Если ему интересно он перейдет и почитает.
Про машинный перевод я молчу — его вообще нет смысла использовать!

Это не баг, это текущий "вектор" развития cms

Вам конечно виднее, т.к. я код в этом направлении не изучал. Но при использовании UTF-8 я должен хоть на китайском, хоть на русском языке написать в любой локализации движка, и он должен проглотить мои записи и обработать их как на своей родной локали. Будет время поковыряюсь в этом направлении...

З.Ы. Что-то я уже начал "сдаваться" от этой идеи. Думал меня листов на 5-6 хватит.

Не сдавайтесь! )) Если я вас уморил, могу больше не беспокоить эту тему. Хочется, если уж делать, то делать хорошо и максимально универсально. Чтобы не переживать за различные компоненты основанные на типах контента (типа мапса, вопросов ответов и др.) у которых могут возникнуть проблемы из-за новых полей, например, изменения структуры БД или чего-то другого.
Также хочется сохранить логичную архитектуру движка (вся локализация отдельно в файлах ..\system\languages\), а не выстраивать "костыли" которые будут сильно затруднять разработку и поддержку в будущем. Возможно придётся более кардинально влезть в ядро системы, но это будет оправдано.

На вид так вроде всё сообщество тут высказалось. Осталось "победить" только одного "несогласного"

Ну… про всё сообщество это вы преувеличили)) Человек 10-20 не больше)) Тем более я уже приводил пример с графическим редактором — предложите эту идею и большинство её поддержит, т.к. все "за" хорошие перспективы, и всем всё равно как это будет работать. Но если будет работать плохо, то все потихоньку "сольются"...

P.S. Я уже несколько раз отвечал я не несогласен, но я за разумное внедрение. Часть ваших идей считаю лишним для встраивания в коробку, хотя с другой частью могу согласиться, а третья часть нуждается в качественной переработке, первоначально на уровне продумывания архитектуры, перед внедрением в движок. В итоге на 2/3 я с вами согласен
P.P.S. блин, не могу я кратко излагать свои мысли((

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

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

компонентик небольшой для народа. Протестирую и выложу.

ждем)

ждем)

Этот компонент никак не связан с обсуждаемым тут "переводчиком".