Появилась необходимость локализации нашего программного продукта. Выянилось, что тут используется, в общем, два подхода:
----- 1 — Динамическая подгрузка строк из файла/реестра и т.д. и вставка их "в нужные места"
Преимущества — нет необходимости перекомпилировать exe-файл для смены языка. Так работают Total Commander, Skype и многие другие.
Однако иногда наблюдаются проблемы, вытекающие из сущности данного подхода — фразы обрезаются, наезжают друг на друга, да и вообще, ведут себя зачастую просто неприлично! Пример:
Добро пожаловать! Вы являетесь последним пользователем.
Wellcome! You are last user.
В основном, крупные фирмы избегают данного подхода, предпочитая делать для каждого языка свой билд.
Кроме того локализация на уровне таблиц строк или даже скриптов(особенно с динамическим определением размера контролов) является трудоёмкой с точки зрения изменений в исходном коде программ.
----- 2 — Работа с уже подготовленными иноязычными ресурсами, в которых отрегулирована высота и ширина всех контролов и т.п.
Этот вариант предполагает наличие отдельных локализованных ресурсов, которые компилируются либо в сам exe-файл, либо подключаются к нему из dll.
-----
Наша фирма, склоняется именно к такому варианту.
Имея версию ресурсов с одним языком, можно легко получить другую версию, просто переведя текстовые строки .rc-файла.
Проблема в том, что переводом строк занимаются наши дистрибьюторы в конкретных странах, и нам нужно отдать им эти строки (и только строки) для модификации, а затем встроить обратно в .rc файл. В .rc-файле же, кроме строк ещё находится куча различной информации, которую отдавать дистрибьюторам нет никакой необходимости — они не программисты, им нужно будет долго объяснять что и где переводить нужно, а где не нужно (например пути в реестре, вынесеные в IDS'ы).
Получается, что нужно написать утилиту – парсер, выдирающую нужные текстовые строки из rc файла, затем составляющую некую базу (со взаимооднозначными соответствиями), а после перевода этих строк втавляющий их обратно. При этом нужно, чтобы она (утилита) учитывала уже переведённые строки из созданных ранее баз данных.
===================
Так вот вопросы: Не существует ли уже таких утилит, а может они вообще не нужны и можно сделать проще? Как проще?
Здравствуйте, Neosyst, Вы писали:
N>Так вот вопросы: Не существует ли уже таких утилит, а может они вообще не нужны и можно сделать проще? Как проще?
Посмотри Langagent — парсит исходники и файл ресурсов, выдирает из них строки и складывает в языковый файл (xml), который можно отдать переводчику. У них же есть специальная тулза для редактирования этого файла.
Здравствуйте, Neosyst, Вы писали:
N>Получается, что нужно написать утилиту – парсер, выдирающую нужные текстовые строки из rc файла, затем составляющую некую базу (со взаимооднозначными соответствиями), а после перевода этих строк втавляющий их обратно. При этом нужно, чтобы она (утилита) учитывала уже переведённые строки из созданных ранее баз данных. N>===================
N>Так вот вопросы: Не существует ли уже таких утилит, а может они вообще не нужны и можно сделать проще? Как проще?
Наши локализаторы в свое время попросили сделать соответствующую Вашим требованиям утилиту, взяв за основу это — но там "парсер" в зачаточном состоянии, поэтому писал его с нуля. Даже без регэкспов (не знал тогда , что есть atlrx) работы не очень много (пару дней ).
Здравствуйте, Neosyst, Вы писали:
N>Так вот вопросы: Не существует ли уже таких утилит, а может они вообще не нужны и можно сделать проще? Как проще?
*.rc файлы можно подключать в другие *.rc файлы с помощью директивы #include — достаточно на начальном этапе определить, что в данный файл будут писаться только строки для контролов, и после локализация идёт достаточно просто( мучится с выдиранием строк не приходится). Таким образом к локализаторам попадают только строки необходимые для перевода и ничего больше.
Здравствуйте, Neosyst, Вы писали:
N>Появилась необходимость локализации нашего программного продукта. N>Так вот вопросы: Не существует ли уже таких утилит, а может они вообще не нужны и можно сделать проще? Как проще?
каким средством разработки пользуетесь?
от этого зависит какие средства локализации вам предлагать
Re[2]: Локализация? Локализация!
От:
Аноним
Дата:
01.02.06 05:36
Оценка:
Здравствуйте, &reY, Вы писали:
Y>Здравствуйте, Neosyst, Вы писали:
N>>Появилась необходимость локализации нашего программного продукта. N>>Так вот вопросы: Не существует ли уже таких утилит, а может они вообще не нужны и можно сделать проще? Как проще?
Y>каким средством разработки пользуетесь? Y>от этого зависит какие средства локализации вам предлагать
Основной проект VC6.0 остальные — более поздние версии VC. Желательно иметь общую утилитку и под VC6 и, скажем, VC7 (или 2003). И, желательно, простенькую и бесплатную. Lingobit и LangAgent мне не совсем понравились по некоторым причинам, перечислением которых я не хотел бы занимать ваше время. (а мы, как известно, люди занятые =) )
Я скачал парсер LocalizeRC — ничего, забавная штука. Именно что-то подобного я и хотел. Только она не совсем удовлетворяет моим запросам. Дело в том, что на перевод должны отсылаться только те строки, которых либо не было в предыдущих переводах, либо они были изменены. Соответственно, необходимо учитывать предыдущие базы. Я написал письмо автору — немцу Конраду — на предмет наличия новых версий, но ответа пока не дождался.
...
Про
#include
— это идея хорошая — можно разбить файл на 2 части — первая не подлежит парсу, вторая — находится в отдельном файле и парсится. Но всё-равно парсить нужно.
Дело в том, что строка:
содержит лишь только ту часть, необходимую для локализации, которая заключена в кавычки. Остальное отсылать на перевод — смысла не имеет. Если, к примеру, переводчики (люди, зачастую, с сугубо гуманитарным складом ума) случайно переведут идентификатор — ошибка обнаружится быстро — не будет компилироваться. А вот если удалят из 295 последнюю цифру (получится 29), о контрол может сместиться относительно своего местоположения и "спрятаться" за другим контролом. А это в локализованных версиях, которые тестятся по-минимуму (сроки, сроки), отследить будет трудно, возможно, вообще, только после релиза. Вывод — лучше вообще им не посылать служебную информацию, которая им не необходима для перевода.
P.S. Мне тут посоветовали XML c применением схем и CAtlRegExp. Спасибо большое, но мне кажется вся мощь этих штук не потребуется при написании парсера. Больше будет заморочек. Или я не прав?
Здравствуйте, Аноним, Вы писали:
А>Основной проект VC6.0 остальные — более поздние версии VC. Желательно иметь общую утилитку и под VC6 и, скажем, VC7 (или 2003). И, желательно, простенькую и бесплатную. Lingobit и LangAgent мне не совсем понравились по некоторым причинам, перечислением которых я не хотел бы занимать ваше время. (а мы, как известно, люди занятые =) )
Спасибо большое, но мы уже отдали этот проект на реализацию, человеку, который хочет у нас работать (и польза будет, и его проверим). За основу дали LocalizeRC — посмотрим...
, что есть atlrx) работы не очень много (пару дней 
).
