Проблемы локализации типовых конфигураций в странах ближнего зарубежья

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

Повторить путь разработки в РФ не получится из-за нехватки ресурсов

Для начала вспомним, как разрабатываются типовые конфигурации 1С для российского рынка.

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

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

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

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

Если попытаться представить некий идеальный путь развития 1С за рубежом, то можно было бы нарисовать в своем воображении картину, схожую с той, что мы видим сейчас в РФ – некий большой вендор полностью посвящает свою работу разработке типовых конфигураций для нашего рынка, с каждым релизом совершенствуя и отшлифовывая свой продукт. В идеале это самобытные, полностью самостоятельные конфигурации (ну разве что опирающиеся на БСП), разработанные по всем стандартам фирмы 1С. Разумеется, с интерфейсом на местном языке. Периодически, так же, как и в РФ, после долгого и тщательного тестирования, эти конфигурации обновляются на новые релизы, чтобы всегда оставаться актуальными современному законодательству.

Красиво. Но пора бы и просыпаться. В наших краях таких вендоров нет. Просто потому, что нет ресурсов – ни финансовых, ни - что может даже важнее – кадровых, которые бы позволили проворачивать такие объемы качественной работы. В РФ у 1С есть накопленный десятилетиями опыт, подкрепленный наличием профессионалов высокого уровня. Масштабы наших возможностей несопоставимы.

Как создать продукт для местного рынка?

Что ж, в таком случае мечту нужно уменьшать, сокращать, обрезать. На ум приходит несколько вариантов:

Вариант 1: своя маленькая, но полностью локализованная конфигурация.

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

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

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

б) низкое качество разработки – про стандарты разработки в местных краях если что и слышали, то особо и не вдумывались. К большому сожалению, большинство местных разработчиков работает по принципу «работает и слава богу». 

в) потерю энтузиазма (читай финансирования)     

Вариант 2: модуль для ERP WE.

Если гора не идет к Магомеду, то Магомед идет к горе. Так, видимо, решили в 1С. Фирма 1С пошла навстречу всем зарубежным локализаторам, вырезав из своего флагманского продукта все, что связано с российским законодательством. Конфигурация уже переведена на английский язык. Наша же задача в таком случае ограничивается тем, чтобы под эту конфигурацию разработать собственный кадровый и зарплатный модуль, а также адаптировать прочую законодательную специфику.

Но тоже нет. Почему? Дело в том, что подавляющему большинству клиентов на местном рынке не нужен дорогостоящий ERP. Им вполне будет достаточно конфигураций уровня КА и УНФ. Да и сама фирма 1С позволяет продавать конфигурацию ERP далеко не всем франчайзи – они больше нацелены на дальнее зарубежье. Кроме того, никуда не пропадает задача перевода конфигурации на местный язык, а значит снимать конфигурацию с поддержки все равно придется.  

«А есть третий вариант, он самый интересный…»

Остается последний вариант, де-факто ставший традиционным для местных локализаторов – это локализация российской конфигурации под местный рынок.

Разберем его поподробнее.

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

Российское законодательство в сфере зарплаты имеет черты очень похожие на законодательства стран ближнего зарубежья. Кроме того, типовые конфигурации уже включают в себя универсальные механизмы кадрового и зарплатного учета, выполненные максимально качественно. Скажем, нам, как локализаторам, не нужно будет изобретать велосипед, создавая заново документы приема на работу, начальной штатной расстановки, кадровых переводов, табелей, индивидуальных графиков, отражения в фин. учете и т.д. и т.п. Это сокращает объем работы просто в разы. Нужно лишь их слегка «пофиксить» - отключить что-то ненужное, пришить что-то нужное, что-то посчитать по-другому и т.д. И вуаля – после такой пластической хирургии мы получаем продукт для местного рынка.

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

Этот путь внедрения 1С на местные рынки кажется путем наименьшего сопротивления. Дешевый и, казалось бы, простой в реализации. Но важно даже не то, что думаем мы, а что думает сама фирма 1С – именно этот способ локализации она и взяла на вооружение при адаптации своих конфигураций в странах ближнего зарубежья. Если кто не знает, то 1С сама заказывает локализацию своих российских конфигураций у местных франчайзи. Те берут российские конфигурации, адаптируют существующие в них механизмы под свое законодательство, переводят их на местные языки, после чего переименовывают их и публикуют как самостоятельные конфигурации на сайте релизов 1С.

Казалось бы, что может быть проще? И действительно, в грамотных руках задача кажется не такой сложной. Но реальность такова, что сложность типовых российских конфигураций возросла многократно, а разрыв в качестве разработки в РФ и в странах ближнего зарубежья остается довольно существенным, в результате чего даже такая упрощенная, на первый взгляд, задача оказывается затруднительной для местных локализаторов. Кроме того, сам такой подход к локализации российских продуктов несет в себе ряд архитектурных ограничений, которые в результате приводят к торможению развития 1С за пределами РФ.

Ниже разберем подробнее подводные камни локализации.

Как организован процесс локализации?

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

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

• Перевод интерфейсов
• Изменение плана счетов
• Учета зарплаты
• Учет НДС
• ОС и НМА
• Какие-то местные особенности, типа WHT
• Локализация вспомогательных инструментов: типа классификатора местных банков или загрузка курсов валют и т.д.

Здесь уже заложена проблема, связанная с тем, что ТЗ мы готовим своими силами. У нас нет круглого стола или какого бы то ни было контакта с представителями налоговых и прочих госструктур, которые дали бы нам четкие инструкции и требования к конечному продукту. Отсутствие единого источника для консультаций в итоге выливается в разную трактовку законодательства. Но пока оставим эту проблему за скобками.

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

В общем, все так же, как и всегда. Так же, как и тогда, когда мы локализировали текущую нашу локализованную конфигурацию, которую мы с горем пополам внедряли у клиентов.

Фиксация версии – скрытая причина отставания на годы

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

Такой подход оправдан, если мы говорим про полностью автономный продукт. Но для локализации, которая по сути является лишь корректировкой типовой российской конфигурации, такой подход приводит к технологическому отставанию на годы. Дело в том, что локализация дорого обходится бизнесу, этот процесс компания может позволить себе в лучшем случае раз в несколько лет, а как правило вообще раз в десятилетие. Поэтому та «свежая» конфигурация, на которой мы сейчас приступаем к локализации, будет с нами (если, конечно, повезет) еще долгие годы. За это время 1С в той же конфигурации успеет исправить тысячу ошибок, добавить множество интересного функционала, поднять режим совместимости для работы на новейших платформах с новыми интересными решениями и даже выпустить новый интерфейс на 8.5, а мы словно застынем во времени – для нас время остановится на этой точке, когда мы приступили к локализации.

Решение кажется очевидным - расширение. Сегодня с помощью технологий расширения можно реализовать если не все виды доработок, то очень и очень многие. Кроме того, расширение легче поддерживать небольшой команде разработчиков, для него легче настроить пайплайны CI/CD. Легче контролировать качество работы и проще отслеживать модули, в которых были выполнены доработки – всегда можно отличить типовой код от локализованного. Не стоит, однако, забывать, что доработка с помощью расширений требует определенной дисциплины в команде разработки. Например, не стоит вносить изменения в заимстовованные формы и т.д.

Если вдуматься, то еще даже до развития расширений локализацию можно было бы выполнить с помощью отдельного cf-файла, который можно было бы сравнить/объединить с типовой конфигурацией.

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

Однако есть куда большая проблема – перевод. Выполнить перевод конфигурации средствами расширения на сегодняшний день практически невозможно. Не будем же мы переносить абсолютно все объекты в расширение? Конечно, нет, а значит так или иначе вносить изменения в российскую конфигурацию и снимать ее с замка все же придется.

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

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

ИИ облегчил задачу перевода интерфейсов

Раньше, в те далекие и прекрасные времена, когда конфигурации 1С были сравнительно небольшими (например, конфигурации на 7.7 или даже еще на УПП 1.3) – перевести их интерфейс на местный язык своими силами было вполне реально. Да, работы было много, но назвать ее невозможной было нельзя.

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

Где найти таких специалистов? Успеют ли они выполнить работу в срок? Позволит ли бюджет оплатить их труд? Ответ: нет, нет и еще раз нет.

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

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

Конечно, остались и подводные камни. Например, далеко не все тексты конфигурации нужно переводить – многие из текстов это служебные идентификаторы, при переводе которых конфигурация ломается. Кроме того, промпты нужно писать так, чтобы ИИ не начал в определенный момент глючить – он может некорректно переводить аббревиатуры или же упустить что-то в форматированных строках. Без ручного вмешательства, однако, все равно не обойдется – в некоторых случаях в зависимости от контекста одно и то же русское слово на местный язык нужно перевести по-разному. ИИ без знания контекста решить такую задачу, конечно, не сможет. Вдобавок, ИИ может совершить ошибки в строках методов а-ля ЧислоПрописью и других.

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

Локализация – это как пластическая хирургия

Теперь обсудим непосредственно разработку.

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

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

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

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

Это очень интересный нюанс, потому что в результате наша работа, по большей части, сводится не к разработке, а именно к «фиксингу»

Мы должны изучить существующие документы, формируемые ими движения и в целом всю текущую логику процессов, а затем откорректировать ее так, чтобы она продолжила работать, но уже соответствуя нашим требованиям. Задача, на самом деле, совсем нетривиальная, так как она заставляет нас погружаться при изучении кодовой базы в самые дебри конфигурации. Позже, общаясь с российскими коллегами по цеху, даже с достаточно опытными из них, мы с удивлением узнаем о том, что они сами никогда в эти модули не заходили и не знают о том, как они работают. А для нас это база – нас ночью разбуди, мы скажем в какой процедуре обработки «Менеджер расчета зарплаты» рассчитываются удержания по произвольной формуле.

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

Приведу один пример - НДФЛ. В местном законодательстве, так же, как и в российском, есть понятие подоходного налога. Тоже есть личные вычеты и т.д. Отличается лишь сам расчет. Соблазн большинства локализаторов – просто найти ту строчку кода, где выполняется расчет НДФЛ и внести в нее соответствующие изменения. В результате, локализаторы находят эту строчку, вносят в нее изменения, проверяют на одном месяце и считают дело закрытым, совершенно упуская из вида то, что в РФ есть понятие нарастающего итога, которого у нас нет. В следующем месяце проблема обнаруживается, и в ту же процедуру вносятся корректировочные изменения. Потом оказывается, что удержания в межрасчетный период у нас учитываются иначе. Вносятся еще изменения. А потом еще, и еще. А все потому, что упускается из виду главное - сама процедура расчета НДФЛ от и до нам совершенно не подходит. Ее нужно полностью заменить своей – по-своему находить облагаемую базу, по-своему ее рассчитывать и так далее. И такие ситуации при локализации возникают сплошь и рядом. И нигде нет инструкции, которая объяснит, как лучше поступить в той или иной ситуации, какую стратегию применить.

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

Низкое качество разработки

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

Правильно – вы получите сырой, недоделанный продукт.

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

Это проблема не какой-то частной компании, а всего местного рынка 1С в целом – высококвалифицированных специалистов катастрофически мало. У нас нет курсов по 1С для школьников или кафедры 1С в местных университетах, как это есть в России. Только практика в фирмах франчайзи. Хорошо если местные университеты в принципе смогут подготовить более-менее успешные кадры в целом в сфере программирования – не важно на каком стеке технологий. Нет материалов по 1С на местном языке (или хотя бы на английском), что тоже отсекает большой слой потенциальных будущих 1С-ников. Учиться людям приходится уже на работе, где их, как правило, сразу после небольшого периода обучения бросают на реальные проекты.

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

А каком-то движе 1С-ников в местных края и вовсе говорить не приходится. Мы только с завистью можем смотреть на то, как в РФ проходят конференции Инфостарта или собрания «Желтого клуба». В наших широтах никакого обмена опытом между участниками сообщества разработчиков 1С не происходит вовсе.

В такой инертной среде не происходит никаких сподвижек для роста качества продукции. Новые инструменты внедряются очень медленно. CI/CD, о котором там много разговоров на конференциях в РФ, здесь просто не существует. В результате все это отражается на качестве работы. В том числе и качестве локализации.

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

Попытки создать собственные локализации

Низкое качество официальных локализированных продуктов побуждает другие местные компании (и франчайзи, и инхаус) пойти на то, чтобы создать свои собственные версии локализаций. Каждая из таких попыток, однако, спотыкается о те же грабли – то же низкое качество, та же фиксация версий, тот же сырой перевод.

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

Более того, даже официальные конфигурации 1С могут быть локализованы по-разному. Скажем, расчет заработной платы сотрудников в конфигурации КА может быть реализован одним образом, а в конфигурации ЗУП, от того же, казалось бы, поставщика, совершенно иначе. Это говорит о непоследовательности при подходе к локализации конфигураций.

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

Имиджевые потери для 1С

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

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

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

Но, если вдуматься, в ближнем зарубежье ситуация для 1С тоже непростая. Здесь есть крупные клиенты, с многомиллионными оборотами, которые тоже хотят получить качественный продукт, и за который они платят немалые деньги, особенно если мы говорим о продуктах уровня ERP. Но сырая локализация, которая не позволяет воспользоваться из коробки, казалось бы, базовым функционалом, в результате приводит к фиаско при внедрении, разочарованию клиентов и имиджевым потерям для самого 1С. Конечно, это не единственная проблема подобных провальных проектов, но точно одна из. И причем проблема, лежащая в самой основе всего проекта, в его фундаменте.

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

Что еще очень важно - внесенные изменения должны быть подробно задокументированы, чтобы исключить неоднозначность при внедрении конечных продуктов. К тому же это позволит сохранять последовательность подходов при последующей доработке решения. Простая документация, собранная на Docusaurus, уже снимет целый ряд вопросов у пользователей, а также станет хорошей базой знаний при подключении к разработке новых сотрудников.

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