29.03.2004, 16:09 | #1 |
Участник
|
Help
Ну когда же в Аксапте появится нормальный русский хелп и сообщения об ошибках?
Ну так достали подсказики системы к полю в два слова или их полное отсутсвие. MSBS моглабы позаботиться, что бы там где отсутсвует русская подсказка вставить англискую версию. |
|
29.03.2004, 18:04 | #2 |
Учаснег
|
Скажу тебе, тезка, по секрету, что английский хэлп - не лучше Единственно что меньше двусмысленностей перевода типа Main Table - Главная (???) Таблица. Хотя иногда они-таки встречаются!!! В тех частях которые писали датчане.
Ну не успевают они хэлп писать вслед доработкам - даже в хедквортере, не говоря уж про локальные офисы...
__________________
Strictly IMHO & nothing personal |
|
30.03.2004, 08:57 | #3 |
Участник
|
Ну они могли бы хотябы постораться написать документацию... а то и документация такая же как хелп...
Помню когда я только начинал знакомство с Аксаптой для меня ихний текст был просто шоком... |
|
31.03.2004, 18:08 | #4 |
Участник
|
Не стреляйте в пианиста он играет как умеет.
Сразу оговорюсь что всё что написано ниже написано не про Аксапту но думаю что вполне к ней применимо.
Давайте прикинем чего стоит эта самая своевременная поддержка хелпов и подсказок. Чтобы система была более или менее распространена в мире достаточно поддерживать порядка 30 языков (3 английских, все европейские, турецкий, арабский, японский, 2 китайских, иврит - это из обязательных). Обычно языковые ресурсы хранятся в виде ресурсных файлов того или иного вида, т.е у вас есть 30 наборов языковых файлов. Теперь предствим ситуацию когда програмист меняет что либо в английской версии. Чтобы изменение попало в локализованную версию нужно либо заставить програмиста внести соответствующее изменение во все локальные версии, либо посадить человека (n человек) который будет собирать данные об изменившихся файлах скажем за сутки и размножать правки, либо написать скрипт который будет всё это делать автоматически. Первый подход отпадает по понятным причинам, второй в принципе возможен где нибудь в Индии но тоже не слишком надёжен, остаётся третий. Далее нам необходим отдел задачей которого будет выделять все английские куски из ресурсных файлов, переводить их на нужный язык либо посылать их переводчикам и вставлять обратно. Собственно это и есть самый денежно затратный процесс во всём цикле. Понятно что невозможно иметь в собственном штате переводчиков на 30 языков (может и возможно но очень дорого) поэтому выдернутые английские строчки посылаются переводческим фирмам. Понятно что среднестатистический переводчик в жизни своей не видел ERP системы и словосочетание "Main table" для него действительно "Главная таблица".(Впрочем как и в любом правиле в этом бывают исключения). "Свой переводчик" в этом смысле более надёжен. Переводческие фирмы берут деньги за перевод каждого слова, поэтому неплохо иметь некую базу данных в которых будут хранится все когда либо переведённые словосочетания, иначе у вас есть все шансы с десяток раз заплатить за перевод словосочетания "Sales Order". В результате мы получаем динамическую систему в которой постоянно присутствуют как переведённые так и непереведённые ресурсы, но при достаточной частоте переводов процент непереведённых ресурсов достаточно мал. Частота переводов может зависить от языка, точнее национальности. Например вы не найдёте японца не говорящего по английски, но английские меню в системе он воспримет как личное оскорбление. Китайцы тоже не любят английский, но совершенно по противоположной причине. Запустить такой процесс - это не слишком дорого (не считая переводов конечно, но ресурсы всё равно придётся переводить и деньги всё равно на это тратить так что extra cost получается не слишком велик) но тут встаёт один большой вопрос: Зачем? С точки зрения маркетинга полезность всего этого нулевая. Вы не можете сказать потенциальным клиентам что теперь ваши языковые ресурсы будут всегда up-to-date. Клиент искренне думает что это само собой разумеется и в его глазах это достоинством системы не является. Поэтому при выборе между хорошей языковой поддержкой и разработкой новой фичи деньги как правило дают на последнюю. |
|
31.03.2004, 18:28 | #5 |
Участник
|
<b>С точки зрения маркетинга полезность всего этого нулевая. ..... Поэтому при выборе между хорошей языковой поддержкой и разработкой новой фичи деньги как правило дают на последнюю.</b>
Точно ! Кстати по этой же причине мы не стали разрабатывать англоязычную версию тренинг-базы GNAD/AGAT по международной версии, а стали наращивать функциональные тренинги по предметным областям. И даже по разработке - тоже не будем (это если кто интересуется). http://ax-test.narod.ru ax-test@narod.ru |
|
01.04.2004, 09:09 | #6 |
Участник
|
Да я же не спорю что это обязательно нужно делать и кропотливо и точно переводить хелп. Просто порой убивает когда например к полю Гост ID выскакивает подсказка со следующим содержанием "ГОСТ ID". Хотя в англиской версии это достаточно подробно описанно. Приходиться выходить из Аксапты, пересталять язык и запускать заново. Не удобно.
Пусть не переводят, но хотябы посторались такие вот сообщения заменить или дополнить англиской версией, чтобы не приходилось постоянно творить манипуляции с языком в системе. |
|