Hi all. Lately I've been working on a translation of Megami Tensei II for NES. I've been using Tile Layer Pro, Relative Search and WindHex32 to create and implement tables. All's well on that end. This being my first time hacking/translating I was positive I'd run into a roadblock, though. So sure enough, here it is...

I don't know how to effectively insert the translated text I wrote. I discovered how to expand the size of the ROM in WindHex32 but I can't figure out how to utilize that new space. I can only write directly over the original text, I can't squeeze in more. I could really use some more room-- not too keen on writing like a caveman just to fit everything.

Also, sorry if this is a common question, but I'm not able to find any solutions...

Thanks in advance for any and all input!

Thanks for pointing me in the right direction, Ryusui. Looks like I'll be readin' for a while-- plenty of documentation here. And hey I recognize your name from another forum. I should have figured you'd be a regular here!

Translation for the uninitiated: NES programming is some complicated crap.

Let me introduce you to the concept of address space. A game console's hardware uses a range of addresses to access all its myriad forms of storage in one big chunk. What addresses correspond to what varies wildly depending on the platform, but the part we need to concern ourselves with is ROM address space. On the NES, we have 32Kb of ROM address space, from $8000 to $FFFF: once upon a time, this was the ironclad upper bound for NES ROM size, and that was all well and good until games needed more space. So companies began to devise their own methods of circumventing the NES' storage space limits. Thus began the age of mappers.

A mapper is a system by which ROMs in excess of 32Kb can be "mapped" to the NES' ROM address space: the ROM is, for all intents and purposes, neatly divided into chunks of equal size - usually called banks - which are swapped in and out of access as needed. If you need help visualizing the concept, think of the ROM as a book and the banks as individual pages - you can only read one at a time, and if you need information or instructions that aren't on the current page, you flip to the page you need. (Appropriately enough, the word "page" describes a similar concept in computing: you've probably heard the term already in the context of the dreaded-but-nebulous "Page Fault Error".)

What ensued in Japan was that practically every company that developed for the NES ended up devising its own mapper, resulting in a babel of conflicting methods that plagues emulator authors (and romhackers) to this day. In America - IN AMERICA! - Nintendo put its foot down and mandated the use of standard mappers, meaning that there are only five different mappers in the U.S. (and that games that were incompatible with these mappers had to be reprogrammed, hence such oddities as the missing intro and color cycling effect in the American version of Contra). Standardized bank swapping schemes became the norm in ensuing generations, such as the Game Boy and SNES, and the expanded address space of the GBA and DS obviates the use of bank swapping entirely. But NES romhackers have to contend with this relic of the past and its arcane logic.

Oh, and to answer your question: no, it's not smart enough. It just pads the ROM with extra bytes.

I've faced translation size issues, but I don't know if they're related to yours.  NES can only have one 32kB bank of ROM loaded at a time to PRG-ROM ($8000-$FFFF).  In a text-dedicated bank I'd expect to see the text arrays (as you've found via relative searching), preceded by the text pointer arrays.  Though it depends on implementation, you can sorta recognize pointer arrays like:
In the example every 2 bytes is a big-endian address to where the text will be loaded in to PRG-ROM, each pointing to the next consecutive text string, so the address value keeps ascending.  If you know where something is in ROM you can calculate where it will appear when it appears in PRG-ROM, and then you will know what its address bytes will be.  If you talk to someone, the game may load a bank number and pointer array index.  If you figure out how, then you can move this person's line to a bank with free memory to hold it, except you'll have to add another pointer into that bank's array, and adjust all the other pointers there because the new pointer shifts all the preexisting text by 2 bytes.  WHEW!  Whatever you took from that, you have to have a process for matching lines with their pointers, and for correcting the pointers when you insert custom text.

Might be a bit tough.
If the dialouge reading routine is not in the fixed bank ($C000-FFFF in many mappers, but it's only $E000-FFFF in Namco-106 (which MT2 uses)), you'll need free space in the same offset within the bank.
(such if the code were at ROM $1000 and you were swapping the bank at $10000-11FFF in, you'd need free space at $11000 ($1000 bytes into the bank), since as soon as you write to the bankswap register, the bank will swap and you want to be sure the new contents at the PC (program counter) are working code)
(so like if the instruction writing to the bankswap register was at $1006-1008, you'd want to continue the dialouge routine at $11009).

The corollary to my well-quoted mantra - "anything is possible with enough time, effort and cursing" - is "it's never as easy as you think it is". (Just look at Sylvanian Families for GBC.)

This said, I wouldn't say you have to know the entire game that well...just one very specific part of it. You'll also need to find out the details about MT2's mapper: namely, how it handles bank swapping. If worse comes to worse, you may have to use a different mapper. (Changing the mapper a game uses is as simple as modifying the relevant byte in the 10NES header...of course, if the mapper isn't similar to the one the game already uses, you'll have to change the game to suit. This will require that you know the game "backwards and forwards, inwards and outwards". ^_^;)