The methods are much the same as they are for anything else. I will note the PSP is a great fan of custom encryption and other types of obfuscation (I do not know if I want to call it encryption but same parties). The PS2 does use iso 9660 but also has raw LBA reads/DMA and similar things to the disc so not everything is there in the iso 9660 filesystem, it will be there in the iso though. Nothing to stop the binaries themselves from containing text in either case either (in which case you will probably be dealing with pointers that reference the memory itself rather than the file).
Four main methods although many are related to the methods by which you make tables (I assume when you say
1) Obvious. A file named somelanguage.txt or similar in a folder named script.... yeah. Also if it is not sound, not graphics (although for puzzle games and similar low volume of text games it can be encoded directly in the graphics) and not level data it might well be text. Also look at the files - it might use a common encoding.
2) Tracing. The PSP lacks a decent commercial title emulator or onboard debugger but you can try with cheat making software/savestates and maybe the likes of iso streaming if you attach a file read command monitor (if it reads 29FF000 and a few seconds later the text appears in ram you have your text). The absolute crazy man method is to manually go through the file and see what is going on (maybe aided by a savestate for current instruction readouts and such).
3) Corruption. Pick a file and corrupt it. Run the game and whatever is broken is whatever you just corrupted.
4) Relative search and other table making methods. Whatever method you used to find the encoding such as relative searching will also by default give you the location of the text (this offset has this text in- just read off what files that falls under). If you find the text in ram search the rom for it, if you have a Japanese and a NA version compare to find the differences- nobody is going to redo the levels for most localisations leaving you with text, maybe a handful of graphics (that you are probably going to want to change anyway) and maybe sound, a file might look like it contains text (space character is the most common most of the time and if that falls every 10 or so characters you have it sorted) and so on and so on .
I don't know anything about PS2 ram hacking, but the architecture is pretty much the same. Learning about static and dynamic memory concepts should help you identify where text is in the game. A good tool to use is ps2dis which is a disassembler for the PS2/PSP. This tool will allow you identify the parts of the game and the files and modules composed.
I'm sure their are other tools to understand the game's functions, but you'll have to research a bit more.
For what it is worth unless you are dealing with encryption (which PC games quite often do although there you have superb debugging abilities to work around it and some consoles are not above it although there is no technical reason console games can not do it) the same rules/methods apply to finding text on any system.
What omarrrio said though most of my answers to that are actually in the DS hacking thread/guide ( http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-rewritten-for-2012.73394/ ) as the DS and GBA are closely related enough that I added it when I wrote up a guide to DS hacking. It covers things in more detail but other than the GBA not having a filesystem used by commercial games the methods mentioned in this thread (corruption, elimination, relative search, tracing) are the same for every system.