Как стать автором
Обновить

Комментарии 29

3. Узнайте ограничения на длину слова и строки
Никогда не понимал смысла таких ограничений, если даже для любительских переводов это не проблема. Напомнило совет избегать букву «ё» из-за потенциальных технических сложностей. Ну ё-моё, если уж её и избегать, то по совсем иным причинам.
Надпись на кнопку вдруг не влезет.
Это уже проблемы форматирования, количеством символов измерять этот факт можно только при моноширинном шрифте.
Нет, не только при моноширинном шрифте; просто при переменной ширине измерение выйдет не совершенно точным.
Это будет просто эвристикой.
НЛО прилетело и опубликовало эту надпись здесь
Если уж он думает о количестве символов, почему бы ему не думать о форматировании? Меня всегда удивлял подобный подход. Я понимаю, что бизнес-процесс и всё такое, но неужели так сложно предоставить локализаторам, скажем, визуализатор текста, чтобы символы считать не приходилось?
Типичный случай
Run -> Исполнить


Никакой шрифт не спасет. Ширина кнопки 45 пикселов, если чо.
Это частный случай, в тексте явно говорилось не об одних лишь кнопках. Я могу точно так же привести в пример какой-нибудь диалог из какой-нибудь jRPG, где считать количество символов для умещения в экраноместо просто бессмысленно из-за большой вариативности отношения количества символов к длине строки.
Upgrade-> усовершенствование

Xorror x — успехов
Ловко.

sale -> распродажа
gay-> гомосексуалист
Мне кажется, меня принципиально никто не хочет понимать. Я разве говорил, что следует игнорировать тот факт, влезет ли слово в отведённое ему место? Я говорил, что для определении этого куда разумней использовать ширину текста, чем количество символов в нём. Вы же приводите примеры, когда и по количеству символов очевидно, что строка не умещается. Классно, конечно, но что насчёт остальных случаев? Когда, скажем, в строку влезает от 100 до 120 символов и переносы по словам? Вы тоже будете символы или слова считать? В этом я тоже могу вам успехов пожелать.
1. Переводчик не должен знать каким шрифтом и что будет набрано — моноширинным или нет. Он не должен лезть в графику. Он может рукодводствоватса одним параметром.

2. Когда в строку влазит от 100 до 120 символов (переносы в играх использовать не правильно, если конечно это не текстовое рпг какое-нибудь) переводчику указывается максимальная длинна в 120. Нет проблем если текст будет короче, хуже когда длиннее.

3. Пользуясь твоим примером: Например английский текст -100 символов. Умний програмист знает о сложностях перевода и закладывает в длинну 20% — в строку влазит 120 символов. Только вот немецкий в среднем длиннее на 50% а не на 20%. Такие пироги.

1. Во-первых, исходя из поста, речь о редакторе. Во-вторых, почему же он должен знать о количестве символов тогда? Может в случае каких-нибудь казуальных игрушек и достаточно мерить текст символами, но в случае более богатых текстом играх такое не всегда может пройти без последствий.

Я думаю, никому бы хуже не стало, если бы редактор видел окошко с визуализатором текста вместо всех этим формул с вычислением длины.

2. В некоторых случаях проблемы могут быть с его внешним видом, если об этом не позаботиться. А в случае с автопереносом по словам (именно его я имел в виду) разброс может быть и 50-120 символов, когда чем длиннее слово, тем больше пустого пространства на предыдущей строке оно съедает.

Вот, к примеру, как в таких случаях может повлиять на картину простое дробление слова (в игре выводятся только три строки):

1 Редактору тоже не к чему смотреть игру, это задача Localization QA. Переводчики и редакторы должны знать о количестве символов.

2 Конкретно на примере видно, что окошко плоцо подходит и для первого текста — слишком маленькое межстрочное расстояние.

1. Теперь понятно, что же является препоной на пути к качественной локализации.

Scee qa рапортует о таких проблемах, как на скрине. Ее провэйвили намеренно
>Типичный случай
>Run -> Исполнить
«Пуск»-не покороче будет?
bash.im/quote/390425
жаль, что не вы один не понимаете.
нередко встречается, чтоперевод выходит за границы элемента на котором должен быть расположен.
Иногда даже и разрабы не владеют такой информацией, каждый такой баг обзывается одинаково — Текст не влазит в поля, сократить.

На сколько сократить? Переводчик начинает «водить пальцем по монитору», считать :). Нещадно режет фразы (к слову сказать, во французском и немецком языках, например, все тексты в объеме вырастают этак на %30). Но это зачастую пальцем в небо. Потому снова итерация = время.
Кстати, вот локализаторы Dead Space 3 точно считали символы, потому что пару раз встречался текст с переносами, расставленными явно позже, чем следовало бы исходя из ширины текста. Вместе с автоматическим переносом получалось что-то вроде этого:
До начала работы спросите заказчика,
какие существуют
ограничения на количество слов (или,
скорее всего,
на количество символов с пробелами и
знаками препинания)
во всех строках игры, либо определенных
видах строк.
Это имеет отношение к ширине строки, а не к количеству символов.
Ну да, глупо сравнивать, например, «i» и «щ», но это (кол-во символов) единственный критерий, который есть у переводчика. Переводчик не видит, как будет отформатирована строка и какой шрифт там будет использоваться.
Думаю, в этом и проблема, что не видит. Вот и приходится символы считать. Если уж разработали игру, неужто так трудно поставить локализаторам инструментарий для решения подобных проблем? Везде только и вижу статьи о том, как правильно прогибаться под техническими сложностями.
Вы живете в идеальном мире :-)
Это вопрос не только и не столько технических сложностей (хотя и они есть тоже), сколько цены и времени.
Возможно. Но на правах хобби часто занимался подобной деятельностью, и иногда мне кажется, что у любителей уровень организации куда выше. Я в таких случаях просто писал программки — это не занимало много сил или времени, а переводчикам изрядно облегчало жизнь.

Бизнес-процесс развращает. Там бы, наверное, одно обсуждение целесообразности затрат съело бы больше времени и средств, чем собственно реализация.
Я бы поспорил с пунктом про макросы а, в идеале, изменил его на «Любите VB, он спасёт вам дни и недели работы».

Код и макросы невероятной силы интструмент и именно благодаря ему «продюсеры предпочитают именно такой формат». Гораздо проще и быстрее написать экспортёр на ВБ силами локализатора/сценариста, чем напрягать си программера на написание «программистами система управления текстом».

И, счётчик количества символов можно написать одной формулой, не надо плодить лишние столбцы.
В русской игре могут фигурировать крутые парни, которые будут называть друг друга «дорогими» вне зависимости от пола.

Эм… что-то не совсем уловил, в какой игре и в каком виде это встречалось?
Гульмэн наверное
Зарегистрируйтесь на Хабре, чтобы оставить комментарий