Localization and Ink workflow

[Shadowsun]

Hello,

I'll first introduce the context because I think it's quite a specific problem I have.

So we are a little team of 4 persons and I (the dev) joined recently, so I'm quite new with Dialog System.
And we are currently reworking the project for a long term production, it's a Visual Novel that'll contain more than 500k words, a number that raised a few questions internally, like how will it impact the workflow and how will it work with Localization.

We quickly found that Ink was the best tool (for integration purpose) for our writer but that still left the question about Localization.
I personally used a few tools in previous prod (like QuickSheet) that allowed to link GoogleSheets (and then the LocKit) into the project directly (with some uses like runtime updates for the localization team). But at the moment I have zero idea about how to connect all the elements together.

If I correctly understood how the Ink-DS workflow works, all the DS text are generated at runtime and so it doesn't allow any database import/export.

Did you already encountered that kind of need in a project? Have you any tips or advices that could help in our situation?

[Tony Li]

Hi,

Ink doesn't do localization itself. In fact, the Inkle devs ultimately recommended just writing separate stories for each language that you want to support.

Of all the external formats, Ink's integration with the Dialogue System is the most unusual. With the other formats, such as articy:draft and Chat Mapper, the Dialogue System can import content into its native dialogue database type.

Ink, on the other hand, runs very differently from other systems. So the Dialogue System allows Ink to run its own engine in Unity. The Dialogue System provides the UI and the components that interact with the rest of Unity, such as triggering conversations.

As you mentioned, it receives the text from Ink at runtime. The DialogueSystemInkIntegration script does this work. You can make a subclass and override the OnPrepareConversationLine method to apply localization:

Code: Select all

protected override void OnPrepareConversationLine(DialogueEntry entry)
{
    base.OnPrepareConversationLine(entry);
    entry.DialogueText = /*** your localized version of entry.DialogueText ***/
}

Alternatively, if you decide to write separate stories for each language (such as 'TheIntercept_EN.ink', 'TheIntercept_RU.ink', etc.) then just load the stories for the current language, and you don't have to worry about looking up localization at runtime.

[Shadowsun]

Thanks for the quick answer

I see, I have more insights about how to deal with Ink, it'll help me figure out a solution for our team.
The ink-DS workflow should not cause anymore problem with that in mind.

Still the need for an update at runtime is a must have for our team as we'll work with a huuuge volume of words and the localization team will provide a lot QA. In past production, I used synchronized google sheets with a little "dev build tool" that allow translators to directly see how the translation/localization react in the game as they are editing it in the sheet.

At the moment the only idea I have is to create a parser that convert my localized sheet in ink-structured JSON so it could be called at runtime in a kind of similar way of what I usually do ... but I'll call it a night and think more about that point tomorrow morning.

Thank you again, I'll dwell more into it tomorrow and try a few things thanks to your insights

[Tony Li]

I don't know if I made clear that OnPrepareConversationLine() is a runtime method. The Dialogue System calls it before showing each line of dialogue when playing a conversation at runtime.

Instead of the simple override I showed above that allows the base method to get the text from Ink, you might replace the entire OnPrepareConversationLine() method so you can get the text from Ink yourself, which will give you more flexibility to process it.

[Shadowsun]

Ah nooo I understood correctly what you said, I just didn't express correctly my concern

the Ink/DS workflow should do fine with our need, there is just the Localization team needs that'll require a bit of work from my side since we have to provide a lockit and we want it to be to be linked somehow to the rest of the project/workflow.

I will look about parsing those sheets datas into Ink format so I will be able to use the runtime workflow with the googlesheet

Thank you one more time, I'll come back if I have more questions or figure out a solution about the googlesheet