Proposal: Runtime Loading of Loc Content

[TheMartianLife]

Yarn Spinner makes it super easy to offer your dialogue in a new language; you just have to fill out a loc table with the new lines corresponding to the line ids of the original script. That's great, as long as you're doing it at edit time. Fan translations - a core part of game fan and modding culture - can't make use of this. But I think very few changes would be needed to make anyone able to provide a translation for a game.

Yes, it might not be something a game wants to encourage. So it should be optional. And yes, it might come with extra requirements about making people agree to license agreements about use of the original dialogue. But that's on the developer to decide. Today, fan translations or edits of games are happening anyway, but it often involves some level of unauthorised redistribution of a game or its source files. We could easily provide an option where all that needs to be shared is the translation file itself - which anyone who already owns the game could import and use.

How would this work?

A developer would set up their game to check on launch for a suitable file in a suitable location, and for their settings UI to populate extra entries if such an asset is able to be loaded, and for their line provider to be able to fetch from this if the resulting new locale option is selected.

A translator would somehow access a template file with all the line ids and original line content - either something exported from the loc tables and shipped with the game or something just shared online with the interested community. They would then fill out the new line content and somehow indicate the new locale name, probably by file name.

A player could download such a file and put it in the target directory within their own game copy as installed on their own machine, then be able to launch the game and select it from the game settings as a first-class offering alongside any of the languages the game shipped with.

What would this require?

1. YarnSpinner-Unity API additions to:

• load a translation from an on-disk asset into a form the line provider can make use of,
• report back the locale code/language name/file name of the asset loaded so that it may be offered in the UI and set in the LocalizationSettings, and
• possibly more complex behaviour for graceful fallback if malformation or missing IDs are encountered. Now also would need to support "the language your settings specify literally doesn't exist anymore".

2. Some thought to the nicest process by which the template files or translation files could be shared. Obviously this part is not really our problem but it would be nice to at least provide guidance on parts - such as "we recommend you provide clear license information for usage of any content in template files you share online" or whatever.

3. Potentially some sort of metadata file. Say, a translation file could be specified by a JSON file giving its locale name and code and fallback languages and the file path to the loc data or whatever. But to not require this would be better. Just a CSV of line content is definitely the ideal easy process.

[parisba]

I really like this!

[desplesda]

This looks good - happy to implement pending API design!

[TheMartianLife]

Depending on how asset tables are stored in a build artefact, you could potentially even offer an in-game option to produce and export the template file from the game, also at runtime. I don't know how feasible that part is.

[TheMartianLife]

Also how would it work in projects where many loc tables exist, like in a game where there are loads of Yarn Projects? So there are definitely still details to figure out.

[desplesda]

Something that occurs to me: what happens if externally provided strings make use of glyphs not present in the fonts used by the game? For example, a game only using latin characters with a fan translation into Korean. A way to supply a new font might be necessary in this case.

[KXI-System]

Something that occurs to me: what happens if externally provided strings make use of glyphs not present in the fonts used by the game? For example, a game only using Latin characters with a fan translation into Korean. A way to supply a new font might be necessary in this case.

Font rendering is a rabbit hole that I would put that weight on the developer instead of the tool, especially if they're interested in supporting fan translations. In an ideal scenario the game would have font or character fallbacks that would fit the style and font rendering needs, leaving the external translation to just focus on translation. Otherwise something, whether that be YarnSpinner or the game, needs to figure out how to create TMPro Font Assets during runtime and ensure it's compatible with the project. That's assuming the project even uses TMPro and not another text rendering package, or a bunch of other factors which could complicated font rendering. This is also assumes a font switch would be enough and doesn't cover locals where Unity sometimes struggles to render correctly without additional support, like Arabic and other LTR languages.

I'm not saying that fan translation projects can't do these things, but it would be a mod on top of the game instead of additional files to be loaded. And a tool can solve all of these font rendering problems, but I don't think it should be YarnSpinner to do it. And if a developer would consciously support loading external fan translations then they should also support proper rendering of those translations, instead of leaving up to their community to do the work they couldn't bother with.

Though YarnSpinner could read some sort of config file like in point 3, and then expose that information to the project. So a fan translation can define information like file asset file paths, then it would be up to the game to interpret that data for runtime. That could be font files or even VO clips.

If a one file CSV solution is really desired, then the "config" part of the file could be smooshed into the CSV somehow. Like the first row having that config information, but again if additional files would be supplied with the fan translations then being a one file solution would be moot.