У нас тут встала задача — перевести программу на английский язык. Когда переводили сами — проблем не было
Но сейчас самим и времени нет, и перевод нужен с гарантированным качеством. Так что будем обращаться к профессиональным переводчикам.
С переводом справки (HTMLHelp) проблем нет. Есть проблема с переводом интерфейса программы (сообщений, диалогов, менюшек и т.п.). Проблема в том, каким образом встраивать переведенные строки в программу. Хочется эту процедуру упростить, чтобы не делать лишней работы.
Я тут вижу такие варианты:
Отдать переводчику исходники (VC++) — пусть он прямо в ресурсах правит, с помощью Студии. Переводчик на такой вариант готов, а вот я — нет: совсем не хочется отдавать кому-то исходники.
Переделать программу — все строки загружать не из ресурсов, а из какого-то внешнего текстового файла. Частично мы так и сделали (по другим причинам), но полностью на это переходить не будем — мороки много.
Дать переводчику rc-файл, он его переведет, а мы потом вручную вставим в программу. Минусов тут два:
а) переводчик во время перевода не сможет посмотреть, как это все будет выглядеть в программе
б) нам придется потом проделать много работы, изменяя ресурсы.
Воспользоваться какой-нибудь утилитой, типа Resource Hacker. Это вполне приличный вариант, но Resource Hacker при выгрузке ресурсов в rc-файл вместо символических имен констант (типа IDD_ABOUT) пишет их числовые значения (разумеется — откуда он символические имена возьмет-то?). Поэтому нам все равно придется при добавлении переведенных ресурсов пробелать много работы.
Может, кто-то уже сталкивался с такими проблемами?
Может, есть какая-то другая технология, или утилита, более навороченная, чем Resource Hacker?
Пока-что я остановился на варианте 4, но придется нам, наверное, писать свою утилиту, которая обновляет "правильный" (студийный) rc-файл на основе resource.h и переведенного rc-файлы.
[]
M>Я тут вижу такие варианты:
M>
[]
M>Переделать программу — все строки загружать не из ресурсов, а из какого-то внешнего текстового файла. Частично мы так и сделали (по другим причинам), но полностью на это переходить не будем — мороки много. M>
Эээ.. Имхо на данном этапе развития индустрии ПО надо _сразу_ предусматривать многоязычный интерфейс. Пусть только предусматривать на уровне архитектуры, но предусматривать. Иначе — вы правы, потом мороки будет много
З.Ы. И кстати, не так много и мороки Если программный продукт — утилита средней руки (под этими словами я подразумеваю "средний класс", т.е. не самая простая, но и не навороченная) — пару дней на пришлепывание сбоку (т.к. в старой архитектуре, судя по всему, не было этого предусмотрено) модуля поддержки мультиязычности, плюс пару дней — на вписывание кода. Все имхо с поправкой на то, что я занимался в свое время подобной проблемой.
Здравствуйте, Denwer, Вы писали:
D>Здравствуйте, mikadi, Вы писали:
D>А если дать только obj файлы и ресурсы, сделать мейк для перекомпиляции ресурсов и линковку потом. D>Пусть правит ресурс а потом линкует и запускает.
Надо подумать. В принципе, как разновидность варианта (1) может и получиться. Переводчику придется устанавливать VC, но это уже проблема решаемая. Спасибо за идею, я почему-то мимо нее прошел .
Здравствуйте, Flamer, Вы писали:
F>Эээ.. Имхо на данном этапе развития индустрии ПО надо _сразу_ предусматривать многоязычный интерфейс. Пусть только предусматривать на уровне архитектуры, но предусматривать. Иначе — вы правы, потом мороки будет много
F>З.Ы. И кстати, не так много и мороки Если программный продукт — утилита средней руки (под этими словами я подразумеваю "средний класс", т.е. не самая простая, но и не навороченная) — пару дней на пришлепывание сбоку (т.к. в старой архитектуре, судя по всему, не было этого предусмотрено) модуля поддержки мультиязычности, плюс пару дней — на вписывание кода. Все имхо с поправкой на то, что я занимался в свое время подобной проблемой.
Речь не о том. Поддержка многоязычности у нас есть, с этим никаких проблем . Но кроме поддержки многоязычности нужна еще и сама многоязычность , то бишь переведенные "сторонним" человеком сообщения и т.п. как-то должны оказаться внутри программы . Я ищу варианты взаимодействия с переводчиком — чтобы вставить "результат его труда" в программу.
[]
M>Речь не о том. Поддержка многоязычности у нас есть, с этим никаких проблем . Но кроме поддержки многоязычности нужна еще и сама многоязычность , то бишь переведенные "сторонним" человеком сообщения и т.п. как-то должны оказаться внутри программы . Я ищу варианты взаимодействия с переводчиком — чтобы вставить "результат его труда" в программу.
Речь о том самом Если возможность мультиязычности предусмотрена архитектурой, то вы просите переводчика скачать и установить программу (а иначе нафик такой заочный перевод), и высылаете ему файлик вида:
[Главная форма]
Caption=Название моеу суперпроги # этот комментарий объясняет, что к чему...
[Вторая форма]
...
F>[Главная форма]
F>Caption=Название моеу суперпроги # этот комментарий объясняет, что к чему...
F>...
F>
F>Идея более чем прозрачна...
...а как же сплаши с нарисованным текстом, кнопки с нарисованым текстом, а такое иногда может быть не (пробел) обходимо (в смысле, нельзя обойти:) по историческим, например, причинам, а если учесть, что для различных языков может потребоваться чуть различный layout диалогов.
Тогда лучше resource-only dll'ы. Хотя идея передавать .obj'ы для последующей линковки весьма остроумна и мне очень пронравилась.
Здравствуйте, Frostbitten, Вы писали:
F>Здравствуйте, Flamer, Вы писали:
F>>
F>>[Главная форма]
F>>Caption=Название моеу суперпроги # этот комментарий объясняет, что к чему...
F>>...
F>>
F>>Идея более чем прозрачна...
F>...а как же сплаши с нарисованным текстом, кнопки с нарисованым текстом, а такое иногда может
текст можно и на ходу на сплеши и на кнопки нарисовать, это не проблема. F>быть не (пробел) обходимо (в смысле, нельзя обойти:) по историческим, например, причинам, а если учесть, F>что для различных языков может потребоваться чуть различный layout диалогов.
Если имеется в виду просто подгонка размеров контролов под разные размеры текста на разных языках, то это тоже в рантайме посчитать можно (а GTK+, которую я сейчас пользую -- вообще этого не требует -- сама ресайзит все, как надо)
F>Тогда лучше resource-only dll'ы. Хотя идея передавать .obj'ы для последующей линковки весьма остроумна и мне очень пронравилась.
Может... Но я пока не вижу чем принципиально отличается такая ДЛЛ от файла(файлов) данных.
Здравствуйте, Flamer, Вы писали:
F>Речь о том самом Если возможность мультиязычности предусмотрена архитектурой, то вы просите переводчика скачать и установить программу (а иначе нафик такой заочный перевод), и высылаете ему файлик вида:
F> F>[code] F>[Главная форма] F>Caption=Название моеу суперпроги # этот комментарий объясняет, что к чему...
Идея-то прозрачна, но делать так мы не будем. Пробовали как-то -- геморрой получается, если руками во всех диалогах, менюшках и т.п. строки выводить. В тексте получается много мусора (лишнего кода) и потом трудно править.
Наверное, лучше попробуем вариант с линковкой ресурсов к obj-ам.
Здравствуйте, mikadi, Вы писали:
M>У нас тут встала задача — перевести программу на английский язык. Когда переводили сами — проблем не было M>Но сейчас самим и времени нет, и перевод нужен с гарантированным качеством. Так что будем обращаться к профессиональным переводчикам.
Имхо, проще написать пару-тройку утилит по переводу ресурсов из EXE, DLL-файлов в INI-файл и наоборот. Или поискать нечто подобное.
В Delphi я пользуюсь ITE. Минус у него только один --- зачастую переводчиками программы являются добровольцы, а им не хочеться для перевода устанавливать программу правки ресурсов. Давно мечтаю написать мечтаю вроде Res Hacker-а, но как утилиту командной строки для генерации и обновления ресурсных DLL.
Здравствуйте, _wqwa, Вы писали:
F>>...а как же сплаши с нарисованным текстом, кнопки с нарисованым текстом, а такое иногда может W>текст можно и на ходу на сплеши и на кнопки нарисовать, это не проблема.
Это все вы говорите првильные вещи. Но на сплаше хочется извратиться и откинуть от текста тень (жестоко упрощаю, но я думаю проблема ясна).
Стоит к этому добавить что в программа хромышленной автоматизацци (я этим немного занимаюсь) на кнопках обычно нарисованы символы (пиктограмки, значки), без или с буквами, но текст там является частью символа (значка), а эти символы определяются стандартами ли, традициями ли, но различны для различных культур, в общем случае я не могу согласиться с тем, что перевод интерфейса можно свести к переводу текстовых строк.
W>Если имеется в виду просто подгонка размеров контролов под разные размеры текста на разных языках, то это тоже в рантайме посчитать можно (а GTK+, которую я сейчас пользую -- вообще этого не требует -- сама ресайзит все, как надо)
Ну это частный слачай. Иногда приходиться все-таки и переставить местами пару контролов, а где-то в комбобоксе слишком длинные названия получаются и хочется чтобы они не только при выпадении видны были, но и "так".
F>>Тогда лучше resource-only dll'ы. Хотя идея передавать .obj'ы для последующей линковки весьма остроумна и мне очень пронравилась. W>Может... Но я пока не вижу чем принципиально отличается такая ДЛЛ от файла(файлов) данных.
Нет, ну resource-only dll вообще не очень хороша, так как если локализация "влита" в exe'шник, это можно использовать для ограничения экспорта ( %) я имею в виду модель типа MS Office — то есть удобнее иметь несколько локализованных версий за разные цены, чем одну, но с набором локализаций к ней) и отдельные файлы тоже в этом смысле не очень подходят.
Здравствуйте, mikadi, Вы писали:
M>Пока-что я остановился на варианте 4, но придется нам, наверное, писать свою утилиту, которая обновляет "правильный" (студийный) rc-файл на основе resource.h и переведенного rc-файлы.
Лет 6 назад писал я утилиту на Delphi для редактирования разноязыковых (до 8 языков) RC файлов для большого проекта, написанного на BC5. Утилита предназначалась для переводчиков (внешних и внутренних) не знакомых с программированием
1. Пердусматривалась возможность редактирования только строк, которые показываются в интерфейсе, но всех выбранных языков сразу.
2. Примерная отрисовка меню и диалогов с визуализацией редактируемого элемента типа как в Workshop.
4. Изменение размеров и положения контролов.
3. Экспорт картинок и редактируемых строк в MS WinWord.
Заняла у меня эта работа в сумме около 8 недель.
Так что вперед
Если программный продукт — утилита средней руки (под этими словами я подразумеваю "средний класс", т.е. не самая простая, но и не навороченная) — пару дней на пришлепывание сбоку (т.к. в старой архитектуре, судя по всему, не было этого предусмотрено) модуля поддержки мультиязычности, плюс пару дней — на вписывание кода. Все имхо с поправкой на то, что я занимался в свое время подобной проблемой.
.
. Но кроме поддержки многоязычности нужна еще и сама многоязычность 
ICQ#: 198114726
