Гостей: 2
Пользователей: 0
Всего пользователей: 2
Новый пользователь: Prorok
|
|
Во-первых, количество слов в переводе значительно возрастает (иногда до двух раз) по сравнению с фактическим количеством слов в переводе, если под рукой нет фильтров, которые бы могли отделить текст от кода. Буквально это значит, что вам придется заплатить в два раза больше. Во-вторых, процесс локализации существенно замедлится, так как переводчику нужно будет вчитаться в код, чтобы понять, какие части нужно переводить, а какие нет. В-третьих, переводчик потеряет единообразие в переводе:
show_data(samples, countone, "Original values"); show_data(samples, counttwo, "Original values");
Программа посчитает, что это две отдельные строки. Если между этими строками еще пара тысяч строк, то можете быть уверены, что переводчик забудет, как он в первом случае перевел "Original values", когда дойдет до второй подобной строки. Если бы код выглядел следующим образом —
Original values Original values
,
то программа бы распознала их как идентичные. Так вы сэкономите деньги, время и получите более однородный перевод. Потому помещайте тексты в отдельные текстовые файлы или, что даже лучше, в файлы в формате XML.
Со скриптами сложно работать, если рядом нет программиста, который сможет понять, что за скрипт. Лучший вариант для заказчика, это при подготовке глоссария внести туда все типы встречающихся скриптов. Причем желательно просто примеры, чтобы простой гуманитарий-переводчик понял, зачем тут эти скобочки. Вот эти скрипты должны испугать переводчика:
\n%StoredActID%\nEvent Date:%Date% \nEvent Time:\n%StartPlusLast%\n
Здесь спас только китайский:
\n%StoredActID%\n活动日期:%Date% \n活动时间:\n%StartPlusLast%\n
Это уже сейчас, зная все подводные камни, я вижу, что здесь к чему. В первой моей локализации действительно спасал только китайский вариант.
[{@0:player's name}] purchased [{@3:number}] [{@4:prop name}] at the port of [{@2:name}]. Да, скрипт прост для понимания. Но, тем не менее, многих недоразумений можно будет избежать, если просто упомянуть в комментариях, какого вида предпочтительнее перевод. Переводчик может написать «Игрок [{@0:player's name}] приобрел: [{@3:number}] - [{@4:prop name}] в порту города [{@2:name}]». А может написать «Игрок [{@0:player's name}] приобрел: [{@4:prop name}] - [{@3:number}] в порту города [{@2:name}]». Указав сразу, какой вариант предпочтительнее, можно облегчить жизнь не только переводчику, но и себе. (Хотя все равно правильнее всего будет «В порту города [{@2:name}] игрок [{@0:player's name}] приобрел: [{@4:prop name}] - [{@3:number}]».)
4. Вы думаете, что переводчик знает ответы на все вопросы
Поверьте, переводчик может не знать, какой символ нужен для переноса строки — /n или @A@D. И еще он совсем не в курсе, что программка для интеграции перевода при вытаскивании текста из «экселя» воспринимает двойные кавычки как символ окончания строки, и после этих кавычек текст просто пропадает. Поэтому не поленитесь написать ТЗ, в котором будет указано, какие символы в каком случае указывать, и где пробелы оставить, а где убрать.
|
|
Вы не зарегистрированы? Нажмите здесь для регистрации.
Забыли пароль? Запросите новый здесь.
|
|
