Download the engine again, make sure you are running 1.0.3 or above.
Use the new setLanguage(name) to set the language name. name should be the 2-letter code like en or it or es.
Change this function to…
function useTranslation(language) {
translation_table = language ? loadtsvtable("Translations_"+language+".tsv") : null
setLanguage(translation_table ? language : "en")
// dumpvar(translation_table) // Uncomment to dump the table
return translation_table ? YES : NO
}
If you have .png called foobar_en.png and another called foobar_it.png it will automatically choose the _it version if the language is set to it. All reference in .dinky code or .wimpy files must be _en.png. The translated .png will be used automatically if found.
If you’ve modified any .wimpy (or altered code) to use _it.png files, revert out of that code and the engine should do all the work for you.
Some of the art already has these, so just doing this code change should show a few of them.
Let me know if you have any issues, the feature has had no real testing in Delores. There is one other change I’ll make if this works for you is auto detecting the language of the machine. The intro ref card image should get a _en on it and then the _it version will show on launch (once I make the additional change).
If I understood correctly, now changing a frame name from foo to foo_en makes it “visible” to the translation system? So, e.g., the QuickiePalOutside.wimpy file has an object with a state that shows a frame called “front_signs_text_en”, if the language is set to “it” then it will automatically load the _it file from the spritesheet?
That is correct. But keep in mind, if you want the translation released with our next update, resist the urge go through add a lot of new frames. Each of those will have to be hand-added back to the .psd file and in the correct format with all the right tagging. When we do a build for a store, we don’t use the .png files, they are all deleted then the automated pipeline is run that extracts the .pngs from the .psd file.
Many of the .psd files already have _en, _it, etc images in them. Any new images need to be organized, grouped and labeled in the .psd exactly like existing ones or they won’t be extracted.
I’ll stick to the important ones (i.e. the text-heavy, like the intro screen) and try to work on them on the .psd files.
However, I can’t get the Quickie Pal to turn to Italian, even if the current language is Italian and the images are already there (the frames already have the _en suffix). Shouldn’t it work directly out of the box?
It should. The system hasn’t gotten a lot of testing since TWP since we didn’t use it on Delores. My quick test showed it working, but it might fail. Let me look closer at that one instace.
Would it make sense to allow loading additional sheets to existing ones, which would allow adding new sprites or replacing existing sprites without the need to change the whole base sprite sheet?
This would make adding new translations easier, especially when we are talking about a finished game.
But maybe this makes the engine unnecessary complex?
Here is an example what I mean:
QuickiePal.json is loaded, adding sprites from QuickiePal.png like background, foreground, Welcome_text_en, Welcome_text_de* etc.
Then QuickiePal_{lang}.json is loaded, possibly overriding sprites from the base sprite sheet, e.g.: QuickiePal_cz.json reads QuickiePal_cz.png and adds sprite Welcome_text_cz and overrides sprite foreground
(implementation detail: the language specific one(s) might be loaded first)
(if this feature of overriding existing sprites makes changing of translations complicated we could live without it of course, BUT it would be nice feature for modding in general)
As of now, the system doesn’t support multiple sprite sheets/room. If we were adding a lot of languages after release, it might make sense, but everything is built with a big pipeline so it doesn’t matter much and it’s a lot easier/safer to just rebuild everything. It’s a trade off on how much work we do to support something that is unlikely to happen in a real life.
That said, I have wanted to support multiple sprite sheets just because they can offer better packing.
I guess I meant “in an actual production”. You are right, something like this would help with mods, and if we ever build a game meant to be modded, I would absolutely look at something like this. Over the years, my code is riddled with features I thought would be important and never were, so now I try and build features where there is an actual immediate use.
I played around trying to understand why it doesn’t work, and it seems like the system is only translating on the fly the frame called front_signs_neon_text_en.
If I add this to other props or objects, even unchanged, I get the Italian image.
But I tried then with front_signs_text_en, maps_banner_lit_text_en and they don’t work. Interestingly enough, maps_banner_text_en works fine.
@RonGilbert while we’re at it, can you share the script you use to extract the images from the .psd files and obtain the texture packs? There’s only the one that packs all PNGs, but nothing for psd. As I’d like to begin with the images, I want to be sure that I’m doing the things the correct way.
I’ll check them into the repo in a subfolder of bin. They are all python, so with a little work you should be able get them working.
For the _en.png to be translated, the _en.png must be attached to an object and that must appear in the .wimpy file. I haven’t looked at those specifically to see what might be wrong.
I tried with the quickie pal lights. The same object changes correctly if I use the “lit text” name, and if I use the “unlit maps banner”, but doesn’t if I use the unlit text or the lit maps banner. It seems like some frame names don’t get recognized by the translation system
