You can pull apart PSP ISOs with various tools but most would probably look to UMDgen as the tool of choice but sounds like you go that far already.
https://www.romhacking.net/utilities/1218/
.bin is the "I just need an extension" of the programming world in that there are probably millions of formats that use that as a name and have nothing in common, and in any one game you might encounter a whole bunch of unrelated ones.
eboot.bin in various playstation efforts tend to be some flavour of elf (the unix preferred means of executable code, think exe/pe on windows for an equivalent) and contain the code the CPU runs plus whatever else the devs included with it -- in an ideal world there would only be code in such things but this is not an ideal world so many times you will see devs include extra data at code level rather than externalising it.
After that it is fairly standard file based ROM hacking (as opposed to all in ROM/incbin approaches seen on the GBA and anything older than that on a cartridge) in which you have nice directory names, file sizes, file names, extensions and more to infer meanings, eliminate and such from. As you don't have resources to waste then most formats will be close to what the final game and underlying hardware (don't know what I am linking these days for the PSP, if in doubt then usually homebrew and emulator source code will have stuff on it) uses without too many layers to go through first (same for most consoles and most PC games but some PC stuff uses more abstract formats), though it could also be a known format from a company (see middleware, and 99% of the stuff on sites like
http://wiki.xentax.com/index.php/Game_File_Format_Central , the PS1 and PS2 often use a graphics format called TIM and TIM2 respectively if we are doing a Sony related example) or a known format in general computing (you might get basic image formats, audio formats and such like inside games).
Translation usually sees you have to find the text, figure out any pointers, figure out any markup/placeholders, possibly figure out the font format (in case you did not know in Japan they speak Japanese which has its own alphabet/characters which might not include English and almost certainly not Cyrillic, though some include enough Greek that you might pull it off).
Text is not something most devices (any ones that do are usually very old) handle at low level and instead they speak binary/hexadecimal. If you ever did something like A=1, B=2, C=3 as a child (or would that be а=1,б=2,в=3,г=4?) then same idea but could be anything. There are common formats but games are the main thing we see out in the world that often rolls up with custom or heavily modified versions thereof. For Japanese you would be advised to know what shiftJIS and EUCJP looks like.
http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml has examples of that one. For English and thus most computing purposes then ASCII
https://www.asciitable.com/ though unicode is supposed to be taking over
https://www.joelonsoftware.com/2003...-about-unicode-and-character-sets-no-excuses/ .
Pointers. While you, I and web browsers are happy to take random text, figure out where things start and stop, figure out sections... then consoles don't have time to be messing around with that and it is not like the text changes (the Read Only part of ROM and all that) so instead said starts and endings will be noted down much like the contents page of a book. If you change the contents of the book without changing the contents pages the page numbers make no sense and much the same with pointers. Over the years we have seen many try to match lengths with original text and thus avoid pointers... I will let you know when one succeeds for more than about 5 lines.
Markup/placeholders. Text is text, want it in bold, italic, underline, dancing, colours then you need to tell it to do that and program it in. This will have to be reflected somewhere in the text to know what to do that to. Placeholders is stuff like it costs ???? to stay here/buy this sword where ???? is replaced by whatever the going rate is and user named characters is another example. Said placeholders will also have to be reflected at some level, and might trouble things like relative search (
https://www.romhacking.net/utilities/513/ ) if you are using that to find text/tables so try to avoid them or account for them when using relative search.
Fonts. As noted above you will be lucky if you get a workable English set of characters in the average Japanese game so you have to alter the font (either replace things or add new, adding new being harder in many cases) to get things to display in game. This then brings you into graphical changing things, and actually probably one of the harder aspects of it. If you want to make a variable width font or it to handle things like descenders (the tails on yjgpq that go below lines) then you also have to redo code a lot of the time. You might also have to edit graphics for title screens, in game graphics (the shop might say weapons shop in Japanese and be hard for your players to recognise as one).
Most translations do not handle much for audio but there have been some to do dubs of various forms (from an anime or something, from community voice acting, from other versions of the game, from sequels to the game... and I guess these days you could use those
fun AI driven
voice synthesisers).
Any one of those could also be compressed (less common on the PSP than some other things but still an option) and you would have to handle that if it arose.
As there are dozens of ways to approach each aspect and game devs variously do all of them then the would be hacker has t be prepared to handle those and adapt accordingly.
It is more for the GBA and DS but I have some more worked examples in
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/
