We have a project where all the dialogue is triggered as SoundWaves with subtitles attached, but Unreal refuses to localise the SpokenText in a SoundWave.
So, in order to avoid having to rewrite a perfectly working blueprint which loads SoundWaves on demand, we’ve created DialogueWaves purely to hold the localised subtitles.
These subtitles now appear in the Gather and we’ve had them localised.
When the SoundWave is triggered, I load the corresponding DialogueWave so that I can display a localised subtitle.
However, the SpokenText field in the DialogueWave always contains the English string.
All other strings in the game are being localised correctly.
Is there a post-load call on the asset to update the string with the localised data, that I’m missing?
USoundWave::SpokenText is FString so by default it won’t go through the UE4 localization pipeline. I think these days it’s only there as a throwback to how things worked in UE3 (where localization data could be assigned to random properties via a key).
UDialogueWave is is the UE4 way to handle localized dialogue, and they handle far more complex localization cases than just creating a 1:1 mapping of localized sound wave assets (which may not map correctly for all languages). You may notice that they’re also FString, but we have custom gathering, GatherDialogueWaveForLocalization, and application, UDialogueWave::UpdateMappingProxy, of dialogue wave subtitles.
We could implement something similar for USoundWave, but they’re designed to be a sound primitive rather than localized directly (the comment about the subtitle being localized is a lie).
As for why your dialogue wave subtitles aren’t localized either… the localization happens when the contexts are created (which relies on the context having a linked sound wave). If you need access outside of the dialogue wave itself, you’ll have to mimic the logic in UDialogueWave::UpdateMappingProxy that finds the localized text into the subtitle cue.
Yeah, I knew the SoundWave one wouldn’t localise, but assumed the DialogueWave would work like any other text field…trying to manually call UpdateMappingProxy now to see if that will fix my problem.
Thanks for the quick response Jamie!
I just realised UpdateMappingProxy is called by PostLoad. I updated my previous answer with some more information. We only actually touch the localized version of the text when we create the subtitle cues, so if you need external access you’ll have to mimic that behaviour (or make sure the dialogue wave context has a sound wave set on it).
Honestly, if you’re comfortable doing it, it might make more sense to modify your version of UE4 to have USoundWave assets gather their subtitles and add a way to get the localized version, rather than go through the process of creating a bunch of dummy dialogue waves.
Ah, it only feeds into Unreal’s subtitle system. We’re not using that because we’re in VR - so I’ll have to manually extract the localised string.
Unfortunately we’ve already committed and had hundreds of DialogueWave subtitles localised. We only realised that the subtitle localisation behaved differently from other text when the final data was in but failing. Wish that had been documented…
At the very least we should have a function to let you get the localized subtitle for a context on a dialogue wave without having to wait for it to be created for the subtitle system.