Brains писал(а):<B>Вопрос</B>: <I><b>чтобы не изобретать велосипед, может, кто подскажет два-три достойных описания схемы рабочего процесса локализации</I></b>, если таковые вообще где-то выложены в Сети?
Не знаю, можно ли где что найти по этому поводу, но вот у меня выдался в полвторого ночи небольшой перерыв, давайте я попробую описать некий процесс.
Сразу скажу, что описание ни в коей мере не претендует на полноту и правильность. Все поправки, дополнения и исправления от коллег будут приняты с благодарностью.
Возьмем для начала исходную ситуацию:
а) не слишком большая программа
б) перевод интерфейса
в) более-менее вменяемые заказчики
г) более-менее вменяемые программеры/админы/консультанты закачиков (не все, это нереально, да и не нужно, но хотя бы те, с которыми предстоит общаться)
д) более-менее нормальные сроки, т.е. не больше 10 - 15 тысяч слов в неделю (со всеми повторами)
е) единственный минус - сама программа не предоставляется (из моего опыта так чаще всего и бывает, хотя, наверное, у коллег есть и другие примеры)
Сразу же примем как данность, что указанные выше условия и описанный ниже процесс идеальны, такого никогда не бывает. Именно никогда. В самом лучшем случае бывает нечто подобное, не больше.
Значит, так: сначала все стринги вытаскиваются оттуда, где они лежат и сводятся в определенные пакеты. Если программа большая, то лучше всего - по "тематике", если можно так назвать. Т.е. отдельно стринги компонента логистики, отдельно строки компонента контроллинга и так далее.
Другой вариант, особенно если программа небольшая - сведение в файлы по типам объектов: отдельно строки сообщений, отдельно строки команд/пунктов меню, отдельно строки из диалоговых окон и т.д.
Самое худшее, что может быть - все стринги бессистемно свалены в кучу в одном файле под перевод. Ужас. Но этот случай рассматривать не будем, потому как даже и не хочется.
Итак, из этих строк с помощью соответствующих инструментов вытаскивается наиболее частотная терминология. Терминология отбирается по принципу, скажем так, "нехарактерности" для программного обеспечения как такового. Т.е. не надо забивать в терминологические списки слова типа "сохранить", "скопировать" и т.д., то есть то, что есть в любой программе. Эти термины и так всем нормальным людям известны и в массе своей эта терминология базируется на глоссариях и продуктах MS, тратить на них время при обработке терминов нет смысла. Хотя, конечно, можно. Но важны не эти термины, а те, в которых заложен, так сказать, сам смылс программы, именно их и важно заранее обработать перед переводом.
Пример из практики - переводил не одну программу для создания монтажных схем, создания диаграмм автоматизации производственных процессов и подобных задач. Там, естественно, были важны такие термины, как "ПЛК", "шина", контроллер", "стандарт МЭК" и прочие защитные автоматы, контакторы, разные реле...
Вот. Вытащенная терминология сводится в экселевский файл, лучше всего в виде таблицы со столбцами "термин", "перевод", "комментарий заказчика", "комментарий переводчика". Со столбцами "термин" и "перевод" все ясно, в "комментарий заказчика" закачик должен ввести побольше информации по данному термину (примеры использования, объяснения и т.п.), со столбцом "комментарий переводчика" тоже все ясно - почему именно так обозвал, а не иначе. и какие есть (если есть) варианты. Если уже есть локализация на другой язык (как в моем случае, у меня рабочий язык немецкий, а программы обычно еще и локализованы на английский), то есть смысл (и очень большой!) в еще в одном столбце с переводами исходника на этот язык.
Допустим, итого у вас около 1500 терминов (реальный пример из одного моего весеннего перевода), вы их переводите, используя предоставленную информацию, и отправляете заказчику. Заказазчик все это смотрит , обсуждает с вами и со своими инженерами, ну и, в конце концов, утверждает терминологию. После чего ее лучше всего загнать в соответствующий инструмент типа Мультитерма, словаря в Транзите - кто на чем работает и кому как удобно.
Вот. Потом присылаются сами стринги. Ой, нет, забыл. Когда стринги прислали или раньше, надо обязательно обсудить с заказчиком проблему места. Обычно всегда есть около 30% свободного места, то есть перевод может быть примерно на 30% длиннее оригинала. Но часто нет и этого. В любом случае надо продумать, как и что вы будете сокращать при переводе. Метод сокращения много разных, надо отобрать и утвердить те, которые вам и заказчику нравятся/нужны/подходят.
Ну и все, прислали стринги, работаем. Со стрингами надо обязательно просить прислать хелпы и руководства (так называемые мануалы), если они не были присланы раньше. Лучше все их получить еще до перевода терминологии, конечно же.
Итак, переводим это добро (строки), в процессе контактируем с представителями заказчика, просим прислать скрин-шоты, просим объяснить, что это за функция и нафига она нужна, просим сказать, о чем конкретно речь, обычный процесс, короче.
При переводе особое внимание нужно уделить таким терминам, которые в исходнике могут иметь два значения (а по жизни слово одно), а на русский переводится двояко.
Пример: так как я постоянно перевожу ERP, сразу вспоминается головная боль в виде немецкого Wert/английского value. И то, и другое может переводиться и как "значение", и как "стоимость". Вот и думай. В немецком особые проблемы связаны со словами, которые в ед. и мн. числе имеют одинаковый вид, например, слово Parameter можно перевести как "параметр" или как "параметры", а слово Kabel, соответственно, как "кабель" и "кабели". Все это надо тщательно отслеживать и в сомнительных случаях запрашивать клиента.
Еще одна заповедь - если одна штуковина названа так-то, а потом вы ее решили назвать иначе, менять надо все и везде, даже если оба использованных перевода являются синонимами. Иначе пользователь просто не поймет, почему в программе одна и та же штука переведена двумя способами и велика вероятность того, что он посчитает, что это разные опции/функции/команды или что там еще.
Если исправить уже готовые перевод невозможно, что же, тут надо действовать в зависимости от серьезности ошибки. Допустим, немного ошиблись вы изначально в выборе термина, а потом поняли, что перевод должен быть немного другим. Если исправить такую ошибку невозможно (что сплошь и рядом, например, у меня на работе), лучше не корректировать ее задним числом в продолжении перевода, а писать так и дальше, пользователю важно, что одна функция называется именно так везде, а что вы с термином прогадали чутка - что же, спишем на особенности данной программы и исправим при следующем апдейте, если понадобится. Естественно, речь о мелких, не очень значительных ошибках. Понятно, что если вместо "сохранить" вы написали "копировать", это грубейшая ошибка и ее надо исправлять везде через невозможно. Если же вместо "рамочного договора" вы написали "общий договор", то ничего суперстрашного в этом нет, хотя и нехорошо.
Еще раз для возможных критиков - примеры выдумываю в ходе написания на основе моего опыта, часть из них реальна, часть нет, не кидайтесь помидорами, а лучше киньте подобных же реальных примеров.
При переводе постоянно надо следить за длиной строки (для этого есть куча разных опций в разных инструментах переводчика, не буду про них писать) и использовать только утвержденные способы сокращений. В особо кривых случаях, когда никак не вместить перевод в отведенное место, естественно, советуемся с закачиком. Может, вам повезет и программисты решат увеличить длину окошка или его ширину. Другой вопрос, что идут они на это чрезвычайно редко. Но бывает. Опять-таки из моего опыта, не более.
И вот все строки переведены, файлы отправлены. Заказчик обрабатывает их своими способами, проверяет (особенно на терминологию и длину строк), пишет вам недобрые письма с просьбой укоротить такие-то и такие-то строки еще на пару знаков или проверить там-то и там-то правильность использованных терминов, а потом засовывает эти переводы в программу. Как он импортирует - это уже его проблемы, вас они не касаются.
После того как строки импортированы, продвинутые пользователи заказчика или просто назначенные им программисты, админы и т.д. тестируют программу на том языке, на который выполнялся перевод, и сообщают ему, а он вам о всех недочетах и недостатках. Обычно все выловить невозможно, но основную массу ошибок, если программа не очень большая, все же можно найти. Ошибочные строки присылаются переводчику, он их правит, закачик их снова импортирует в программу, еще немного проверяет, подтверждает правильность перевода и на этом все, можете выставлять счет.
Вот, пока все на этом. Извиняюсь за многословность и опечатки, а также частые отходы в сторону и не совсем стройную логику изложения. Все-таки три ночи уже.
Надеюсь на помощь коллег с точки зрения критики, дополнений и прочего.
Про перевод хелпов/руководств к программам можно написать чуть позже, там есть своя специфика.
Кроме того, незатронуты такие вещи, как формуляры/бланки и прочие готовые шаблоны. Их локализация - особь статья, не знаю, интересно ли это кому-нибудь, потому и не писал про них.
К сожалению, из-за разногласий с администрацией я более не участвую в работе данного форума и сайта и ничем не могу вам помочь. Поэтому прошу не писать мне личных сообщений на форуме, если надо, обращайтесь через эл. почту.