Never played with this game but in general
1) If you tried relative search ( https://www.romhacking.net/utilities/513/
) and using the same table seen elsewhere then seems like time for something new. Corruption is something some do (tweak parts of the ROM until you find what corresponds* to it, can be tedious), assembly methods (it has to get into memory, follow it back up the line when it does and go from there), pointer inference (search for pointers in the game, you need not know what they lead to but it is usually a quick way of finding something interesting as pointers tend not to point to nowhere of interest) and in some systems compression search (it tends to leave fingerprints) though for the megadrive it was likely custom.
Assembly is the best method but also the hardest (you need to follow along with the programming aspect after all)
*I should note if the other translation you reference changed something then whatever changed in that should be related to it. Find out what changes are not just for the main script and the rest goes from there).
2) Same as above really, though relative search will not do you much good.
3) First be sure that there are pointers. Menus quite often use other methods such as
fixed length -- "whatever it is we hope you can fit it in ? characters as that is all you get" (ever wondered why games from such eras have horribly abbreviated terms? This is that when translation teams get lazy)
delineated -- the reason this started a new line is because I pressed the enter/return key. Many games in menus will have this so it knows to go to the next term when it sees a given value. Does not work well for mainline text of many paragraphs as it takes a bit of CPU power to do but can be acceptable for use in menus.
Can also be noted length in the thing itself. If you note that the following value is 5 characters long, have those 5 characters and then another value to say this one is 4 then have those 4, then another saying 6 and have 6 characters...
The pointers can be a relative pointer setup. In this case maybe just the first thing in the list has a pointer and the rest just have lengths in a small table the game can quickly total up to find what it wants (or indeed if every time it displays such things if it knows it will also have the others then do even less calculations than that).
You also have the assembly choice again -- if it needs to find where something is on screen then it will likely be using some kind of length value, pointer value or something else. Catch it as it is drawing it on screen (or maybe putting it in VRAM to begin with -- chances are it is not there right from boot, and instead when you start a battle or something) and watch it work to see what it uses.