Lemma Soft Forums

I think there's room for improvement. Following the wiki page, the current ways of doing it are:

• Multi-Path Translation: means code duplication, maintenance becomes harder
• In-line translation: ends-up with interleaved code, difficult to read

It's a common practice to separate data and code (albeit we're talking about event-data and event-code). Wouldn't it be nice if we had a mechanism to make a clean separation between text and the event script?


Edit: A related issue I had in my mind for a while is, I think the design could usually be specified in a pure-data file. User could privide with a JSON (or XML, or whatever) that tells about the overall design --without any code or script.

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.

Is there any chance to translate characters words the way launcher can be translated?

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 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.

Since I think games are mostly written in a single language, I think a better approach would be to write the game in one language, and then have a translation file:
(That syntax sucks.)

This is similar to what gettext does - write in a canonical language, and then translate it. I don't like any syntax that removes the canonical text from the Ren'Py script- I think that would make initial development and maintenance a nightmare.

A very useful tool if you're going to do it that way would be an function in the launcher that generates a "blank" translation file with the original language entries, where you just replace all the text with your new translation.

But man, doing a translation file for anything but simple renpy code sounds like a complicated proposition. What about code that generates language on the spot? Should translation files be able to replace whole labels, and python objects and functions?

I think this is probably more trouble than it's worth. If you are rewriting your script, no matter what translation tool, scheme, or syntax you're using, maintaining it will be unpleasant.

If you do a translation file (as per PyTom's idea) and change any string in the original, you have to change it each one for each language. I'm personally convinced that it's a Bad Idea to have string literals treated as translation keys - it's for this reason that I don't like the config.translation functionality.

In a project I'm working with (which is written with translation in mind from the get-go) it's done using the multiple branch philosophy, by putting each language of each Act of the story into its own file, so we have act1_en.rpy, act1_es.rpy, act1_id.rpy act2_en.rpy, etc. Each language file is just a clone of the original English script. As a result, line numbers are equal from script to script, so it's easy to hop back and forth and translate them that way, since every script is formatted the same way.

To me, trying to automate translation just sounds like over-engineering. ;)

I'd expect there to be tool support for generating translation files from game script files, if we went down that route. (I'm not in any rush to do so, however.)