The NES and GBA are fairly similar in this regard in that text is located in the rom rather than a file system (DS, FDS, playstation and the like). I personally tend to use pointer maps (lots of 08XXXXXX strings (after byte order is accounted for) or maybe 09XXXXXX for roms larger than 16 megabytes) to locate text.
Bear in mind tables for GBA can be everything from plain ASCII (advance wars amongst other things), through simple relative to completely random (final fantasy a culprit here and naturally kanji tables as well).
You may also have control characters (new line, section end, bold, italic, yes/no...) embedded which can screw up 16bit character sets no end.
There are a few more automated tools but I still find ripping the text from the rom with a hex editor and dumping it into a new file before using something like Windhex to grab it, however you could try romjuice:
http://www.romhacking.net/utils/234/
You say also that you get a few letters correct, if they start out OK but get increasingly worse it is likely you have compression happening (the GBA has several onboard decompression mechanisms which are typically used, LZ77 being the most common followed by huffman). Have a read here:
http://nocash.emubase.de/gbatek.htm#biosde...essionfunctions
VBA-sdl also helps as it can monitor BIOS calls and help determine what compression is happening.
I suggest a generic decompression tool like
http://gbadev.org/tools.php?showinfo=56 for LZ (huffman you will have to search for I am afraid) although romhacking.net (linked above) has a few reasonable GBA oriented tools (even some capable of taking a VBA-sdl log).
Simply put there is no click here, here and here to get a text file, the fact most companies use their in house tools (unlike the DS where stuff tracks across nearly all the roms) further complicates this, keep plugging at it: nothing is really impossible in rom hacking but it will often require some original thought or more learning.
