Что такое локализация 1с
Особенности использования строк интерфейса конфигурации на разных языках
Платформа 1С:Предприятие 8 предоставляет набор механизмов для удобной локализации конфигураций. Одним из них является поддержка строк на разных языках. Такие строки позволяют хранить интерфейсные (предназначенные для пользователя) тексты на нескольких языках одновременно, при этом пользователь соответствующую строку увидит на своем (указанном в его настройках) языке. Используются эти строки очень широко. Например, в таком виде задаются синонимы (представления) объектов метаданных, тексты в формах, меню и табличных документах. В данной статье мы рассмотрим особенности хранения и редактирования подобных строк.
Языки конфигурации
Набор доступных для пользователей языков определяется объектами метаданных "Язык". Каждый язык помимо стандартных свойств "Имя", "Синоним" и "Комментарий" имеет свойство "Код языка". Это свойство представляет собой строку , которую рекомендуется определять в соответствии с международным стандартом двухбуквенных кодов языков ISO-639. Это требование не обязательное, однако исключительно важно, чтобы в пределах конфигурации данные коды были уникальны. Как мы увидим, в отличие от других объектов метаданных, именно код, а не имя является основным идентификатором языка.
Отображение строк на разных языках
В режиме Конфигуратора строки отображаются на языке редактирования конфигурации, который может быть изменен через выпадающее меню в правом нижнем углу основного окна Конфигуратора. В режиме 1С:Предприятие строки отображаются на языке, выбранном в настройках пользователя, доступных из списка пользователей меню администрирования. Если ни одного пользователя в информационной базе не заведено, используется основной язык конфигурации.
Хранение строк на разных языках и связь с языками конфигурации
Строка на разных языках представляет собой набор пар код-строка. То есть привязка к конкретному языку осуществляется именно по коду, а не по имени или внутреннему идентификатору (данное замечание касается именно строк, поскольку, например, свойство конфигурации "Основной язык" для привязки использует внутренний идентификатор, и редактирование имени и кода языка на него никак не влияет). Что же происходит со строками при изменении кода языка? Ничего. Автоматическая "перепривязка" строк не производится. Таким образом, все строки, привязанные к старому коду, будут недоступны.
Редактирование строк на разных языках
Для формирования строк на языках, отличных от языка редактирования конфигурации, можно использовать редактор в панели свойств. В случае если в конфигурации заведено более одного языка, в нем будет доступна кнопка открытия ("лупа"), нажатие на которую вызывает диалог, позволяющий редактировать содержимое на всех языках, заведенных в данный момент в конфигурации. Однако для решения описанной выше проблемы (потери строк при изменении кода языка) этот способ не подходит. Во-первых, строки со старым кодом в этот диалог просто не попадут, да и "разыскивание" всех строк по всей конфигурации задача утомительная. Для восстановления связи с утерянными строками следует воспользоваться механизмом редактирования текстов интерфейса, доступным из меню "Правка". Данный механизм производит сканирование всей конфигурации (или указанного подмножества объектов) и выводит список всех строк на разных языках. Важным отличием этого механизма от редактора в панели свойств, является то, что он выводит содержимое не только на всех языках (а на самом деле кодах языков), которые присутствуют в конфигурации в данный момент, но и всех, встречающихся в строках. Другим важным средством данного механизма является возможность копирования текстов из одного языка в другой. То есть мы можем указать копирование из старого кода языка в новый код, и связь строк с языком будет восстановлена. После чего можно воспользоваться еще одним средством и очистить строки со старым кодом.
Рассмотрим ситуации, когда данная проблема может возникнуть. Наиболее очевидна ситуация, когда у существующего языка (для которого уже определено много строк) меняется код. Однако возникновение ее маловероятно. Как уже указывалось, рекомендуется использовать стандартные значения кодов и в последствии их не менять. Однако есть еще одна, менее очевидная ситуация, связанная с внешними обработками. Внешняя обработка могла быть создана в среде совсем другой конфигурации, где набор языков (или их коды) отличается от набора, используемого в данной конфигурации. При открытии такой обработки все строки будут "утеряны". Описанный механизм позволит решить эту проблему, поскольку он позволяет искать и редактировать строки не только в конфигурации, но и во внешних обработках (как открытых в конфигураторе, так и находящихся в файлах на диске).
Программное формирование строк на разных языках
Если интерфейсную строку требуется сформировать программно, следует воспользоваться функцией НСтр() . Она описана в документации, однако следует указать на необходимость аккуратного соблюдения синтаксиса. Строки для каждого языка могут быть заключены как в одинарные так и в двойные кавычки. Сложности возникают, если эти символы содержаться в самих строках. Рассмотрим, например, строковую константу “ Документ “”” . Она содержит двойную кавычку. При переводе ее в параметр функции НСтр() рекомендуется использовать следующий вариант:
То есть оформить ее в одинарных кавычках. Можно воспользоваться и двойными, но при этом все внутренние двойные кавычки следует удвоить:
Разумеется, подобная константа не очень наглядна (хотя результат будет тот же, что и в предыдущем варианте). Если же "механически" обрамить строку в двойные кавычки:
то получится ошибочный шаблон. Причем, особенность реализации функции НСтр() состоит в том, что ни при синтаксической проверке модулей, ни при исполнении, никакой ошибки выдано не будет. Функция просто вернет пустую строку.
В целом, для редактирования сложных строк, заключенных в НСтр() , надежнее воспользоваться механизмом "Редактирование текстов интерфейса". Однако следует учитывать, что, по умолчанию, поиск НСтр() не производится, для его включения требуется включить соответствующий флажок в диалоге настройки редактирования текстов интерфейса.
Форматирование модулей, содержащих НСтр()
Следует обратить внимание еще на одну особенность работы с НСтр() . Если необходимо сформировать сложную строку как результат нескольких вызовов НСтр() , то рекомендуется располагать эти вызовы на разных строках модуля. Например вместо
Размещение в одной строке модуля нескольких вызовов НСтр может привести к ошибкам работы механизма редактирования текстов интерфейса. Это может выражаться в следующем. При первичном редактировании строк (ручном, или в результате какой-либо групповой операции, например копировании текстов из одного языка в другой) будут правильно обработаны все строки, но при последующем редактировании тексты, соответствующие НСтр() , расположенным не первыми в строке будут недоступны. Для решения этой проблемы достаточно заново произвести поиск интерфейсных текстов, но лучше не допускать возникновения подобной ситуации, и располагать вызовы НСтр() на разных строках.
Эта статья об адаптации программных продуктов под другие рынки. Что же такое локализация приложений, какие есть общие проблемы в этой области и какие есть специфичные проблемы именно 1С платформы.
Пользовательские данные - Разруливаются через "представление ссылки", Можно хранить как в самом объекте, Так и в регистре сведений. Наименования базовых классификаторов аналогично. А с СКД проблема. Язык для макетов без "бубна" не передается.
(1) Язык макета обычно по умолчанию берется из языка интерфейса.
В регистре сведений нельзя. Вернее можно, но потом очень долго из регистра получать для каждой ссылки. Нужно именно в полях объекта.
Представление ссылок в СКД (как и в любых документах и справочниках) будет ровно то, что сформировано в процедуре модуля менеджера ОбработкаПолученияПредставления().
Тут вроде тоже никаких проблем нет.
(2) В регистре сведений преставления получаем через общий модуль со свойством повторное использование получаемых значений - на время сеанса. У меня на 100 человек работает.
(6) Да, согласна.
Тоже хороший вариант.
Повторное использование получаемых значений подходит, должно решать проблемы со скоростью.
Мне кажется, из полей объекта было бы чуть-чуть быстрее, особенно для большого количества данных. Но не принципиально.
Думаю, в данном случае легкость внесения изменений перекрывает другие недостатки.
(19) хе-хе, мы сами создаем эту видимость, что английский нужнее, сами себя ставим в эти рамки.
Достаточно просто начать использовать нормальный международный язык Эсперанто, и остальные подтянутся.
Эсперанто учится месяц по паре часов в день.
Подскажите пожалуйста, а у вас был опыт не локализации, а разработки продукта на базе 1С под другой, не русскоязычный рынок? Была ли возможность сравнить затраты и полученный результат? Интересен полученный опыт, если конечно идея создания своего решения не была пресечена на корню.
(10) Я в основном работаю на украиноязычный рынок.
На самом деле создание продуктов на нероссийские рынки достаточно неэффективно.
У меня есть некоторая статистика по моим мелким продуктам (обработкам, расширениям), размещенным на Инфостарте. Спрос на версии по нероссийским конфигурациям (Украина, Белорусь, Казахстан) это мизер по сравнению со сросом на варианты для российского рынка. На англоязычные как-то совсем спроса пока не вижу.
Как мне кажется, логичнее все-таки адаптировать.
Одна из проблем при внедрении на международном рынке это отсуствие универсальных обработок адаптированных под ситуацию, когда основной язык конфигурации - английский, а также БСП английская. Чаще всего обработки, опубликованные на infostart также требуют допилки.
(11) Да, действительно это отдельная тема.
Тут я бы выделила 3 проблемы.
1. Отсутствие интерфейса. Если мы открываем обработку с языком пользователя, которого нет в обработке, то пользователь видит просто поля без наименований. Обычно решается режимом конфигуратора "Поиск текстов интерфейса" и копированием из русского языка в целевой. В этом случае отображается хотя бы русский интерфейс при открытии в другом языке.
2. Ошибки именно в работе чаще связаны не с англоязычным кодом, а с англоязычным языком платформы.
Например, обработка ожидает, что ошибка будет выглядеть, как "Слишком много фактических параметров". А на самом деле появляется ошибка "Занадто багато фактичних параметрів". В итоге вся логика обработки ломается.
Если речь идет именно о редком использовании администратором, а не постоянном использовании пользователем, то часто проблема решается просто запуском ИБ с русским языком платформы.
3. Есть и проблемы именно связанные языком разработки. Решаются только анализом кода и доработкой. Но их на самом деле все-таки не так много.
Буквально пару месяцев назад с таким сталкивался в одной отраслевой конфигурации, которая ранее успешно прошла сертификацию в 1С. Что бы понять тип переданного параметра (ссылочный или примитивный), от этого параметра получался тип и приводился к строке в нижнем регистре, в которой далее искалось русское слово "ссылка".Поскольку дело происходило в Украине, то параметр ошибочно определялся как не ссылочный и далее алгоритм работал неверно. И такой бред нашел в нескольких местах.
На самый больной мозоль! Спасибо за статью.
Довольно типичная картина для иностранных 1С:Франчайзи. Каждый из нас рано или поздно выбирает какую-то типовую конфигурацию 1С и вкладывается в её адаптацию под свою страну. Положим, 1 год до выпуска полноценного релиза. Затем 1-2 года на то, чтобы потенциальный клиент воспринимал новое предложение как норму. Далее 2-3 года бурного развития и. Всё. В России за эти 5 лет концептуально меняется платформа, конфигурации и локализованная местная уже выглядит на фоне тысяч роликов в ютубе как прошлый век.
Мы месяц назад продали надеюсь последнюю 1С:Бухгалтерия 6.0 с нашими настройками. :-)
Бух77 с нашей написанной с нуля конфигурацией под Эстонию до сих пор пользуется спросом. Свой же ТиС не продаём, но поддерживаем.
Региональный дистрибьютор несколько лет назад предоставил - спасибо ему - типовую Бух8, созданную на основе латышской типовой, в свою очередь созданную на российской Бух 8.1 версии 1.3, по-моему.
1С считает эту конфигурацию региональной типовой со всеми вытекающими, что не способствует возникновению новой, на уровне всё-таки современных технологий.
В итоге что имеем. Конфигурации 1С в других странах всегда будут отставать от российских типовых. Вкладывать столько средств в развитие конфигураций, как этом может себе позволить 1С, не сможет ни один франчайзи, сколько бы у него в своём государстве ни было клиентов. В результате, даже по сравнению со ПО своей матери, ПО дочек всегда будет в хвосте и в некоторых случаях даже работать против репутации 1С. Пока не появятся универсальные конфигурации, о которых Вы говорите в начале статьи. Интернационализация на уровне исходного кода.
1С:Drive - шанс получить одну единственную конфигурацию, которая силами 1С будет поддерживаться в актуальном по технологиям состоянии. Это несколько другой подход. И отдельная тема.
(14) Да. В этом и смысл.
В идеале нужна универсальная Интернациональная конфигурация, из которой при адаптации хотя бы не нужно ничего вырезать. При локализации нужно будет только добавить свои дополнительные документы, налоги, отчеты.
А следующая итерация должна быть не новой конфигурацией на основе актуальной российской типовой. А обновлением интернациональной на новые стандарты платформы. Чтобы для адаптации нужно было просто накатить сверху свои изменения сделанные для старой редакции и адаптировать их к новым стандартам платформы.
Но на самом деле это дикий объем работы. Поэтому не знаю, придём ли к такой идеологии.
Достаточно давно сталкиваюсь с задачами локализации учетных систем. Когда-то занималась адаптацией под другие страны ЕРП-системы ИТ-Предприятие, последние годы занимаюсь этим же с продуктами на платформе 1С. За время работы в голове накопился некоторый объем информации по этой теме и полезно будет эту информацию структурировать, чтобы взглянуть на нее более обобщенно.
Для начала рассмотрим основную терминологию. Что такое локализация, интернационализация и глобализация, зачем они нужны.
1. Адаптация приложений как Интернационализация (удаление особенностей) и Локализация (добавление особенностей)
В общем случае локализация приложения это лишь часть процесса адаптации его под другие территориальные рынки, т.е. под рынки других стран.
В соответствии с терминологией, используемой Ассоциацией по стандартам в области локализации (Localization Industry Standards Association или LISA), адаптация приложения начинается с Интернационализации (от англ. Internationalisation). Под Интернационализацией подразумевается удаление из продукта национальных особенностей. Для учетных систем к этому можно отнести вынесение национальной информации (ставок НДС, статей движения денежных средств, единиц измерений) из кода в пользовательскую информацию (справочники): создание более универсальных документов, которые проще потом адаптировать.
Второй этап адаптации это Локализации (от англ. Localisation). Это непосредственная адаптация продукта к конкретному рынку. Доработка под учет национальных особенностей (законодательства, документооборота). Также к Локализации относится перевод приложения на местный язык. Интернационализация выполняется для продукта один раз, локализация для каждого региона, для которого будет использоваться продукт. Чем качественнее выполнена интернационализация, тем проще локализация.
Интернационализация и Локализация вместе представляют из себя процесс Глобализации.
Глобализовать — означает заранее продумать проект и методы продвижения продукта, учитывая многонациональную аудиторию, чтобы избежать увеличения стоимости и проблем, связанных с качеством, а также сэкономить время и уменьшить объём усилий, затраченных на локализацию в каждой стране и регионе.
В идеале Глобализация не линейный, а циклический процесс. Каждый виток цикла это новая редакция продукта. Изменения, сделанные на этапе Интернационализации и Локализации постепенно включаются в основной продукт, упрощая следующие итерации.
Применительно к 1С цикл глобализации очень условно можно рассмотреть на примере адаптации УНФ к европейскому рынку.
Конфигурация УНФ это исходный продукт. К Итернационализации можно отнести разработку на его основе продуктов SmallBusiness и SimpleERP (она же 1C:Drive). На этом этапе мы создаем из ориентированного на русскоязычную аудиторию продукта более универсальный вариант. А Локализация это разработка на их основе отдельных конфигураций для Болгарии, Германии, Литвы и других стран. Один виток цикла глобализации это одна редакция УНФ, адаптированная для Европы.
Для многих универсальных приложений (Photoshop, Total Commander) адаптация достаточно простой процесс. Он заключается в переводе интерфейса. Нам в это плане не повезло. Большинство приложений на 1С это учетные системы. А учетные системы очень сильно зависят от региональных стандартов. Рассмотрим, что включает в себя адаптация учетных приложения под рынок другой страны.
2. Подходы к адаптации.
2.1. Адаптации средствами настройки в режиме пользователя
Для начала рассмотрим адаптацию логики работы приложений. Это основная и наиболее сложная задача в локализации. Фактически 80% работ по локализации это именно переработки логики работы приложения. И лишь 20% времени это перевод текстов.
С задачами адаптация приложений лично я первый раз столкнулась лет пятнадцать назад. В это время я работала с ERP-системой ИТ-Предприятие. Изначально данная система была разработана под украинские стандарты учета. Неожиданно оказалось, что в России есть шикарный платежеспособный рынок и её можно продавать и там. Есть несколько вариантов адаптации приложений под рынки других стран. Для ИТ-Предприятия изначально был выбран подход, предусматривающий максимальную Интернационализацию на уровне исходного кода. И последующую Локализацию на уровне пользовательских настроек. Это способ проектирования, при котором возможность мягкой настройки под особенности учета заложена изначально. В данном подходе национально-зависимая часть отделена от каркаса приложения и может изменяться под задачи заказчика без изменения ядра системы. В ИТ-Предприятии каркас системы не зависит от страны использования. Вся национально-зависимая логика (перечень документов, взаимосвязи документов, классификаторы, ставки налогов и НДС . ) не встроена в каркас приложения, а поставляется в виде данных системных таблиц. Все отчеты для подачи в государственные органы настраиваются конструктором и поставляются в виде настроек, а не вшиты.
Соответственно, адаптация под региональные стандарты заключается в настройке системы в режиме пользователя, без влезания в код.
Примечание: на самом деле, последние лет 8 я не сталкивалась с этой системой и вполне возможно, что архитектура полностью поменялась. Всё, что написано тут и далее касается достаточно старого периода и используется исключительно для иллюстрации подходов к разработке.
2.2. Создание отдельных версий продукта.
Когда я начинала работать с 1С, то изначально я ожидала чего-то похожего и при адаптации 1С-продуктов. Реальность оказалась несколько иной. В 1С-решениях очень жесткая привязка к региональным стандартам именно в коде. Соответственно, для локализации используется другой подход. Условно его можно назвать, как "отдельная версия" каждого продукта под каждую страну. Так уж сложилось, что почти любое решение разрабатывается изначально под российский учет. А партнёры в каждой стране создают свою версию конфигурации на базе российского варианта. Основной проблемой такого подхода является большая трудоёмкость. Локализованные приложения очень сильно отстают по срокам выпуска исходного продукта. Часто на года.
Собственно, "Глобализация" и "Отдельные версии" это две совершенно разные концепции адаптации приложений. Они относятся не только в локализации, но и к адаптации под особенности учета конкретного предприятия.
Нельзя сказать, какой из этих подходов лучше. В каждом случае есть свои преимущества и недостатки. Попробуем их систематизировать.
Простота адаптации под другие рынки
Сложность начальной разработки гораздо выше у интернационального решения. Это несколько другой и более сложный уровень абстракции. Схема вынесения национальной логики работы за пределы кода гораздо более сложная, чем просто прописать всё на этапе разработки. Зато адаптировать решение гораздо быстрее и дешевле, если в нём изначально национальные особенности выделены за пределы кода. Но и возможности такой адаптации в виде настроек гораздо ниже, чем адаптация в варианте разработке отдельных версий. Обновления проще выполнять на интернациональном решении, так как в нём национальный код не зависит от ядра и его не требуется изменять при обновлениях конфигурации. Для 1С-решений обновление национального решения на новую редакцию очень трудоемкий процесс. Фактически для обновления локализованного решения с УТ11.2 на УТ11.3 нет смысла вносить изменения в локализованную версию. Проще взять 11.3 и локализовать ее заново с нуля, используя выполненные ранее наработки.
Скорость работы выше у "отдельных версий". Просто потому, что при вынесении логики работы в отдельные справочники требуется дополнительное время на определение этой логики при выполнении. Кроме того, при описание вычислений в виде исходного кода, а не обобщенных алгоритмов, можно получить более оптимальную конструкцию, выполняющуюся быстрее.
Обычно "Глобализация" и "Отдельные версии" не встречаются в чистом виде. 1С решения, на самом деле, тоже не совсем независимые версии. Есть промежуточное ядро платформы, общее для всех конфигураций. Соответственно, это ядро сильно упрощает разработку, но дает потери в скорости, по сравнению с прямой разработкой учетной системы, например, на Java или популярных ранее FoxPro или Delphi.
Для предприятий, переходящих с самописных программ учета на 1С, достаточно неприятным фактом является потеря в скорости работы. Это цена, которые мы платим за простоту разработку и универсальность.
Очень условно разные системы учета по степени вынесения настроек за пределы кода можно расположить следующим образом.
Чем правее на данной оси расположена система, тем более она универсальна и проста для адаптации.
3. Что именно адаптируем:
3.1. Логика работы приложения.
Что именно дорабатывается при локализации логики работы приложения? Для 1С решений к основным направлениям можно отнести:
- Документооборот предприятия. В разных странах банально разный набор требуемых документов. Особенно это относится к налоговым документам. Поэтому при локализации некоторые документы удаляются (например, российская счет-фактура), другие создаются заново с нуля. Меняется порядок ввода документов и их взаимодействие.
- Учет налогов. К сожалению, налоговая система везде разная. Начиная от ставок НДС и подоходного налога, заканчивая логикой расчета данных налогов.
- Отчетность. В каждой стране свой утвержденный законодательством набор отчетных форм.
- Учет кадров и расчет ЗП ну совершенно разный идеологически и обычно требует глобальной переработки.
- Торговое оборудование. К сожалению, торговое оборудование также везде разное. Разные драйвера, логика работы, порядок взаимодействия с учетными системами.
- Разный набор веб-сервисов, с которыми должна интегрироваться учетная система. Например, используемые в России ЕГАИС и Меркурий в других странах нафиг не нужны и их приходится аккуратно удалять из конфигурации, чтобы не путать пользователя.
- Классификаторы. Сюда можно отнести классификаторы единиц измерений, статей налоговых декларации, виды начислений и удержаний при расчете ЗП. При чем в большинстве случаев речь именно о разной структуре и логике использования классификаторов.
Все эти вещи в 1С архитектуре требуют именно изменения исходного кода и не решаются универсально. Тут очень сильная зависимость от рынка, для которого выполняется адаптация. Так что подробно описывать нет смысла.
3.2. Перевод интерфейса пользователя.
Вторым основным направлением локализации является перевод приложения на язык того региона, для которого выполняется адаптация.
Есть несколько вариантов многоязычности программных продуктов. Условно их можно разделить на:
- Встраивание нескольких языков одновременно в исходный код программного продукта. Именно этот подход используется для 1С приложений. Если мы выпускаем многоязычную конфигурацию, то все поддерживаемые языки изначально встроены и добавить убрать что-то в режиме пользователя нельзя.
- Отдельный набор файлов продукта для каждого языка. Такая схема используется, например, в ИТ-Предприятии. При разработке логики работы в исходном коде используются только русскоязычные тексты. При сборке готового программного продукта русские тексты меняются на другие языки и собирается несколько наборов исходных файлов. Отдельный для каждого языка.
- Отдельные файлы с текстами переводов. Достаточно популярный подход, при котором дополнительные языки поставляются в виде отдельных текстовых папочек. Такой подход часто используется в небольших программных продуктах, скриптах, многих опенсорс решениях.
Реализация полноценной многоязычности программного продукта на самом деле достаточно сложная техническая задача. И в 1С, на мой взгляд, она реализована очень хорошо именно средствами платформы. Разные языки платформы, любые языки интерфейса, поддержка национальных дат и чисел, интернационализация на строенном языке. И даже возможность писать код на двух языках. На самом деле это просто огромный пласт работы, выполненный за нас. Нам не нужно задумываться о выводе текстов в разные режимах, об анализе настроек пользователей. Всё это делает платформа. Наша задача как разработчиков сводится к простому вписыванию нужных текстов в конкретные поля конструктора.
3.2. Сложности при переводе интерфейсов.
Хотя, конечно, многого в платформе и не хватает. Например, при использовании многоязычных html-шаблонов невозможно в режиме предприятия получить текст шаблона, отличающийся от языка интерфейса пользователя. Так же нельзя получить синонимы метаданных, отличающиеся от языка интерфейса.
Нет возможности сделать многоязычные картинки, которые отображались бы в зависимости о языка интерфейса. В результате, для встречающихся в интерфейсе картинок, имеющих текст, приходится заводить новые отдельные картинки предусматривать в коде вывод разных картинок в зависимости от используемого языка.
Текущие проблемы локализации конечно есть. Но большинство из них универсальны для любых продуктов, не только 1С.
Из основных сложностей можно выделить:
Разумеется, все эти проблемы решаются. На текущий момент разработка многоязычного интерфейса 1С уже достаточно понятный, хоть и долгий процесс.
3.3.Работа с многоязычными данными.
Из нерешенных сейчас полноценно задач хотелось бы отметить хранение в базе многоязычных данных. Это необходимо при одновременной работе в системе пользователей с разными языками интерфейса.
В идеале хотелось бы дойти до варианта, при котором каждый пользователь работает полноценно на своем языке.
Статичный интерфейс перевести просто. Сложности начинаются в случае, если нам нужно поддерживать актуальными многоязычные данные. К таким данным относятся.
- Интерфейсные данные. Т.е. данные об интерфейсе, хранящиеся в справочниках и отображаемые пользователю. Примером таких данных можно назвать механизм "Варианты отчетов". Данный механизм позволяет пользователю самостоятельно настраивать, какие отчеты отображать в интерфейсе и как их назвать. Проблема в том, что текущая реализация БСП подразумевает хранение данных только на одном языке. Поэтому наименования и описание отчетов отображаются для всех пользователей на одном и том же языке.
- Данные классификаторов. Единицы измерения, справочники, валюты. Всё это логично отображать пользователю на его интерфейсе.
- Пользовательские данные. Наименование номенклатуры, должностей, подразделения, статьи доходов и расходов.
В целом на текущий момент технически ничего не мешает нам хранить и отображать все данные в многоязычном формате. Для этого достаточно добавить в каждый справочник поля по количеству языков. Мы даже можем отображать во всех формах данные именно на том языке, который удобен пользователю. С текущими возможностями расширений для этого даже не нужно вносить изменения в конфигурацию, достаточно создать расширение с новыми полями и правилами формирования наименований.
Проблема в том, кто будет каждый раз выполнять перевод данных. Ведь если мы меняем данные на одном языке, то логично изменить и перевод на другой язык Можно, конечно, переводить автоматически при сохранении или вручную. Но в таком случае очень вероятны со временем совершенно левые данные на втором (неосновном) языке.
В целом можно сказать, что на текущий момент адаптация конфигураций на 1С это все-таки в основном не техническая проблема платформы, а проблема архитектуры флагманских решений. В наиболее популярных продуктах (ЕРП, УТ, УНФ, БП) настолько жесткая завязка на российский учет, что адаптация каждой новой редакции это почти адаптация с нуля. Надеюсь, со временем это все-таки изменится, и решения будут изначально разрабатываться более интернациональными.
С самого начала, с момента, когда Вы, решили установить платформу 1С Предприятие 8.3 возможно сразу же установить несколько языков конфигурации. В основном ставят русский и региональный язык страны, в которой владелец продукта находится.
Следующий момент, когда необходимо обращать внимание на локализацию – это установка языка пользователю. Когда добавляют нового пользователя в 1С, ему можно установить один из языков системы. Количество языков для нового пользователя 1С определяется общим объектом конфигурации «Язык». В этот объект разработчик может сам добавлять необходимые языки или они добавятся автоматически, (если было установлено несколько языков платформы).
В основном несколько языков используется в случае, если компания работает не только в рамках своей страны (от 2 и более языков) или когда пользователи владеют несколькими языками. Ситуации бывают разные, как и разные варианты локализации 1С.
Также следует обратить внимание на преобразование дат и чисел в тот формат, который соответствует региону использования. Для этого используется метод глобального типа «Формат» или, когда необходимо создать строку на нескольких языках, используется функция «Нстр()». Существует много инструментов для перевода данных программного продукта на необходимый язык.
2. Локализация в процессе разработки нового объекта 1С
Также при разработке нового объекта в 1С необходимо учитывать, что вывод этого объекта будет происходить на другом языке и для корректного вывода в любом языке, необходимо заполнять синонимы реквизитов на всех языках системы.
Также при разработке в 1С макетов для печати или отчетов, которые используют табличный документ необходимо учитывать, что они могут выводиться на нескольких языках, то есть необходимо реализовывать текст этих объектов на нескольких языках, что конечно, занимает определенное время при разработке.
Существует много инструментов, встроенных в информационную базу, которые помогают легко и без особых сложностей перевести текст с одного языка на другой.
Сейчас также существует специальный программный продукт 1С, который предназначен именно для перевода документации с одного языка на другой – «1С:Переводчик».
Хочется отметить, что помимо всего вышеуказанного, также существует локализация логики работы продукта и адаптация под определенный регион использования, о чем мы поговорим в будущих статьях.
Специалист компании ООО «Кодерлайн»
Мороз Олег Игоревич
Вас могут заинтересовать следующие статьи:
С самого начала, с момента, когда Вы, решили установить платформу 1С Предприятие 8.3 возможно сразу же установить несколько языков конфигурации. В основном ставят русский и региональный язык страны, в которой владелец продукта находится.
Следующий момент, когда необходимо обращать внимание на локализацию – это установка языка пользователю. Когда добавляют нового пользователя в 1С, ему можно установить один из языков системы. Количество языков для нового пользователя 1С определяется общим объектом конфигурации «Язык». В этот объект разработчик может сам добавлять необходимые языки или они добавятся автоматически, (если было установлено несколько языков платформы).
В основном несколько языков используется в случае, если компания работает не только в рамках своей страны (от 2 и более языков) или когда пользователи владеют несколькими языками. Ситуации бывают разные, как и разные варианты локализации 1С.
Также следует обратить внимание на преобразование дат и чисел в тот формат, который соответствует региону использования. Для этого используется метод глобального типа «Формат» или, когда необходимо создать строку на нескольких языках, используется функция «Нстр()». Существует много инструментов для перевода данных программного продукта на необходимый язык.
2. Локализация в процессе разработки нового объекта 1С
Также при разработке нового объекта в 1С необходимо учитывать, что вывод этого объекта будет происходить на другом языке и для корректного вывода в любом языке, необходимо заполнять синонимы реквизитов на всех языках системы.
Также при разработке в 1С макетов для печати или отчетов, которые используют табличный документ необходимо учитывать, что они могут выводиться на нескольких языках, то есть необходимо реализовывать текст этих объектов на нескольких языках, что конечно, занимает определенное время при разработке.
Существует много инструментов, встроенных в информационную базу, которые помогают легко и без особых сложностей перевести текст с одного языка на другой.
Сейчас также существует специальный программный продукт 1С, который предназначен именно для перевода документации с одного языка на другой – «1С:Переводчик».
Хочется отметить, что помимо всего вышеуказанного, также существует локализация логики работы продукта и адаптация под определенный регион использования, о чем мы поговорим в будущих статьях.
Специалист компании ООО «Кодерлайн»
Мороз Олег Игоревич
Вас могут заинтересовать следующие статьи:
Читайте также: