6.12.x: Translation Support

[PyTom]

To elaborate my thoughts on translation:

The basic approach to translation will be to have a file mapping source-language strings to target language strings. I'm not sure (and would appreciate feedback from translators about) if there should also be some context information, like a unique identifier for each line of dialogue in the game.

By default, a translations file (translations.rpt?) will be loaded whenever Ren'Py starts up, if it exists. The creator will be able to specify an alternate list of translation files to load, which will allow multiple languages to be shipped as part of a game - or to specify that no translation file will be loaded at all.

Translation will take place at two places, the same two places substitutions will take place in newtext. The first is as part of the processing of a say statement - the "what" text will be translated before it is shown to the user. The Text displayable will also translate text, if it has not already been translated.

Two text tags will be added, {split} and {ignore}. These will only apply to say statements. The former will break a say statement up into two psuedo-say statements. (Rollback might roll over both at once, but apart from that they'll look like two lines of dialogue.) The latter will prevent the line of dialogue from displaying at all. This gives translators the freedom to split, combine, and eliminate lines of dialogue.

The new launcher will have the function to dump the text from a game into a translations file. This will only be possible when each .rpyc file loaded by the game has a corresponding .rpy file. The translations will be updated as necessary, if they already exist.

[jack_norton]

I never did any translation for my games so far, but if I was doing it I would:
1. dump all the game dialogue strings using dump_text.rpy you wrote a time ago (don't know if it's somewhere in Renpy website/cookbook but I still have it if needed), leaving an empty line after each say statement. This way the output is a single text file that you can copy and paste in a spreadsheet, so translators will have the source text and will also have an empty line to write the translated text.
2. each file could be a .rpt like italian.rpt, german.rpt and so on, perhaps would be nice to have the possibility to change the language in the options screen? you could define standard .rpt filenames to use or have a template.
3. I remember a similar thing was done by Spiky Caterpillar so maybe he can be of help

[Spiky Caterpillar]

I don't think that unique identifiers should be auto-added by default, because that will likely clutter up source or break things if the script changes after translation, but we should be able to add them manually.

IMO, it will produce more robust code if the identifiers live in the .rpy (player "{identifier=ore}I..." ) rather than the translation file ({act3.rpy:1042}I...\nOre...).

[Counter Arts]

I think it would useful to have a decorator or "id" of identifying the next say statement.

Code: Select all

alex id scene20-23 "Itadakimasu is hard to translate to English"
id scene20-23 voice "scene20-23.ogg"
ryan "But Alex... we have to insert more lines into this localization!"

This could also be very useful for handling voice acting line identification. I'm not a voice actor so maybe asking a voice actor/actress about it could be useful.

[PyTom]

I like both ideas. My gut feeling is that - at least for translations - the ids should be optional. They'd only be useful when Ren'Py needs to disambiguate between two say statements with the same text that need to have different translations. (That should be pretty rare, in practice.)

[Counter Arts]

Haha... programming some really funky C# with decorators and reflection gave me those ideas. Yeah... ids should definitely be optional.

Another idea to give flexiblity for translators as they might need to insert new lines is to allow something like an "say id" block in the translation file to replace the single say statement. It might be a bit weird for rollback though. I wouldn't allow anything but say statements though.

For the different translations of the same text, you really have to consider that they are also context sensitive. Sayings might not exist for all localizations so they may have to use something else. This is just a use case I thought of.

[Sexo Grammaticus]

There are universal codes for different languages - I'd be happy to be able to wrap statements in tags for one of these (preferably IETF).

[denzil]

I never did any translation for my games so far, but if I was doing it I would:
1. dump all the game dialogue strings using dump_text.rpy you wrote a time ago (don't know if it's somewhere in Renpy website/cookbook but I still have it if needed), leaving an empty line after each say statement. This way the output is a single text file that you can copy and paste in a spreadsheet, so translators will have the source text and will also have an empty line to write the translated text.

Having done few translations of Ren'Py VNs, this is pretty close to how I do it nowadays:
1. Copy contents of .rpy file into spreadsheet (including code and indentation - saves me time later and I can modify code too where necessary). One column is for original version, one for translation.
2. Translate it
3. Export as .csv file, use python script to convert it into .rpy file. Because I kept all the code and indentation from the original version the python script can take care of adding it into the translation.

[Counter Arts]

I never did any translation for my games so far, but if I was doing it I would:
1. dump all the game dialogue strings using dump_text.rpy you wrote a time ago (don't know if it's somewhere in Renpy website/cookbook but I still have it if needed), leaving an empty line after each say statement. This way the output is a single text file that you can copy and paste in a spreadsheet, so translators will have the source text and will also have an empty line to write the translated text.

Having done few translations of Ren'Py VNs, this is pretty close to how I do it nowadays:
1. Copy contents of .rpy file into spreadsheet (including code and indentation - saves me time later and I can modify code too where necessary). One column is for original version, one for translation.
2. Translate it
3. Export as .csv file, use python script to convert it into .rpy file. Because I kept all the code and indentation from the original version the python script can take care of adding it into the translation.

Wow... that is an awesome way to do it.

If I were to do it now I would just separate all game logic code (which is a lot) from the scene files. Most of my game logic just calls the labels of the scenes anyways.

I should combine your spreadsheet method with my scene/code separation method.

[Aoide]

I'm in the process of developing a multilingual game (Japanese/English), so I've been putting work into various frameworks (a multilanguage framework and various other frameworks for characters and whatnot that work with multilingual code) and I've run into a few problems:

1. There doesn't seem to be a way to switch languages without rebooting the game client. While I'm still new to the Ren'Py system, from what I've seen a good fix for this would be to store all possible translations instead of overwriting (ex. putting the relevant code into config.translations["en"] and config.translations["jp"]) and using the persistent.lang to determine which table to read data from.
2. There doesn't seem to be a way to add an item to a screen from a different file than where the screen object is declared. Apparently there was a function to do this in the older Ren'Py versions (as it's in the Cookbook entry), but it doesn't work with newer ones that use the "screen" definition. This makes it very hard to make a framework that works like a plugin (ie. copy the files to your game directory and everything works) and instead forces you to use a hack (ie. ask users to copy/paste certain code to a place in their own code) in order to allow users to switch languages from the main menu. It would be great if future implementations of the screen would allow for adding modules to it from external files.

The project I'm working on now is being built around the currently available method that uses a condition switch to determine which language to use, which is the method that works best with the way that I organize my code. But one thing that I would like to see kept from how things are now is the flexibility that allows people to chose the method that suits them best.

[Anima]

There doesn't seem to be a way to add an item to a screen from a different file than where the screen object is declared. Apparently there was a function to do this in the older Ren'Py versions (as it's in the Cookbook entry), but it doesn't work with newer ones that use the "screen" definition. This makes it very hard to make a framework that works like a plugin (ie. copy the files to your game directory and everything works) and instead forces you to use a hack (ie. ask users to copy/paste certain code to a place in their own code) in order to allow users to switch languages from the main menu. It would be great if future implementations of the screen would allow for adding modules to it from external files.

You can simply overwrite the screen.
Put a screen with the same name into a init block with a higher number and that screen will be used instead.

[Aoide]

You can simply overwrite the screen.

That still makes it work like a hack, though, because the new menu would overwrite whatever changes the user has made to their menu. Not to mention that it would be repetitive code; overwriting the entire menu means copying/pasting several lines of code in order to add only one button.

What I'm looking for is a way to append a child element to an existing screen from an outside source file. The ability to do that, especially if there was a way to give some rudimentary control over where in the box it was displayed, would help not just with making Ren'Py more modular (and therefore plugin friendly), but also make screens even more flexible (and therefore powerful) than they already are.

[PyTom]

UnicornStudios, we used to have the sort of approach that you wanted. Many of the layouts had the ability to plug things in based on configuration variables. We moved away from this because it's hard-to-impossible to figure out, in advance, all of the ways that the user might want to extend things. By making screens that the user is expected to edit, we don't need another complex configuration system.

I get the point about drop-in plugins - but that's actually really hard to achieve. The top-tier Ren'Py games are all using imagemaps or otherwise heavily customizing the interface, to the point where a plugin that tries to automatically update the screens would prove counterproductive.