Alexander Bukhonov

+1
с 2020
0 подписчиков
23 подписки

Да давайте прямо тут пока и продолжим ветку про несекретное. На почту, впрочем, тоже напишу :)

1. А большинство переводчиков и компаний даже и не знают, что в UE можно подсмотреть в название ассета и внутренний путь к элементу в нем. Если в файле нет, то и не догадаются.

К тому же у вас сейчас все в таблицах, есть неймспейсы, айдишки созданы вручную и они осмысленные — это огромный плюс. У нас тут ребята, как и многие разрабы, чьи экспортированные из UE файлы я видел по работе, ничего не знали про локу, поэтому не заморачивались, хранили текст прямо в ассетах, без неймспейсов, со сгенерированными айдишниками. В итоге при экспорте получается файл со строчками в де факто случайном порядке... Кошмар для переводчика. (Это мы уже решили сортировкой по Source Reference.)

2. Комменты можно добавлять в таблицах строк, но... не в самом редакторе строковых таблиц в UE! Он этого не поддерживает. Можно экспортировать в CSV, добавить сколько угодно столбцов, накидать туда комменты, теги, контекст, да что угодно. Импортировать это обратно — и оно сохранится. Но вы этого не увидите и не сможете изменить или добавить прямо в UE. При том, что вообще-то сама суть и UI для работы с подобного рода таблицами в UE есть. На мой взгляд, это лишний раз убеждает, что сам эпик не пользуется редакторами строк в UE... Подозреваю, у них просто есть какие-то свои плагины/надстройки для редактора по работе с текстом и локой. С тем, что есть в редакторе по умолчанию, работать над проектом типа Фортнайт просто невозможно: слишком много и часто они релизят контент. Возможно поэтому лок дашборд и висит в статусе Experimental уже много лет и ничего там кроме как по острой необходимости не меняется.

3. А вот у нас сейчас текст прямо в ассетах и, конечно, это печально, потому что даже исправляя опечатку, ты создаешь проблемы с последующим мерджем. Плюс никаких пакетных действий не сделаешь, да и иной раз хрен найдешь нужный текст в гигантском хитром виджете... Как-то глупо это по современным меркам :) Будем точно переходить на таблицы строк, но очень не хочется терять простоту создания текста: ведь без таблиц ребята просто пишут текст, а с таблицами придется сначала открыть нужную, добавить строчку, потом сослаться на нее...

А у вас нет проблем со встроенными строковыми таблицами? Ведь это же бинарные ассеты. Нет страданий, когда приходится их мерджить?

(Кстати, вот хоть убей, но не понимаю, почему эпики сделали строковые таблицы бинарными. А главное зачем... Почему не текст?..)

Привет!

Спасибо, что раскрываете тему. Инфы по локе в UE явно маловато.

Интересная программка. И, конечно, необходимая, если вы не пользуетесь никакими CAT-программами, поскольку редактор переводов в UE — абсолютный ужас. Да и даже если отдавать потом профикам или использовать какую-то CAT-программу самим, у многоязычного табличного формата типа эксельки есть явные преимущества относительно PO, который в UE используется для экспорта по умолчанию.

Посмотрел, однако, формат, который испольузется у вас в эксельке, и у меня вопрос: почему вынесли SERVICE DATA вниз таблицы отдельно? На это есть какие-то технические причины, которые я не улавливаю? Просто было бы куда лучше оставить эти данные в отдельных столбцах прямо в основной таблице: так контекст был бы виден переводчику сразу (Source Reference очень помогает при переводе, плюс по нему можно сортировать — и получать более-менее хорошую группировку строк), искать и фильтровать по нему (фильтрация по asset name или кусочку имени, например, очень помогает увидеть все строки, так или иначе связанные с одним понятием или ассетом), ну и так далее. Плюсов много, но есть один очень важный: если бы все метаданные были в той же таблице, что и данные, а не под ней, то файл стал бы совместим с CAT-программами — а все стоящие переводчики сейчас только в них и работают, прямо в файлах очень редко когда переводят, разве что мелочь всякую. То есть формат таблицы (навскидку) #, Namespace, ID, Source Reference, Comments, Source Locale, Target Locale #1, ..., Target Locale #N без «лишних» данных внизу был бы как минимум универсальнее, а на мой профессиональный взгляд попросту лучше во всех отношениях.

А как вы вообще с текстом работаете в игре? У вас текст прямо в ассетах сидит или в стринг тейблс? Если в таблицах, то это ассеты или CSV-шки? Вообще, я бы с радостью пообщался с вами — у меня нехватка знаний по Unreal Engine (информации о локе вообще немного, а уж о том, как люди реально работают с текстом в UE и того меньше), зато есть чем поделиться про локализацию (я 15 лет перевожу и 4 года управляю проектами по локализации). Если вам это интересно, давайте поболтаем :) 

Я нынче работаю лок менеджером в компании, где несколько больших игр на UE. И текущий подход к работе с текстом мне не нравится. У нас есть идеи, как допилить редактор, чтобы было не так больно работать с текстом и локой, но это требует немало ресурсов. Сначала хочется понять, а не слишком ли я заморачиваюсь, не упускаю ли я какой-то другой подход, который не требует таких вложений.

1