1с для чего применяется код локации

Обновлено: 07.07.2024

Достаточно давно сталкиваюсь с задачами локализации учетных систем. Когда-то занималась адаптацией под другие страны ЕРП-системы ИТ-Предприятие, последние годы занимаюсь этим же с продуктами на платформе 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С.

И ведь думаешь, что знаешь эту "1Ску" как свои пять пальцев, но стоит случайно копнуть глубже. И очередная багофича. Да ешё и какая!

В этой статье рассмотрим секретный оператор ?

О нём мало кто знает, хоть он и существует как минимум с версии 8.0.

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

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

Код успешно выполнился. Удивительно, но сработало! И тут меня понесло.

Как оказалось, знак ? ведёт себя крайне странно. Давайте посмотрим ещё раз прошлый пример.

Мы создаём новую переменную и назначаем ей значение - ?. И в переменной находится Неопределенно. И, казалось бы, это и есть ответ на вопрос. Знак ? означает Неопределено.

Но что же тогда это:

В данном коде сначала идёт объявление переменной "А". И в А установлено числовое значение "1". А далее идёт наше сравнение с ?. Если бы под знаком вопроса скрывалось Неопределено, то мы бы не попали внутрь условия. А по скрину видно, что попали.

Очень странная ошибка. "Переменная не определена (Сообщить)". Ну допустим. Добавим тогда такую переменную:

Данный код компилируется без ошибок. И при выполнении в 1С сообщает "ТЕСТ". То есть значение переменной Сообщить

Выходит, что символ ? указывает на предыдущее слово в коде. В данном случае, перед ? было слово Сообщить. И поэтому 1С изначально поругалась, что такая переменная не определена. А когда мы добавили переменную Сообщить, то всё стало на свои места.

То есть наш код для 1С выглядит так:

А теперь вернемся к нашим предыдущим примерам и разберём что и как сработало.

В данном коде предыдущее слово перед ? - Если. Но оно является ключевым для 1С. Как "Цикл", "Процедура" и так далее. Поэтому, его оператор ? не учитывает и берет в качестве источника значения переменную А.

Скорректируем же этот код так, как его видит 1С:

Теперь всё логично. А = А и поэтому условие выполняется.

А что с нашим самым первым примером?

На самом деле всё так же. Просто заменяем знак вопроса на предыдущее слово.

Да, такой код тоже странный, но в рамках 1С всё логично. Сначала объявляется переменная и в ней Неопределено. А затем происходит присвоение переменной значения из её самой. То есть опять же Неопределено. Можете проверить такой код - это хоть и выглядит странно, но работает. А почитать чуть подробнее можно в статье на ИТС: МояПеременная = 0; МояПеременная = ? + 1; //1 МояПеременная = ? + 1; //2 МояПеременная = ? * 5; //10 МояПеременная = ? / 2; //5 МояПеременная = ? - 6; //-1

А самое интересное, что такая возможность существовала как минимум ещё с версии 8.0 . Специально скачал старую платформу и проверил.

На самом деле такой код можно ещё упросить:

Но такой вариант становится менее надежным. Ведь всё работает до тех пор, пока перед ? находится МояПеременная. Если же вставить после этого какое-то другое "слово", то всё порушится.

Но вот ещё пример:

Мы же помним, что знак ? берет предыдущее слово. Так вот в нашей строке кода это слово "А". Именно так - без "Структура".

Поэтому 1С в таком коде вместо знака вопроса вставит "А"

Но зато появляется новая возможность применения:

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

А вот ещё пример. Можно передать в какой-то метод или конструктор одно значение несколько раз:

Передавать знак ? можно даже в условный тернарный оператор. Например, этот код приводит отрицательные числа к 0:

А этот приводит отрицательные числа к положительным:

Подобным образом можно присваивать дефолтные значения необязательным параметрам:

Главное помнить, что знак ? берет именно предыдущее слово, поэтому вот так работать НЕ будет:

1С поругается, что Переменная не определена (Структура). Ведь перед последним знаком ? слово Структура

Но что если использовать символ ? в параметрах?

Сделаем процедуру с параметром ? :

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

Но мы можем сделать его необязательным:

И параметр не обязан быть единственным. Можно делать разными способами:

А можно использовать Знач

Но вот незадача, ? в параметре метода не использует предыдущее слово (как во всех других случаях). Как обратиться к этому параметру - неизвестно.

В стеке вызовов он отображается:

А попробуем добавить второй параметр ?

1С ругается так:

Формальный параметр с указанным именем уже определен (?)

Опираясь на текст ошибки, мы можем предположить, что 1С объявляет параметр с именем "?"

И когда мы пытаемся добавить ещё один такой параметр, то платформа ругается.

Как обратиться к параметру с именем "?" - неизвестно. Методы Вычислить() и Выполнить() не помогли.

Но, возможно, это всё те вопросы, которые нам ещё предстоит разгадать. Секреты и загадки этой таинственной платформы под кодовым названием 1С.

Понравилась статья?

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

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

Языки

Языки в 1С:Предприятии 8.0 предназначены для создания интерфейса прикладного решения на различных языках. В конфигурации может быть определено необходимое количество различных языков:

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

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

Редактирование текстов интерфейса

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

Существует возможность указания области прикладного решения, в которой должен выполняться поиск:

Поиск можно производить по всему прикладному решению, во внешних файлах, в открытых документах или в отдельных элементах прикладного решения, например, в форме обработки:

Результат поиска представляется в виде списка, содержащего расположение найденного текста и его значение на различных языках. Для удобства просмотра, этот список может быть свернут по значениям, совпадающим для всех языков или для одного выбранного языка:

По щелчку мыши возможен переход к элементу прикладного решения, содержащему найденную строку; кроме того, изменение значения строк возможно прямо в этом списке:

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

Читайте также: