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

Тот вариант перевода магазина на Битриксе на другой язык что есть сейчас ОЧЕНЬ неудобный и сложный. Сделайте, пожалуйста, возможность просто переводить магазин на другие языки. Как это сделано например в CS CART. У них все очень просто и удобно. Сколько же можно уже тянуть с этим....

В мобильном приложении добавить выбор языка интерфейса, в облаке эта возможность есть.

посмотрел видео партнерки. там снова поднимался вопрос о нескольких языках в инфоблоках. хотел бы предложить свой вариант реализации с минимальной кастомизацией продукта. Может компанию Битрикс заинтересует. Или кто-нибдуь из партнеров выпустит модуль и обогатится ))

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

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


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


4. Для хранения данных по другим языкам (отличным от основного) нам потребуется дополнительная таблица или две - если сделать отдельно для элементов инфоблока и отдельно для разделов (в нюансах работы mysql я не силен, поэтому предложу общую схему - думаю кто разбирается додумает) в этой таблице будет хранится языковые версии данных. Для этого в таблице должны быть следующие поля:
- ID записи
- ID элемента инфоблока
- ID языка
- Код поля или свойства для которого мы храним данные (например PREVIEW_TEXT, для свойств - как при выборке: PROPERTY_КОД_ПОЛЯ)
- Значение (тут у меня сомнения, поскольку значения бывают разных типов (строка, текст, дата, число - можно использовать наверное 4 разных поля для каждого типа значения)
Для разделов - аналогичная структура, только вместо ID элемента - ID раздела

5. Нам потребуется несколько функций для вывода и записи данных (я не программист - опишу своими словами).
Нам потребуется 4 функций для работы с каждой из таблиц (для элементов и для разделов)
- Добавления
- Редактирование
- Обновление
- Удаление
Итого 8 функций, 1 класс (CIBlockLang) для работы с языковыми версиями инфоблока

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

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

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

Надо иметь возможность задать язык админки (для каждого из сайтов и/или всего проекта) для каждой группы

Для описания в языковых файлах предлагаю
1. Использовать сами идентификаторы описываемых событий, то есть например:
без добавления дополнительных идентификаторов, типа "mymodul_" и т.д., так как по заданному стандарту предполагается присутствие всех нужных партнерских идентификаторов в имени идентификатора события.
2. Описывать событие в неопределенной форме, кратко, то есть "Добавление раздела инфоблока" можно использовать такое описание в любом месте, а вот "Событие вызываемое при добавлении раздела информационного блока", или "Вызывается при создании раздела", или "Позволяет изменить данные созданного раздела" и т.д. не универсально.
3. Описывать только стабильные события, то есть те, которые можно смело использовать, не боясь, что они будут переименованы, удалены и т.д.

Наличие языковых файлов позволит разработчикам, использующих события:
1. Упростить поиск доступных и стабильных событий.
2. Упростит получение списка событий в человекопонятном виде, а значит уменьшит время на формирование функционала, и исключит не нужны прослойки.
3. Упростит жизнь тем, кто активно работает с событиями, освободив массу времени от задач по постоянному добавлению новых событий, удалению убитых и т.д.

Ну реально наболело и отнимает слишком много времени на актуализацию и очеловечивание списка событий, особенно в части партнерских модулей!

ВАЖНО: ключи в массиве языковых значений должны полностью соответствовать символьному представлению события в коде включая РЕГИСТР, это значительно упростит написание кода, это позволит получать символьное представление событий для динамической вставки в код, равно как позволит получать человекопонятное описание события для последующей динамической вставки и вывода и т.д.

/ru/
/en/
/de/
etc.
1 сайт, разное содержание у каждого инфоблока/статьи, редактирование соответственно в одном месте.
соответственно html lng='lng', мета, у инфоблоков доп аттрибут язык, настраиваемая часть URL (в данном случае site.ru/xx/).
Со всеми вытекающими.  

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

Подавляющее большинство фразу  "Показывать баннеры с равномерной скоростью" понимает как распределение показов по дням, т.е. если 1000 показов и интервал 10 дней и галочка отмечена, значит будет по 100 раз в день показываться. Огромное количество жалоб на то что данная функция не работает.

Примечание "Параметр равномерного показа не учитывает настройку "Время и дни недели для показа" ничего не объясняет, ну да просто не будет учитываться.



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


В настройках таргетинга, добавить возможность выбора страниц из структуры сайта.
Пример:



Конечно было бы идеально ещё добавить возможность кастомизации формы как в инфоблоках.

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

Сделать перевод/локализации для стран ЕС, таких как Швеция, Франция, Италия и всех других. Уверен что система Битрикс не оставит не одного конкурента.