Okay, the other guys gave a good overview of where to go next, I'll just toss my two cents in.
First thing, get WindHex 32 EX, it's a bit old but it's the nicest table-supporting hex editor I know of. As Disch said, a table just says what each byte represents in a ROM, when those bytes are used to represent text. Those bytes tell the game which graphic to use for each letter on the screen. WH32EX is a good tool to use if you have figured out your table and want to edit some text to see how it looks.
You should pick the first line in the game and mess around with it to see what happens: how many characters per line, which bytes are used for control codes - to tell the game to move to the next line, or that it's the end of that dialogue - and so on. A lot of early work on a translation is experimentation. It's reverse engineering after all, so you try lots of things to see what you can and can't do with the game as-is. Though often you can get around things if you learn assembly, but let's figure out the basics first.
So, it would help to know exactly which ROM you're hacking, and which system it's for. That makes a big difference: a SNES RPG is a lot different to a NES action game, for example. If there isn't much text, you could probably just do it all with WH32EX, but as Disch said, anything bigger will probably be better done with a dumper/inserter. I use Pointer Tables which is in the database of this site, because it'll work for any game or system provided you know what you're doing. Everyone mentions Atlas but I haven't got it to work.
Of course, to use Pointer Tables, you'll need to understand what pointers are.
They're just a bunch of bytes (one to three, generally) that say where some data is stored - usually text, but also other stuff. Basically, here's how games display text: the game will have a command to load the next character of text (it has to do it one at a time), and it will use a pointer to know where to find it. So if there's a pointer table, it will probably get the number of the dialogue used and say (for example) "load from $A472 plus whatever the dialogue number is". There it will find the pointer, which tells it where to find the first character. It'll then continue from there until it sees a byte that it knows means "this is the end of the text".
How to find pointers is the tricky thing. If you use a debugging emulator and can understand assembly, this isn't so hard, but otherwise you could try searching for the address of a line of dialogue, with adjustments (I'll say more when I know what you're hacking
), and you might get lucky. Learning assembly is worth it, though
Hopefully that makes sense. It should give you a start, at least.