6.12.x: Translation Support

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Post Reply
Message
Author
User avatar
PyTom
Ren'Py Creator
Posts: 15445
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

6.12.x: Translation Support

#1 Post by PyTom » Sat Jun 18, 2011 10:37 am

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.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

User avatar
jack_norton
Lemma-Class Veteran
Posts: 4029
Joined: Mon Jul 21, 2008 5:41 pm
Completed: Too many! See my homepage
Projects: A lot! See www.winterwolves.com
Tumblr: winterwolvesgames
Contact:

Re: 6.12.x: Translation Support

#2 Post by jack_norton » Sat Jun 18, 2011 11:06 am

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 :)
follow me on Image Image Image Image
computer games

User avatar
Spiky Caterpillar
Veteran
Posts: 252
Joined: Fri Nov 14, 2008 7:59 pm
Completed: Lots.
Projects: Black Closet
Organization: Slipshod
Location: Behind you.
Contact:

Re: 6.12.x: Translation Support

#3 Post by Spiky Caterpillar » Sat Jun 18, 2011 3:32 pm

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...).
Nom nom nom nom nom LEAVES.

Counter Arts
Miko-Class Veteran
Posts: 645
Joined: Fri Dec 16, 2005 5:21 pm
Completed: Fading Hearts, Infinite Game Works
Projects: Don't Save the World
Organization: Sakura River
Location: Canada
Contact:

Re: 6.12.x: Translation Support

#4 Post by Counter Arts » Sat Jun 18, 2011 4:08 pm

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.
Fading Hearts is RELEASED
http://www.sakurariver.ca

User avatar
PyTom
Ren'Py Creator
Posts: 15445
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: 6.12.x: Translation Support

#5 Post by PyTom » Sat Jun 18, 2011 4:55 pm

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.)
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

Counter Arts
Miko-Class Veteran
Posts: 645
Joined: Fri Dec 16, 2005 5:21 pm
Completed: Fading Hearts, Infinite Game Works
Projects: Don't Save the World
Organization: Sakura River
Location: Canada
Contact:

Re: 6.12.x: Translation Support

#6 Post by Counter Arts » Sat Jun 18, 2011 6:37 pm

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.
Fading Hearts is RELEASED
http://www.sakurariver.ca

User avatar
Sexo Grammaticus
Regular
Posts: 69
Joined: Thu Jun 09, 2011 1:54 am
Projects: human instrumentality and vocals section
Location: butts
Contact:

Re: 6.12.x: Translation Support

#7 Post by Sexo Grammaticus » Sun Jun 19, 2011 5:27 am

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).
i have no signature and i must obscure game reference

User avatar
denzil
Veteran
Posts: 293
Joined: Wed Apr 20, 2005 4:01 pm
Contact:

Re: 6.12.x: Translation Support

#8 Post by denzil » Tue Jun 28, 2011 4:07 am

jack_norton wrote: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.
Practice makes purrrfect.
Finished projects: Broken sky .:. colorless day .:. and few more...

Counter Arts
Miko-Class Veteran
Posts: 645
Joined: Fri Dec 16, 2005 5:21 pm
Completed: Fading Hearts, Infinite Game Works
Projects: Don't Save the World
Organization: Sakura River
Location: Canada
Contact:

Re: 6.12.x: Translation Support

#9 Post by Counter Arts » Tue Jun 28, 2011 11:42 am

denzil wrote:
jack_norton wrote: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.
Fading Hearts is RELEASED
http://www.sakurariver.ca

User avatar
Aoide
Regular
Posts: 31
Joined: Sat Jun 11, 2011 2:40 am
Contact:

Re: 6.12.x: Translation Support

#10 Post by Aoide » Wed Jul 13, 2011 8:46 am

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.

User avatar
Anima
Veteran
Posts: 448
Joined: Wed Nov 18, 2009 11:17 am
Completed: Loren
Projects: PS2
Location: Germany
Contact:

Re: 6.12.x: Translation Support

#11 Post by Anima » Wed Jul 13, 2011 9:41 am

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.
Avatar created with this deviation by Crysa
Currently working on:
  • Winterwolves "Planet Stronghold 2" - RPG Framework: Phase III

User avatar
Aoide
Regular
Posts: 31
Joined: Sat Jun 11, 2011 2:40 am
Contact:

Re: 6.12.x: Translation Support

#12 Post by Aoide » Wed Jul 13, 2011 9:12 pm

Anima wrote: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.

User avatar
PyTom
Ren'Py Creator
Posts: 15445
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: 6.12.x: Translation Support

#13 Post by PyTom » Wed Jul 13, 2011 9:26 pm

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.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

Post Reply

Who is online

Users browsing this forum: No registered users