A setting to change the language of the game to Any language

[JackTriton]

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.

[aofengen]

Why is the overall Readme of the project modified to include information from a single PR? Seems unnecessary

[cjohnson57]

Just wanna say this is a huge amount of work, great job on it!

[DuskTheUmbreon]

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.

[JackTriton]

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.

[DuskTheUmbreon]

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.

[JackTriton]

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.

[cjohnson57]

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.

[JackTriton]

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.

[JackTriton]

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...

[fenhl]

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.

[fenhl]

It might make sense to combine such a refactor of user-facing text for translation support with the refactor mentioned in #1525 (comment).

[cjohnson57]

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.