Ren'Py Two Quick Menus

iOtero

Active Member
Aug 4, 2020
925
1,459
Hi, I don't know if this is the right place to ask this, but if it isn't, have the moderator move it to the right place.

I am translating to Spanish a renpy game in English and I want the quick menu of the Spanish version to be different from the English one without modifying the original files.

I have created this "patch.rpy", that I put in the /game/tl/spanish folder:

Code:
init 999:

    screen quick_menu():
    
        zorder 100

        if quick_menu:

            hbox:
                style_prefix "quick"

                xalign 0.5
                yalign 1.0

                textbutton _("Retroceder") action Rollback()
                textbutton _("Historial") action ShowMenu('history')
                textbutton _("Auto") action Preference("auto-forward", "toggle")
                textbutton _("Saltar") action Skip()
                textbutton _("Salto directo") action Skip(fast=True, confirm=True)
                textbutton _("Cargar ya") action QuickLoad()
                textbutton _("Guardar ya") action QuickSave()
                textbutton _("Cargar") action ShowMenu('load')
                textbutton _("Guardar") action ShowMenu('save')
                textbutton _("Preferencias") action ShowMenu('preferences')
                textbutton _("Ocultar") action HideInterface()
                textbutton _("Salir") action Quit(confirm=not main_menu)
The language is not a problem, the problem is that when I change the language, the quick menu is always the one of the patch, and what I want is that when the game is in English you see the original quick menu of the game, and when the game is in Spanish, you see the quick menu of the patch.rpy.

What am I doing wrong?

Thanks for the help.
 

rayminator

Engaged Member
Respected User
Sep 26, 2018
3,041
3,140
you want to use config.overlay_screens.append = [ ... ] I think, I might be wrong

something like this
Code:
init 999 python:
  config.overlay_screens.append( "quick_menu" )
 
  • Like
Reactions: iOtero

79flavors

Well-Known Member
Respected User
Jun 14, 2018
1,581
2,219
You don't need to do any of that.

If you go into the RenPy launcher, you can pick the option [Generate Translation].

Type in the name "spanish" into the name of the new language, then pick the [Extract String Translations]. If you're doing this a second (or more) time, then pick [Merge String Translations] instead.

Then just go into the /tl/spanish/*.rpy files and type in the the spanish translations.

Included in /tl/spanish/screens.rpy is all the translations for all the screens defined there.... including the screen quick_menu():. So there are your quick_menu translation, without altering any of the english code.

Then all you need is something in the code that does renpy.change_language("spanish") and off you go... Tu juego no se ejecuta en español.
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
10,360
15,270
Included in /tl/spanish/screens.rpy is all the translations for all the screens defined there.... including the screen quick_menu():. So there are your quick_menu translation, without altering any of the english code.
It should be good according to the code he gave, but he should ensure that all the entries of the original quick menu are wrote with the _( [...] ) syntax. Else they will not be part of the translation file.


Tu juego no se ejecuta en español.
"no" have the same meaning in Spanish than in English ;)
So: si, es juego esto ahora(? :/) en español.
 
  • Like
Reactions: iOtero

79flavors

Well-Known Member
Respected User
Jun 14, 2018
1,581
2,219
[...] but he should ensure that all the entries of the original quick menu are wrote with the _( [...] ) syntax. Else they will not be part of the translation file.

Maybe that's what's broken in the original game he's working on. But his "new" spanish patched version includes the underscores... that implies to me that the original also included the underscores... which means a "normal" translation should do the translation he wants without touching the original code.

This is what a "standard" quick menu looks like:

You don't have permission to view the spoiler content. Log in or register now.

Maybe the original doesn't looks like that... in which case maybe all it needs is those underscores ( "_" ) adding?

Either way, I'm still not sure why this needs a patch as a solution when RenPy already has a fully working translation solution.
 
  • Like
Reactions: iOtero

moskyx

Forum Fanatic
Jun 17, 2019
4,005
12,959
He want to have a different quick menu, not just a translated one. That wouldn't be an issue
 
  • Like
Reactions: iOtero

moskyx

Forum Fanatic
Jun 17, 2019
4,005
12,959
that's how I read it
He's an experienced translator but also likes to mod games to add them his own flavour, and I guess that what he's trying to do here. So I think your solution is closer to what he's looking for.

About the _( ), it just lets Ren'Py SDK to automatically extract the strings but nothing else (at least in this case; text variables might need it to work properly, though). But for menu options, you could just write the strings manually in the tl file and they will be translated even if in the original file the strings are not written between that symbol.
 
  • Like
Reactions: iOtero

79flavors

Well-Known Member
Respected User
Jun 14, 2018
1,581
2,219
He want to have a different quick menu, not just a translated one. That wouldn't be an issue

Ah. I was probably reading too quickly and being thrown off by the Spanish version being almost the same as the English one, except... you know... Spanish.

What am I doing wrong?
Your basic problem is that your patch.rpy file (no matter which folder it is in) is completely replacing the standard screen quick_menu() due to the init 999:.

init: code is just initialization code. It runs before the main game starts.
So that there can be more than one init: block and the programmer can control what order those blocks are run in... there's the number afterward.

init 0: is the default. Anything with a minus number is run BEFORE init 0:, anything higher than 0 is run AFTER init 0:. How big or small the numbers control when each are run compared with the other init: blocks.

So in your case, 999 is trying really hard to be the last thing run before the game starts for real. Anything that happens there, overwrites anything that happened earlier.

So the screen quick_menu(): in the screens.rpy will create a screen called "quick_menu" during init 0:.
Then your patch comes along and creates a replacement screen quick_menu(): during init 999: - effectively overwriting the original definition.

... So you get your Spanish language version regardless of the language selected.

I guess it really comes down to what you mean what you say...

I want the quick menu of the Spanish version to be different from the English one [...]

Because if you just want Spanish words instead of English ones... then my post back here explains that. Which is basically "use the normal translation process" like you would any other text.

Except other people point out you're an experienced translator and you're not actually doing something that simple.
Bahh. I'm SO late in noticing this... but you've actually added extra buttons onto the quick_menu in your version.

So... Move your patch.rpy back into the main /game/ folder, then rewrite it to look something like this:

Python:
init 1:
    screen quick_menu():

        ## Ensure this appears on top of other screens.
        zorder 100

        if quick_menu:

            if preferences.language != "spanish":
    
                hbox:
                    style_prefix "quick"

                    xalign 0.5
                    yalign 1.0

                    textbutton _("Back") action Rollback()
                    textbutton _("History") action ShowMenu('history')
                    textbutton _("Skip") action Skip() alternate Skip(fast=True, confirm=True)
                    textbutton _("Auto") action Preference("auto-forward", "toggle")
                    textbutton _("Save") action ShowMenu('save')
                    textbutton _("Q.Save") action QuickSave()
                    textbutton _("Q.Load") action QuickLoad()
                    textbutton _("Prefs") action ShowMenu('preferences')

            else:

                hbox:
                    style_prefix "quick"

                    xalign 0.5
                    yalign 1.0

                    textbutton _("Back") action Rollback()
                    textbutton _("History") action ShowMenu('history')
                    textbutton _("Auto") action Preference("auto-forward", "toggle")
                    textbutton _("Skip") action Skip()
                    textbutton _("Q.Skip") action Skip(fast=True, confirm=True)
                    textbutton _("Q.Load") action QuickLoad()
                    textbutton _("Q.Save") action QuickSave()
                    textbutton _("Load") action ShowMenu('load')
                    textbutton _("Save") action ShowMenu('save')
                    textbutton _("Prefs") action ShowMenu('preferences')
                    textbutton _("Hide UI") action HideInterface()
                    textbutton _("Quit") action Quit(confirm=not main_menu)

The basics of what I've done here is that I've said "If the language is NOT Spanish, use a copy of the standard quick_menu. Otherwise (if it IS Spanish) use the your expanded quick_menu". Both menus are in English (because the base game is English). I'm then suggesting that you then use the standard translation processes to convert all the text here (including the text in the expanded quick_menu) to Spanish.

I've used init 1: rather than init 999: because honestly, as long as it's above 0 (zero) - it'll still overwrite the original screen definition.

You'll still need to do the normal translation process via the RenPy launcher, but when you do - you should find a /game/tl/spanish/patch.rpy file which only contains translate lines.

Then just put the translation lines in for things like "Q.Skip" -> "Salto directo", etc. into the /tl/ files and things should work how you planned.

*I think*.

I've done a brief test using this code and changing the language with the game already running... and it works exactly how you would expect, with the new layout being used when the right language is selected.

You might want to consider removing the whole section I'm thinking of as the "English Quick Menu" (that is the section after if preferences.language != "spanish": and ONLY using your extended quick menu options for both the english and spanish versions. It won't require altering the baseline code and I'm sure English speakers using your patch won't object to a few extra quick menu options to choose from.
 
Last edited:
  • Like
Reactions: iOtero

iOtero

Active Member
Aug 4, 2020
925
1,459
He's an experienced translator but also likes to mod games to add them his own flavour, and I guess that what he's trying to do here. So I think your solution is closer to what he's looking for.

About the _( ), it just lets Ren'Py SDK to automatically extract the strings but nothing else (at least in this case; text variables might need it to work properly, though). But for menu options, you could just write the strings manually in the tl file and they will be translated even if in the original file the strings are not written between that symbol.
Exactly, I wouldn't have explained it better, thanks Moskyx. (y)
 

iOtero

Active Member
Aug 4, 2020
925
1,459
You might want to consider removing the whole section I'm thinking of as the "English Quick Menu" (that is the section after if preferences.language != "spanish": and ONLY using your extended quick menu options for both the english and spanish versions. It won't require altering the baseline code and I'm sure English speakers using your patch won't object to a few extra quick menu options to choose from.
I have thought about it. But I want to respect the original code as much as possible. I also like, as Moskyx says, to give my own flavor to the translations, but the original code, unless I make a mod or a new version of the game, I prefer to respect it as much as possible.

Thanks a lot for your help, I still can't get it to work, but I'm still working on it.
 

iOtero

Active Member
Aug 4, 2020
925
1,459
Thank you all very much for your help. Especially to 79flavors because their code works perfectly. (y)

At the beginning it didn't work because the game already has a patch.rpyc file (that the unren.bat is not able to decompile), but with changing the name from patch.rpy to parche.rpy everything was fixed. ;)
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
10,360
15,270
He want to have a different quick menu, not just a translated one. That wouldn't be an issue
But why ? There's no interest in having two quick menu, even in two different languages, when the translated one include the untranslated one.

Just rewriting the "quick_menu" screen, and making it created after the original one, is enough. Anyone using the translated version will have the translated and extended quick menu, without the, became totally useless, untranslated one.
 
  • Like
Reactions: iOtero

79flavors

Well-Known Member
Respected User
Jun 14, 2018
1,581
2,219
At the beginning it didn't work because the game already has a patch.rpyc file (that the unren.bat is not able to decompile), but with changing the name from patch.rpy to parche.rpy everything was fixed. ;)

Edit: This reply is assuming that the "extra" patch.rpyc file that was causing you problems was your own. If it's part of the base game... you can ignore the rest of this post - because I assume it's some sort of incest patch or something that already existed before you started your Spanish translation.


The .rpyc files are just compiled versions of the source code .rpy files. The game only uses .rpyc files when it runs, but will rebuild them if it detects an updated version of the matching .rpy file. The .rpy files can be omitted completely (and often are).

If it had been me, I would have deleted both the patch.rpy AND patch.rpyc (because they belong together) from the /game/tl/spanish/ folder. Then created a new patch.rpy in the /game/ folder and copy/pasted the code from the thread above.

My worry now is that you have /game/patche.rpy, /game/patche.rpyc AND a /game/tl/spanish/patch.rpyc file. Or maybe all the files are in the /tl/spanish folder.

But if that patch.rpyc still exists somewhere, it will still being run.

My best guess (IF I'm right about there still being a patch.rpyc file somewhere) is that the following is happening.
  • screen quick_menu created at init 0: within /game/script.rpyc.
  • screen quick_menu re-created at init 999: within /game/tl/spanish/patch.rpyc.
  • screen quick_menu re-created again at init 999: within /game/patche.rpyc.
Honestly, this is me just worrying about something that MIGHT be happening. I'm trying to think about the sort of things that could go wrong when I do stuff and assuming that if it could happen to me, it could happen to someone else.

IF (and it's a big if) this is happening, the only reason things are working as intended is that "patche" is alphabetically after "patch" and both sets of code are defined at init 999.

My assumptions are based on the fact you've said you needed to create a "patche.rpy" rather than just deleting the "patch.rpyc" file.
 
Last edited:
  • Like
Reactions: iOtero

iOtero

Active Member
Aug 4, 2020
925
1,459
Edit: This reply is assuming that the "extra" patch.rpyc file that was causing you problems was your own. If it's part of the base game... you can ignore the rest of this post - because I assume it's some sort of incest patch or something that already existed before you started your Spanish translation.


The .rpyc files are just compiled versions of the source code .rpy files. The game only uses .rpyc files when it runs, but will rebuild them if it detects an updated version of the matching .rpy file. The .rpy files can be omitted completely (and often are).

If it had been me, I would have deleted both the patch.rpy AND patch.rpyc (because they belong together) from the /game/tl/spanish/ folder. Then created a new patch.rpy in the /game/ folder and copy/pasted the code from the thread above.

My worry now is that you have /game/patche.rpy, /game/patche.rpyc AND a /game/tl/spanish/patch.rpyc file. Or maybe all the files are in the /tl/spanish folder.

But if that patch.rpyc still exists somewhere, it will still being run.

My best guess (IF I'm right about there still being a patch.rpyc file somewhere) is that the following is happening.
  • screen quick_menu created at init 0: within /game/script.rpyc.
  • screen quick_menu re-created at init 999: within /game/tl/spanish/patch.rpyc.
  • screen quick_menu re-created again at init 999: within /game/patche.rpyc.
Honestly, this is me just worrying about something that MIGHT be happening. I'm trying to think about the sort of things that could go wrong when I do stuff and assuming that if it could happen to me, it could happen to someone else.

IF (and it's a big if) this is happening, the only reason things are working as intended is that "patche" is alphabetically after "patch" and both sets of code are defined at init 999.

My assumptions are based on the fact you've said you needed to create a "patche.rpy" rather than just deleting the "patch.rpyc" file.
I can't delete the original game file patch.rpyc because the original game script.rpy refers to its content. With the name change I have made I have skipped that difficulty. Thanks. (y)
 

iOtero

Active Member
Aug 4, 2020
925
1,459
But why ? There's no interest in having two quick menu, even in two different languages, when the translated one include the untranslated one.

Just rewriting the "quick_menu" screen, and making it created after the original one, is enough. Anyone using the translated version will have the translated and extended quick menu, without the, became totally useless, untranslated one.
I don't want to make an extended quick_menu, I've only put it here as an example. What I want is to respect the original English version as much as possible and to be able to return to it from the Spanish version (and vice versa), without seeing any change.
In the Spanish version the quick menu will be graphic. If the author sees it and wants it, he is free to incorporate the graphic quick menu in his original game, but I am not going to modify its code, except to add the English/Spanish language option. Thank for your help. (y)
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
10,360
15,270
What I want is to respect the original English version as much as possible and to be able to return to it from the Spanish version (and vice versa), without seeing any change.
In the Spanish version the quick menu will be graphic.
I suspect that the reason why I, and probably also 79flavors, failed to understand your problem is because the issue is only in your approach, and nowhere else.
If I finally understood what you want, and so if it's to have a screen displayed in place of another, depending of the context, there's absolutely no problem here. And I mean, really no problem at all, it's even one of the easiest possible thing. It happen that the screen is the quick menu, but it's an insignificant and unrelated detail, and it happen that the context is the language of the game, but it's also an insignificant and unrelated detail.

You define a screen with your graphic buttons, and when the player will change the language, you hide the screen you don't want, and show the one you want, dot.

Basically something like :
Code:
menu languageSelection:
    "What language do you want ?"
    "English":
        $ renpy.change_language( None )
        hide screen "spanishQuickMenu"
        show screen "quick_menu"
        return
    "Spanish":
        $ renpy.change_language( "spanish" )
        show screen "spanishQuickMenu"
        hide screen "quick_menu"
        return
    "Cancel":
        return

screen spanishQuickMenu():
    [whatever you want]
And that's all. It's done and don't need something more.
 

iOtero

Active Member
Aug 4, 2020
925
1,459
I suspect that the reason why I, and probably also 79flavors, failed to understand your problem is because the issue is only in your approach, and nowhere else.
If I finally understood what you want, and so if it's to have a screen displayed in place of another, depending of the context, there's absolutely no problem here. And I mean, really no problem at all, it's even one of the easiest possible thing. It happen that the screen is the quick menu, but it's an insignificant and unrelated detail, and it happen that the context is the language of the game, but it's also an insignificant and unrelated detail.

You define a screen with your graphic buttons, and when the player will change the language, you hide the screen you don't want, and show the one you want, dot.

Basically something like :
Code:
menu languageSelection:
    "What language do you want ?"
    "English":
        $ renpy.change_language( None )
        hide screen "spanishQuickMenu"
        show screen "quick_menu"
        return
    "Spanish":
        $ renpy.change_language( "spanish" )
        show screen "spanishQuickMenu"
        hide screen "quick_menu"
        return
    "Cancel":
        return

screen spanishQuickMenu():
    [whatever you want]
And that's all. It's done and don't need something more.
This is another good possibility. I will keep the code because it will be useful to me, thank you very much.

And I'm sorry I didn't explain myself better from the beginning.
 

anne O'nymous

I'm not grumpy, I'm just coded that way.
Modder
Donor
Respected User
Jun 10, 2017
10,360
15,270
And I'm sorry I didn't explain myself better from the beginning.
You don't have to be sorry. It's not always easy to understand the problem, especially when you don't necessarily know the subject.
I've been a little rude in my answer, but it wasn't against you. It's more for, hmm, let's say "the lesson to stick". You'll remember more easily that sometime the misunderstanding isn't from the one(s) you answer, but from the description of the issue. It can even make you question this description beforehand, and find the answer by yourself.
 
  • Like
Reactions: iOtero