Hi, I plan to add multiple languages to my game. In the past I’ve just created a spread sheet (csv) and stored the English word and their translations in separate columns.
Then, depending on which language is selected in the menu, I will gather the translation for each time a piece of text in displayed in game.
This system has worked very well so far and gives me the flexibility I need. But it seems too ‘hacky’ considering there is an extensive built in Localisation system in UE.
I looked into it and it seems a lot more complex than the current system I have, yet I can’t see any benefit to using this much more complex system. Can someone please
help me understand?
Primarily the system is designed so that most of the developers on a project don’t need to care about localisation concerns, and instead can just type in whatever they want wherever they need it (author-at-source), and then someone/something else takes care of the process of getting that text collected together and translated. The process of gathering that data together is where most of the complexity comes from.
We have a halfway house between author-at-source and what you do with your CSV files, which is a String Table. String Tables still only provide the source text (they are gathered for translation like everything else), but they do allow themselves to be robustly referenced from other assets and code.
Ultimately, if you’re a one-man band or small team, there’s nothing stopping you from continuing with your CSV file approach. You could even create a custom localised text source to let you load it into the UE4 localisation manager, which would let you access your data as FText (via FindText) and take advantage of features like live culture-switching, and avoid a constant fight with the parts of UE4 that expect to be dealing with FText (like UI).