Второй альтернативный внешний сервис для перевода символьного кода - вместо заблокированного Яндекса
В связи с блокировкой в Украине сервисов Яндекса, прошу рассмотреть возможность добавления второго альтернативного внешнего сервиса для перевода символьного кода заголовков элементов и разделов инфоблоков.
Или, как вариант, если возможно, сделать перевод на стороне сервера (чаще всего они заграницей и под блокировку не подпадают)
---
Аналогично, прошу поддержать идею Гугл-карты, как альтернативны заблокированной Яндекс-карте, на странице "Скорость сайта":
ps
У меня VPN-то включен и проблемы нет, а вот у клиентов есть проблема
Или, как вариант, если возможно, сделать перевод на стороне сервера (чаще всего они заграницей и под блокировку не подпадают)
---
Аналогично, прошу поддержать идею Гугл-карты, как альтернативны заблокированной Яндекс-карте, на странице "Скорость сайта":
ps
У меня VPN-то включен и проблемы нет, а вот у клиентов есть проблема
Было-бы неплохо иметь поддержку добавления полей\свойств на разных языках, как это например сделано для Типов почтовых событий
Давайте будем честными, Битрикс не пользуется популярностью на европейском рынке, о таком слове вообще никто не слышал, все знают что такое Друпал, Жумла и Вордпрес, а про Битиркс не слышали.
Хотя по качеству исполнения и по возможностям Битрикс на две головы выше. Хоть в 8-ой версии Друпала и добавили ООП и современные шаблонизаторы, но ядро D7 и ORM все равно оставляют Битиркс лидером по удобству для разработчика, а юзабилити, интерфейс и удобство использования у Битрикса вообще вне конкуренции.
Но все равно, о нем никто не знает, все боятся на ней работать, и дело даже не столкьо в незнании системы, а может даже скорее в том, что система росийская. Ввиду последних событий - сложно представить способ которым можно заставить европейцев использовать российский продукт.
Для чего это нужно:
1. платежеспособность европейских клиентов на порядок выше;
2. легко освоить рынок сайтостроения с помощью более качественной CMS;
3. устойчивость и уверенность в завтрашнем дне для программистов и партнеров.
Все знают, что маркетинговый отдел Битрикс творит чудеса, 10% от общего бюджета, который тратит Битрикс, способен легко переплюнуть рекламные активности других CMS. Просто почему-то такая задача не ставится и никаких действий не прозводится.
Что можно сделать:
1. перевести документацию на английский, чтобы привлечь англоязычных разработчиков;
2. перенести часть производства в другие страны (Германия, Польша, Украина);
3. проводить маркетинговую активность на европейском рынке (спонсорство, выставки, реклама);
4. ввести статус "Англоговорящий партнер" для тех кто хочет работать с европейцами и знает английский.
Для примера, сравните документацию для разработчиков на русском языке:
и на английском:
похоже что на нее (английскую документацию) просто забили, а это как раз одна из основ, почему европейцы боятся осваивать Битрикс, в нем ничего не понятно. Для перевода документации вполне можно привлечь битрикс-сообщество, уверен, у многих хороший технический английский.
Сделать нормальную английскую демо-версию, чтобы любой мог зайти и попробовать ее, а не так как сейчас, заполнить форму, и только тогда может-быть вышлют ссылку на скачивание:
Часть производства (например, разработку Битрикс24, или разработку управления сайтом) перенести в другие страны, привлечь иностранных разработчиков для работы над системой. Чтобы не было репутации чисто-российской разработки, а была больше ориентированной на запад.
Дублировать перевод блогов от Битрикс на английский (сейчас много полезных нововведений разработчики Битрикс пишут прямо в блогах, какой новый функционал, что он умеет), и все это недоступно англоговорящим разработчикам, если нанять переводчика и просто дублировать текст блогов на английский - было бы намного круче. Сейчас же на английской версии сайта мертвым висят новости за 2011 год на главной странице.
В целом выигрывают космополиты, которые могут охватить весь рынок интернета, а не только узкую его часть. К тому же, качество CMS Битиркс на сегодня намного превышает западные аналоги, нужно только захотеть и сделать, все возможно.
Это в том числе заинтересует новых разработчиков писать под Битрикс, так как они будут видеть перспективы развития и выхода на другие рынки.
Хотя по качеству исполнения и по возможностям Битрикс на две головы выше. Хоть в 8-ой версии Друпала и добавили ООП и современные шаблонизаторы, но ядро D7 и ORM все равно оставляют Битиркс лидером по удобству для разработчика, а юзабилити, интерфейс и удобство использования у Битрикса вообще вне конкуренции.
Но все равно, о нем никто не знает, все боятся на ней работать, и дело даже не столкьо в незнании системы, а может даже скорее в том, что система росийская. Ввиду последних событий - сложно представить способ которым можно заставить европейцев использовать российский продукт.
Для чего это нужно:
1. платежеспособность европейских клиентов на порядок выше;
2. легко освоить рынок сайтостроения с помощью более качественной CMS;
3. устойчивость и уверенность в завтрашнем дне для программистов и партнеров.
Все знают, что маркетинговый отдел Битрикс творит чудеса, 10% от общего бюджета, который тратит Битрикс, способен легко переплюнуть рекламные активности других CMS. Просто почему-то такая задача не ставится и никаких действий не прозводится.
Что можно сделать:
1. перевести документацию на английский, чтобы привлечь англоязычных разработчиков;
2. перенести часть производства в другие страны (Германия, Польша, Украина);
3. проводить маркетинговую активность на европейском рынке (спонсорство, выставки, реклама);
4. ввести статус "Англоговорящий партнер" для тех кто хочет работать с европейцами и знает английский.
Для примера, сравните документацию для разработчиков на русском языке:
и на английском:
похоже что на нее (английскую документацию) просто забили, а это как раз одна из основ, почему европейцы боятся осваивать Битрикс, в нем ничего не понятно. Для перевода документации вполне можно привлечь битрикс-сообщество, уверен, у многих хороший технический английский.
Сделать нормальную английскую демо-версию, чтобы любой мог зайти и попробовать ее, а не так как сейчас, заполнить форму, и только тогда может-быть вышлют ссылку на скачивание:
Часть производства (например, разработку Битрикс24, или разработку управления сайтом) перенести в другие страны, привлечь иностранных разработчиков для работы над системой. Чтобы не было репутации чисто-российской разработки, а была больше ориентированной на запад.
Дублировать перевод блогов от Битрикс на английский (сейчас много полезных нововведений разработчики Битрикс пишут прямо в блогах, какой новый функционал, что он умеет), и все это недоступно англоговорящим разработчикам, если нанять переводчика и просто дублировать текст блогов на английский - было бы намного круче. Сейчас же на английской версии сайта мертвым висят новости за 2011 год на главной странице.
В целом выигрывают космополиты, которые могут охватить весь рынок интернета, а не только узкую его часть. К тому же, качество CMS Битиркс на сегодня намного превышает западные аналоги, нужно только захотеть и сделать, все возможно.
Это в том числе заинтересует новых разработчиков писать под Битрикс, так как они будут видеть перспективы развития и выхода на другие рынки.
Идея не моя взята из переписки:
Однако, мне это тоже нужно
Делать отдельные инфоблоки для языковой версии интернет магазина - я считаю это недопустимо сложным решением - в плане работы контент менеджера
Однако, мне это тоже нужно
Делать отдельные инфоблоки для языковой версии интернет магазина - я считаю это недопустимо сложным решением - в плане работы контент менеджера
Поясню в двух слова. Допустим, у нас есть интернет-магазина на трех языках, у которого товары на всех языковых версиях идентичны.
Битрикс рекомендует создавать для этих целей три ифноблока, и в каждом инфоблоке дублировать все свойства, настройки формы редактирования товара, сортирвоку товара, цены, скидки, привязку к категории, значения свойств с типом "список" и тд.
Битрикс рекомендует создавать для этих целей три ифноблока, и в каждом инфоблоке дублировать все свойства, настройки формы редактирования товара, сортирвоку товара, цены, скидки, привязку к категории, значения свойств с типом "список" и тд.
То что имеется на данный момент сейчас - это не многоязычность, это обычная многосайтовость.
Каждый отдельный язык - это просто отдельный сайт, по сути, со своей базой данных (своими инфоблоками).
Нужно иметь возможность делать именно настоящие многоязычные сайты, контент которых полностью симметричен между разными языковыми версиями.
Нужна полноценная поддержка симметричной многоязычности в Битрикс.
Сейчас она есть только на уровне:
- валют
- настроек сайтов
- интерфейса админки
нужна поддержка еще и на уровне остальных модулей:
- инфоблоков
- веб-форм
- опросов
- подписок
- групп пользователей
- свойств заказа для магазина
- почтовых шаблонов
Да, я допускаю вариант, что, например, опрос может быть разный, как для русского, так и для английского языка. Но в то же время, он вполне может быть и одинаковый. То-же самое касается новостей, статей, каталогов и тд.
Должна быть возможость выбора - создавать отдельным инфоблоком, или на одном инфоблоке, в зависимости от потребностей сайта.
Каждый отдельный язык - это просто отдельный сайт, по сути, со своей базой данных (своими инфоблоками).
Нужно иметь возможность делать именно настоящие многоязычные сайты, контент которых полностью симметричен между разными языковыми версиями.
Нужна полноценная поддержка симметричной многоязычности в Битрикс.
Сейчас она есть только на уровне:
- валют
- настроек сайтов
- интерфейса админки
нужна поддержка еще и на уровне остальных модулей:
- инфоблоков
- веб-форм
- опросов
- подписок
- групп пользователей
- свойств заказа для магазина
- почтовых шаблонов
Да, я допускаю вариант, что, например, опрос может быть разный, как для русского, так и для английского языка. Но в то же время, он вполне может быть и одинаковый. То-же самое касается новостей, статей, каталогов и тд.
Должна быть возможость выбора - создавать отдельным инфоблоком, или на одном инфоблоке, в зависимости от потребностей сайта.
Ни для кого не секрет, что большинство сайтов делают мультиязычность для каталогов с помощью дополнительных свойств. Это удобно, так как элемент (с его ценой, картинкой, сортировкой) добавляется один раз, а языкозависимые параметры задаются через дополнительные свойства:
PROPERTY_EN_NAME
PROPERTY_EN_DETAIL_TEXT
...
и тд.
Идея в том, чтобы в стандартных компонентах
bitrix:catalog.element
bitrix:catalog.section
bitrix:catalog.section.list
bitrix:catalog.top
bitrix:news.list
bitrix:news.detail
реализовать поддержку мультиязычности, и в зависимости от константы LANGUAGE_ID и языка по умолчанию, выбирать в $arResult те или иные свойства элемента в качестве основных.
А так же добавить поддержку выборки нужных свойств перевода на уровне API инфоблоков.
PROPERTY_EN_NAME
PROPERTY_EN_DETAIL_TEXT
...
и тд.
Идея в том, чтобы в стандартных компонентах
bitrix:catalog.element
bitrix:catalog.section
bitrix:catalog.section.list
bitrix:catalog.top
bitrix:news.list
bitrix:news.detail
реализовать поддержку мультиязычности, и в зависимости от константы LANGUAGE_ID и языка по умолчанию, выбирать в $arResult те или иные свойства элемента в качестве основных.
А так же добавить поддержку выборки нужных свойств перевода на уровне API инфоблоков.
Сделать перевод/локализации для стран ЕС, таких как Швеция, Франция, Италия и всех других. Уверен что система Битрикс не оставит не одного конкурента.
Не работает транслит/перевод при создани разделов, а это было очень удобно.
Пожалуйста восстановите это как нибудь... =(((
Пожалуйста восстановите это как нибудь... =(((
Ответил 
Kriachek Mikhail 14.12.2011 17:23:09
Kriachek Mikhail 14.12.2011 17:23:09
В скором времени выйдет обновление, где будет использоваться Bing вместо Google
Есть идея - упростить разработчикам создание и сопровождение мультиязычных сайтов. А именно:
---
В каталогах: ни для кого не секрет, что удобнее многоязычные свойства делать как дополнительные свойства инфоблока, а потом в компоненте проверять какой языке и выводить на сайте соответствущие свойства.
Сейчас приходится городить такие костыли:
Хотелось бы иметь штатный механизм, чтобы было АПИ и чтобы компоненты "понимали" какие многоязычные свойства выбирать и показывать на сайте.
---
В модуле подписки у подписчика нельзя выбрать на каком языке он хочет получать подписку. Желательно чтобы полписчик был один, и рубрика подписки одна (так проще управлять) а в параметрах подписчика добавить поле "язык подписки", и при рассылке отправлять ему письмо на том языке, который он выбрал.
---
Чтобы создать веб-форму на нескольких языках приходится или создавать несколько веб-форм (по одной для каждого языка) или писать в названии вопроса варианты ответов через раздилетиль:
Почему-бы не сделать чтобы штатно можно было задавать перевод для вопросов веб-формы и для ответов веб-формы. Было бы очень удобно.
---
Переключение на другой язык. Удобно чтобы мы остались на той-же странице (например, на новости) но на другой языковой версии (с русской на украинскую, или на английскую). Нужно добавить в поставку компонент "переключатель языков" который бы учитывал что такая новость существует и что на неё можно переключиться (чтобы не генерировать ссылки на 404 страницы если перевода новости нет).
---
Напоминание о том, что после создания страницы на одном языке нужно еще зайти в другую языковую версию и там создать страницу. Часто редактор добавляет одну страницу или новость, и забывает что еще нужно создать аналогичную страницу для перевода. Идеальный вариант - чтобы он сразу в одном окне при создании или изменении страницы мог редактировать все языковые варианты этой страницы.
---
Возможность брать константу LANGUAGE_ID не из настроек сайта, а из папки сайта или из домена (например, если мы в папке /en/ то сразу принимать что язык сайта английский, или если на поддомене ua.some-site.com то понимать что язык сайта украинский. Необходимости создавать дополнительный сайт для этого совсем нет, можно просто создать для этого сайта правило по которому определять константу LANGUAGE_ID.
---
В каталогах: ни для кого не секрет, что удобнее многоязычные свойства делать как дополнительные свойства инфоблока, а потом в компоненте проверять какой языке и выводить на сайте соответствущие свойства.
Сейчас приходится городить такие костыли:
while ($arElement = $db_elements->GetNext())
{
// Переводим все свойства на нужный язык (выбираем нужный вариант перевода)
$arElement = CVidiLib::TranslateToLanguage($arElement, $arLangProps, $arLangParams);
... |
Хотелось бы иметь штатный механизм, чтобы было АПИ и чтобы компоненты "понимали" какие многоязычные свойства выбирать и показывать на сайте.
---
В модуле подписки у подписчика нельзя выбрать на каком языке он хочет получать подписку. Желательно чтобы полписчик был один, и рубрика подписки одна (так проще управлять) а в параметрах подписчика добавить поле "язык подписки", и при рассылке отправлять ему письмо на том языке, который он выбрал.
---
Чтобы создать веб-форму на нескольких языках приходится или создавать несколько веб-форм (по одной для каждого языка) или писать в названии вопроса варианты ответов через раздилетиль:
ФИО|ПІБ|Name |
---
Переключение на другой язык. Удобно чтобы мы остались на той-же странице (например, на новости) но на другой языковой версии (с русской на украинскую, или на английскую). Нужно добавить в поставку компонент "переключатель языков" который бы учитывал что такая новость существует и что на неё можно переключиться (чтобы не генерировать ссылки на 404 страницы если перевода новости нет).
---
Напоминание о том, что после создания страницы на одном языке нужно еще зайти в другую языковую версию и там создать страницу. Часто редактор добавляет одну страницу или новость, и забывает что еще нужно создать аналогичную страницу для перевода. Идеальный вариант - чтобы он сразу в одном окне при создании или изменении страницы мог редактировать все языковые варианты этой страницы.
---
Возможность брать константу LANGUAGE_ID не из настроек сайта, а из папки сайта или из домена (например, если мы в папке /en/ то сразу принимать что язык сайта английский, или если на поддомене ua.some-site.com то понимать что язык сайта украинский. Необходимости создавать дополнительный сайт для этого совсем нет, можно просто создать для этого сайта правило по которому определять константу LANGUAGE_ID.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
