[aenon]

Сразу оговорюсь что всё что написано ниже написано не про Аксапту но думаю что вполне к ней применимо.

Давайте прикинем чего стоит эта самая своевременная поддержка хелпов и подсказок. Чтобы система была более или менее распространена в мире достаточно поддерживать порядка 30 языков (3 английских, все европейские, турецкий, арабский, японский, 2 китайских, иврит - это из обязательных). Обычно языковые ресурсы хранятся в виде ресурсных файлов того или иного вида, т.е у вас есть 30 наборов языковых файлов.
Теперь предствим ситуацию когда програмист меняет что либо в английской версии. Чтобы изменение попало в локализованную версию нужно либо заставить програмиста внести соответствующее изменение во все локальные версии, либо посадить человека (n человек) который будет собирать данные об изменившихся файлах скажем за сутки и размножать правки, либо написать скрипт который будет всё это делать автоматически. Первый подход отпадает по понятным причинам, второй в принципе возможен где нибудь в Индии но тоже не слишком надёжен, остаётся третий.
Далее нам необходим отдел задачей которого будет выделять все английские куски из ресурсных файлов, переводить их на нужный язык либо посылать их переводчикам и вставлять обратно. Собственно это и есть самый денежно затратный процесс во всём цикле. Понятно что невозможно иметь в собственном штате переводчиков на 30 языков (может и возможно но очень дорого) поэтому выдернутые английские строчки посылаются переводческим фирмам. Понятно что среднестатистический переводчик в жизни своей не видел ERP системы и словосочетание "Main table" для него действительно "Главная таблица".(Впрочем как и в любом правиле в этом бывают исключения). "Свой переводчик" в этом смысле более надёжен. Переводческие фирмы берут деньги за перевод каждого слова, поэтому неплохо иметь некую базу данных в которых будут хранится все когда либо переведённые словосочетания, иначе у вас есть все шансы с десяток раз заплатить за перевод словосочетания "Sales Order".
В результате мы получаем динамическую систему в которой постоянно присутствуют как переведённые так и непереведённые ресурсы, но при достаточной частоте переводов процент непереведённых ресурсов достаточно мал. Частота переводов может зависить от языка, точнее национальности. Например вы не найдёте японца не говорящего по английски, но английские меню в системе он воспримет как личное оскорбление. Китайцы тоже не любят английский, но совершенно по противоположной причине.
Запустить такой процесс - это не слишком дорого (не считая переводов конечно, но ресурсы всё равно придётся переводить и деньги всё равно на это тратить так что extra cost получается не слишком велик) но тут встаёт один большой вопрос: Зачем?
С точки зрения маркетинга полезность всего этого нулевая. Вы не можете сказать потенциальным клиентам что теперь ваши языковые ресурсы будут всегда up-to-date. Клиент искренне думает что это само собой разумеется и в его глазах это достоинством системы не является. Поэтому при выборе между хорошей языковой поддержкой и разработкой новой фичи деньги как правило дают на последнюю.