Step 1 is tbl is just a hacker helping format, nothing to do with any game I have seen and is unlikely to be and so inserting it makes no real sense. There might be another format called .tbl (see also why there are a billion different formats with the extension .bin) but that does not sound like the case here.
The .tbl is a listing of a hex values a text engine uses and what characters they correspond to. They are used in two points in a translation hack
1) Getting the text out
2) Getting the text (presumably translated or at least modified) back in.
On occasion the same file can be used for both, many times though the insertion one will be different because a) the encoding will have been changed (not all Japanese games include the Roman alphabet for instance) and b) the original table may have included multiple ways to generate the same character and you don't want to confuse your insertion tool.
You may also have multiple different encodings used within a game (often normal text can be one thing and menus quite another, some games change table all the time which gets really confusing) but it is still those two steps at its heart.
Going back to the a) encoding change thing. There are three main changes done
1) Overwriting characters
2) Inserting new characters
3) Changing the entire encoding (typically an 8 bit conversion)
Overwriting is much as it implies. The game has no concept of characters so if you find where the pictorial representation of a character is and doodle over that the game will happily display your modified doodle. Change say a kanji you don't care about into a Roman character (and indeed the next 70 or so for the rest of the alphabet, numbers and a few choice pieces of punctuation) and you can get the game to display text in English where it may not have before. Your new table would have to reflect these changes in the game.
Inserting new characters is harder for some things (some DS formats and tools to manipulate them make it easy) but still doable as there are usually gaps in the encoding that could be filled by something else. You then need to add these new encodings to your table.
Changing the entire encoding is not done so often these days as systems have memory to spare most of the time but is hardly unknown. Japanese has thousands of characters which typically means they want a 16 bit encoding (2^16 options for characters) where as mentioned above with 70 or so values you can do the entire Roman alphabet quite comfortably so you use an 8 bit encoding (2^8= 256 options). If you can change how the game pulls characters to be 8 bit you immediately then double the space available in the file or in memory. Both incredibly useful on the NES or something but only the latter really matters for the PSP as while I said they have memory to spare you can still run into troubles so some people do it.
We have a guide on hacking, it is mainly aimed at the GBA and DS but enough of it is similar enough across all systems and many of the things for the DS also apply to the PSP (it too is a filesystem based system that loads things into memory rather than reading directly from the disc).
http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/
