PyTom wrote:Hm... I'm not sure how well this would work. Here's a small chunk of the question, with all of the text elided:
[...]
I think after a while, it just becomes difficult to write the script in the first place, without that integration. There's a reason why movie scripts include the dialogue as part of the script, rather than as a separate file.
That be being said, the Ren'Py translation story could be better. It would be interesting to work with people who've translated games to see if we can figure out a way to improve things. I don't want to abstract the original script writing, but I'd be fine with a translation layer that processes the text before it gets to the user.
Oh, no no. That wasn't what I meant. I was thinking something like this: we can have text files, like
Code: Select all
# scene1_en.rpt
1: Hello world!
# scene1_ja.rpt
1: 今日は世界!
and we could refer them from the Ren'Py script with a syntax like this (% wasn't being used at all, wasn't it?):
where "text labels" could be meaningful names as well.
One other alternative is to provide with a "default" text, and something that will let Ren'Py to locate the translated line:
All in a similar fashion with usual open source internalization. Of course I'm suggesting this as an
alternative syntax, which doesn't break the backwards compatibility. Anyone could revert back to the "normal" syntax at will.
This way, providing with translations would become a lot easier, the text would be readable and on-the-fly language transitions would be possible.
All approaches have their cons and pros, but I don't think that is the case for design. There would only be a need to add a function to the API, which will load the specified JSON(XML) file.
@Alex
With the current specification, no.