Closed albertjane closed 1 year ago
Hi @albertjane
Do you plan to add multi-language support to arrow ?
Support for multilingual projects, in terms of internationalization, is not planned. Features such as RTL (right-to-left) and CTL (complex text layout) would be, but definitely not in the short term.
How would you implement multi-language currently ?
If someone is going to do that, one approach is to add multilingualism on the node level.
For example, Dialog
node currently keeps { ... lines: ["as a vector of strings"], ...
but a multilingual dialog can keep a dictionary per line (e.g. { ..., lines: [ { en: "English version", fr: "...", .. }, ... ], ... }
). There as well needs to be changes to the GUI and implementation of the nodes.
But there are reasons (beyond common constraints) that I would not approach the task this way.
How you would approach it ?
First and foremost, you need to set up a quick and convenient way through which different people (translators, audio engineers, etc.) can contribute to your project with the skills they already poses.
The next challenges surface while using dynamic features of Arrow, such as resource modification or exposure (i.e. printing {variable}
s and {character.tag}
s via content nodes or variable-update
nodes on strings) in runtime. Internationalization is a tricky business, specially when the target languages are too different, syntactically, from the source. For example adding word-1 to the right of word-2 can be meaningful in one language, but completely meaningless in another, although you have translated each part independently. In other worlds you have to introduce new logic if you're going to have such dynamic features being used. Exposure can create another league of wired situations in its own way.
These are just the basic challenges.
If I needed to go for multilingualism, considering Arrow as is, and with no change in the runtime side of the things, I would try content re-mapping techniques.
First you need to establish some ground rules: Not to use exposures and string variables (other variables are fine). If you need different versions of a piece of content, take the hard way. It would serve you in the long term. Then you can create a map (maybe a spreadsheet) of all the data you would show to the users, where there are alternative contents (translations) for each entity. It wouldn't be difficult because all the Arrow resources get unique identifiers. The next step is to have your game using the alternative content whenever the original content is observed. The logic remains universal, generally speaking. You can implement the mapper functions yourself, or rely on your engine's features (such as Godot's translation-server) and use the messages (textual parameters) directly as the keys.
There are other ways of course, including what you've already mentioned, with their own pros and cons. At the end of the day, the best approach depends on your work-flow, resources, preferences and the project's nature.
Best of luck.
Hi again @mhgolkar
Do you plan to add multi-language support to arrow?
How would you implement multi-language currently?
I'm thinking multilpe options, create an .arrow file for each lenguage, chapter01_en / chapter01_es and so on, but the logic would need to be duplicated and lead to language specific bugs. Another option could be create language scenes, scene_01_en, scene_01_fr, etc, but would have tha same issues as before. Or extra languages could be handled by the game itself, that present some advantages in terms of logic, but extra implementation needs to be done.
How you would aproch it?
Thanks for yor time 🤗 Albert J.
P.S: Sorry to bother you again, please let me know if you prefer another way of communication.