TestRunnerSRL
A setting to change the language of the game to Any language
A setting to play the randomized oot in Japanese.
Below this is the file informations.
textJP.py Raw text of OOT JProm with some transformation for texts
data/titleJP.bin title.bin for JP rom title screen
Below this is the major definitions I made.
parsejp(text, mode = 0) parse the Encoded JPtext (mode 0 = tag, 1 = ending)
text_to_bytes(text, width, signed=False) convert Encoded JPtext to int and to an array of bytes of the given width
JPencode(text, mode = 0, replace_chars=True) encode JPtext written in Japanese and additional CONTROL_CHARS (mode = 0 normal, 1 scrub, 2 item) when its mode is 2, CONTROL_CHARS are written differently due to icon bytes
update_message_jp(messages, id, text, opts=None, mode = 0) write Encoded JPtexts to temporal.py (mode = 0 normal, 1 scrub, 2 item) template: (id{:04x}): ((Encoded JPtext), (opts), (tags), (ending)),
shuffle_messages_jp(messages, except_hints=True, always_allow_skip=True) mostly identical function to def shuffle_messages. (return is shuffled groups)
write_messages(rom, shuffle = False, shuffle_group = None) write all texts inside temporal.py to the rom (when shuffle = True, need shuffle_messages_jp)
I already played several times to ensure that this one doesn't have any sort of unintentional glitch or crashes caused by that. But if you find it, please comment in this section.
Why is the overall Readme of the project modified to include information from a single PR? Seems unnecessary
Having a separate Hints.py and Patches.py for every language we'll add in the future doesn't seem terribly sustainable or maintainable (although I could be wrong), especially since we'll likely be adding several other languages after this PR (Almost certainly French, German, Spanish, and Chinese, based on what I've seen in the server). Since both of those files are less "Add this text here" and more "Do this thing in the code", is it possible to just have one file for each?
Obviously we can't condense hintslist.py and hintslistJP.py (or any other file that's 90% "Insert this text into the ROM") into a single file since that'll be a trillion times long by the time we're done with it, but I'd assume we could condense Hints.py and hintsjp.py, and patches.py and patchesJP.py into a single file each.
Having a separate Hints.py and Patches.py for every language we'll add in the future doesn't seem terribly sustainable or maintainable (although I could be wrong), especially since we'll likely be adding several other languages after this PR (Almost certainly French, German, Spanish, and Chinese, based on what I've seen in the server). Since both of those files are less "Add this text here" and more "Do this thing in the code", is it possible to just have one file for each?
Obviously we can't condense hintslist.py and hintslistJP.py (or any other file that's 90% "Insert this text into the ROM") into a single file since that'll be a trillion times long by the time we're done with it, but I'd assume we could condense Hints.py and hintsjp.py, and patches.py and patchesJP.py into a single file each.
With using the method I use to create textJP.py, I think we can make same kind of files with all sort of languages.
The reason why I separated to 2 files and didn’t condense (such as patches.py and patchesJP.py) is because in the future, when we’ll add more languages inside this,I’m sure that the file is going to be too big to load or edit it.
Having a separate Hints.py and Patches.py for every language we'll add in the future doesn't seem terribly sustainable or maintainable (although I could be wrong), especially since we'll likely be adding several other languages after this PR (Almost certainly French, German, Spanish, and Chinese, based on what I've seen in the server). Since both of those files are less "Add this text here" and more "Do this thing in the code", is it possible to just have one file for each? Obviously we can't condense hintslist.py and hintslistJP.py (or any other file that's 90% "Insert this text into the ROM") into a single file since that'll be a trillion times long by the time we're done with it, but I'd assume we could condense Hints.py and hintsjp.py, and patches.py and patchesJP.py into a single file each.
With using the method I use to create textJP.py, I think we can make same kind of files with all sort of languages.
The reason why I separated to 2 files and didn’t condense (such as patches.py and patchesJP.py) is because in the future, when we’ll add more languages inside this,I’m sure that the file is going to be too big to load or edit it.
The problem with that is if we make a change to something in patches.py that has nothing to do with the languages at all (say...changing a flag from a temp to a perm), we then need to make that same change another dozen times.
It might be worth splitting patches.py into two files - languagepatches.py and patches.py? That way the majority of the code changes get made to a single file, while the language-specific ones are all separate? I don't know if that's a direction the dev team wants to go in, but it'd solve the issue of having to duplicate non-language changes across every file.
Having a separate Hints.py and Patches.py for every language we'll add in the future doesn't seem terribly sustainable or maintainable (although I could be wrong), especially since we'll likely be adding several other languages after this PR (Almost certainly French, German, Spanish, and Chinese, based on what I've seen in the server). Since both of those files are less "Add this text here" and more "Do this thing in the code", is it possible to just have one file for each? Obviously we can't condense hintslist.py and hintslistJP.py (or any other file that's 90% "Insert this text into the ROM") into a single file since that'll be a trillion times long by the time we're done with it, but I'd assume we could condense Hints.py and hintsjp.py, and patches.py and patchesJP.py into a single file each.
With using the method I use to create textJP.py, I think we can make same kind of files with all sort of languages. The reason why I separated to 2 files and didn’t condense (such as patches.py and patchesJP.py) is because in the future, when we’ll add more languages inside this,I’m sure that the file is going to be too big to load or edit it.
The problem with that is if we make a change to something in patches.py that has nothing to do with the languages at all (say...changing a flag from a temp to a perm), we then need to make that same change another dozen times.
It might be worth splitting patches.py into two files - languagepatches.py and patches.py? That way the majority of the code changes get made to a single file, while the language-specific ones are all separate? I don't know if that's a direction the dev team wants to go in, but it'd solve the issue of having to duplicate non-language changes across every file.
I think adding language definition to patch_rom itself would be better. Something like: patch_rom(spoiler, world, rom, lang) And for the texts to add:
if lang is (“English”, “Japanese” etc..): (Excute message update thing) elif lang is ...
something like that would solve every problem.
You could also make something like a Text class for all text that's inserted into the game, where the class has either an array of text for each language or just an English, Japanese etc. property. HintList instead of taking a string as the hint text will take a Text object that defines both languages, and it decides whether to use the English or Japanese text at patch time depending on the setting.
I tried my best to compile 2 files to 1 (Like Patches.py and PatchesJP.py). works fine for most part. but when it comes to shop items, it doesn't work at all. it doesn't place the item (now it's blank) and soon after that, the game place error text. I don't know how to fix that. so, I'm just going leave that for now (at least) . But anyway, I fixed some texts. and I actually managed to remove about 70% of text speed differences.
You could also make something like a Text class for all text that's inserted into the game, where the class has either an array of text for each language or just an English, Japanese etc. property. HintList instead of taking a string as the hint text will take a Text object that defines both languages, and it decides whether to use the English or Japanese text at patch time depending on the setting.
I'm pretty sure this is the route we would have to take in the long run. All translatable text needs to be separated from logic bearing things, so this doesn't turn into a maintainability nightmare.
You could also make something like a Text class for all text that's inserted into the game, where the class has either an array of text for each language or just an English, Japanese etc. property. HintList instead of taking a string as the hint text will take a Text object that defines both languages, and it decides whether to use the English or Japanese text at patch time depending on the setting.
I'm pretty sure this is the route we would have to take in the long run. All translatable text needs to be separated from logic bearing things, so this doesn't turn into a maintainability nightmare.
So I tried again to compile 2 files to 1, and for the Patches.py, it actually worked! Unfortunately, I don't think Hints.py, HintList.py, and Messages.py are able to combine with the JP versions because of the amount of differences. so what I thought is leaving those files separated, and in the future, when we add more languages, we'll take those separated files as parent files, and as sub file, take the new file called something like lang(Country name in 2 or 3 characters).py inside Lang file. this is just an idea, but it would be easier to make translations.
Hi! It's been a while, I finally managed to compile Messages, Hints and HintList with its JP versions! In addition, I made line wrap program and a program to align the JP text to center, left and right! for texts, it is now fully supported for shuffle text and warp song.
I made some codes to get texts from other files using dynamic import.
These are new codes (and files) I added.
data/make diff.py Make diff file from 2 data (original data and changed data)
ListE.py Example table for extra language text file
Below this is the tree structure of extra language file.
(Language File)
|-----ListX.py
|-----data
|--------title.bin
|--------etc...
The approach of passing in a language data file won't work for most languages. There is already some code in this PR that fixes what I assume are grammatical errors arising from simply pasting bits of Japanese text together, and many other languages would require similar considerations. (English is fairly light on those requirements, but even there we already do things like changing “Ganon's castle” to “my castle” in text spoken by Ganondorf.) I think it would be better to remove the “extra language” feature and instead encourage people who want to translate the randomizer to contribute code or collaborate with contributors to make things work. To keep the code organized, I would recommend placing all the code that generates user-visible text in one central module, moving the text itself (including the English text) to JSON files in the data directory, and avoiding handling anything language-specific anywhere else.
There is also the concern of what to do when a new feature is added by a contributor who doesn't speak Japanese. Expecting the entire randomizer to be fully translated at all times could significantly hinder development (especially if more languages are added in the future), so instead there should be automatic fallbacks to English text for every missing translation, perhaps combined with a way to query the randomizer for missing translations so that volunteers can get an overview of text to add.
It might make sense to combine such a refactor of user-facing text for translation support with the refactor mentioned in https://github.com/TestRunnerSRL/OoT-Randomizer/issues/1525#issuecomment-1060058818.
Unfortunately this PR is unlikely to be merged in its current form, but we're going to be making an issue for tracking a translation project, and a lot of the work done here is definitely helpful for that project.