Apologies if I go a bit in depth, I can already see this turning into a long one.
The basics of text hacking seem to be known to you which is nice as there is no real need to cover them again.
You appear to have run into a spot of trouble though as overlays can be harder than the more convention method where text is stored in a file in the rom (I usually point people towards new super mario brothers and the BMG files it has when they are new to text editing as it is a great non trivial example of how this sort of thing usually happen).
Back on topic if it is an overlay it can get a bit tricky. For the normal text in normal file type things you can usually just extend the file (do note the header will often have a file length as might any section length entries so it is not quite like adding more text to a document) and suffer nothing for it as surprisingly the DS has a measure of redundancy here (those section length entries and the general nature of the roms and the SDK that makes them providing it). The overlays however are a part of the binary so it can get harder.
Three things worth looking at though
1) reduce the translation length- Obvious I know and I truly hate doing this myself but you can usually trim the text a bit.
You said sound is in the overlay which is odd (I do not think I have ever seen that on the DS) but the nice thing in this case as sound on the DS is usually large wave type files or something similar which you can nuke (replace one sound with another or blank it out). Hopefully you have some voice acting in there you can lose as a few seconds of audio can mean a page of text.
2) The Japanese rom If it started in English there is a good chance it also appeared in Japan and while the problem is likely to be worse if you used it as a base for your hack (Japanese is very condensed) it provides two things including a point to compare against which helps with reverse engineering. Also if you are lucky it has a 16 bit character set which doubles the length on the spot (each character takes 16 bits rather than the 8 you can get away with for a European language) giving you the option of turning it into an 8 bit character set and if it has proper unicode (
http://www.joelonsoftware.com/articles/Unicode.html ) you might not even have to hack anything.
Better yet if it appeared in another language (sometimes stateside games have Spanish or French in them and the Koreans get a fair few games these days too) you can also use them as a base for your hack.
3)Dirty tricks Several little tricks you can use here to try and cram things in. One I usually reserve for fixed length strings (menus are great fans of this especially Japanese originating RPGs) and pseudo variable width fonts (sticking two i characters together or something rather than coding a proper variable width font) and you have some experience of font editing thanks to your "umlaute-patch"- merge a few characters/words/names (names are especially good for this) into a single "character" in the font and you can use this to decrease effective text length and maybe make it look a bit better along the way.
Something I have never tried but have had kicking around in my head for a while now and on the face of it at least is a solution to your problem is a GBA slot device- the 32 megabytes that GBA carts afford are mapped to the DS memory at 08000000 to 09FFFFFF hex and if you are already reading memory for your overlays it is no different to point it at the GBA slot instead.
Carrying on to answer some of your other questions.
Pointers are just that- they are like a contents/index pages of a book in that they have the locations of given chapters/sections contained within them. They are done here so as to make it easier on the system resources- the pointer value is used to calculate the address of the section you want rather than the game having to check to see if it has got to the end of a section after every character.
I am not sure what you know about overlays but they are a method from the early days of computing brought back for the DS that allows commercial programs (homebrew has it far easier thanks to DLDI) to have a section of memory usable for anything they like and overwritten (the files are "layed" "over" this section) as and when it becomes necessary. Despite their seemingly temporary nature in the execution of a rom anything and everything can be found in them as you have discovered. For instance one would usually think they were used for say playing back a video if there were only 5 videos the entire game and the 2 megabytes the decoder takes up does not need to be there all the time.
In your case if it is an overlay then chances are good that the pointers (if they exist) will be pointers to memory rather than the more traditional DS style of in file, as such they they will read as 02XXXXXXh rather than maybe 4 hex digits in a normal file.
Where you can go from here
Overlays working like the do means you are also in the position of maybe having no memory available (if the overlay finishes and the next section starts immediately afterwards for instance) which is a problem as it means you might have to start your own memory management which is well into the realms of full blown ASM hack* and not what you want to be doing if you are just starting out text hacking.
First things first though you never displace a section of any code if you can avoid it (remember pointers from earlier- you change where something sits and the pointers might point to nothing special at all and the game becomes unworkable or crashes). Here you will have to use all the space the original text space afforded and then probably jump to the end of the file or if you have some blank memory somewhere else in the memory then that too (getting it in there is another thing though if it is outside the overlay).
*if you are going to head down this path the DEADBEEF padding option of DSATM to help figure out what you have available:
http://gbatemp.net/t80540-ds-auto-trainer-...t&p=1059389 (although you will probably want an older version as that feature was removed
http://filetrip.net/f2112-DSATM-2-0.html and
http://crackerscrap.com/projects/DSATM-4.3.4.rar ).
The other option is you build some form of dynamic compression engine into the binary so when it tries to read a section it decompresses it and reads that (I would go for the hijack a pointer and overlay the overlay from somewhere else rather than trying to do it string by string). This dodges the memory issue but sucks up resources and
Translation tools are usually made by translation teams for the game they are translating and given the hugely variable nature of games a one size fits all tool is not likely to happen any time soon. You can dump the script and then try to return it later and there are even some semi automated tools available but they are not so hot. That is not to say you are stuck with a hex editor though as
http://www.romhacking.net/?category=14&...itle=&desc= has a few tools you might find useful.
As for automated pointer tools I usually whip up a database or spreadsheet in a pinch and combine it with hex editor search results (the end of sentences/paragraphs and other things pointers find themselves pointing at are usually easy enough to drum up in a search).
