FDS games are noted as containing files rather than being one big lump (prior to the DS if it was not on an optical drive or floppy drive it was probably a lump) so you would want to start with that.
I don't know what the suggested tool is these days but http://www.romhacking.net/?page=utilities&category=&platform=&game=&author=&os=&level=&perpage=20&title=&desc=fds&utilsearch=Go
should feature a few. Hopefully you get some nice file names, extensions, directory names and file sizes to narrow things down (dialogue.file in a folder called script being overly optimistic but better than those looking at a lump of code featuring game's programming, levels, graphics, music and text, and maybe nothing used at all by the game but left in by the devs).
Somewhere in these probably will be some way the text is represented that you in turn need to alter. It is rarely that simple and at least one of the following things will make life more fun. Said following things include compression, font alterations, pointers, text as graphics (I send you a nice BMP image with some text in it and you can't exactly get a cursor up to edit it),
In the ideal case you would have basic table finding* and pointers** to deal with, and many games from that era are that with fonts being the next thing (Japanese is not a Roman character using language so might not have included them -- when your memory is usefully measured in kilobytes you don't need to be including things you won't be using).
After that http://www.romhacking.net/start/
is there for a reason.
*yeah you are right about it being a binary equivalent. I usually describe it with an analogy to the 1=A, 2=B, 3=C... code most do as kids, just the computery version of that. There are some standard ones (ASCII https://www.ascii-code.com/
, ShiftJIS http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml
, EUC-JP http://rikai.com/library/kanjitables/kanji_codes.euc.shtml
and of course unicode https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/
) but games even today rarely use such things and it would be the exception back when. There are all sorts of methods you can use to find tables, some of which don't work as well with Japanese like the otherwise incredibly powerful relative search, that vary in effectiveness and difficulty (assembly driven analysis is going to work every time but requires you know a bit about assembly coding and put the time in, statistical methods like take the text section and analyse letter count and most times it will match scrabble scores, are less reliable but quicker, and that is before we deal with corruption).
**continuing with analogies then computers don't know where things are and don't have the resources to parse text. Computer programs then have all sorts of things to keep track of data, the main thing being pointers which are small values that... point the way to things. For text you might have one every line, every screen or every section. I usually then make the analogy of it being like a contents page in a book. Rip out some pages and if you had counted along you would have done wrong somewhere, stuff a bunch in and the same. Given that translation will seldom ever make things the same size (or shorter such that you can pad it out) you then get to deal with pointers. There are three, maybe four, primary types (that being standard, offset, relative and simple size, and can deal with the ROM, the file or the memory as the system sees it) but we can leave that for later.