I am free now so I thought I can give the help I said I would.
You seem to have the translation aspect down so I went ahead and figured out how to repoint the text thus enabling you to dodge the text length issues (this is the technique x_comp spoke of).
I am sure you are aware of the DS using a file system to hold it's files, if not you need a program like NDSTS: http://www.gbadat.altervista.org/tools.htm or NDSTool (the most compatible version I have put on my site: http://www.4shared.com/file/2170119/a40ec269/ndstool.html ) to get at them.
NDSTS does not touch the header and is probably the better route to go as sometimes ndstool can make a rom stop working for some patchers.
Unfortunately ndsts does not allow you to change the filesize for the component of a rom you are changing so if you plan on expanding the text much you will come unstuck (FF3 likes to but a bunch of FF's between files to make it a nice round (hexadecimally speaking) file size).
While NDSTool works with 99.9% of all roms I have tested (using my EZ2/4 and their respective patchers) it is wise to be aware of this issue, if you are feeling exceptionally brave/bored you could repoint the header manually (I guess it is the altered placement of a system file that causes crashing when using NDSTool).
As a mentioned already the FF3 rom like to put several (average of about 30 bytes) of FF's between file sections so you could easily repoint to there.
Enought chit chat so lets get down to buisness, to explain the process I will use your example from post #18 although I have confirmed it to be the case for other files too though.
In your example the file you are playing with is called Eureka_menu.msd (got to love nice developers and the DS file system), if for some reason you do not wish to rip the file apart it is at offset 2DE3600 (hex) with all the menu/text I have found so far (credits aside) starting with MSDA (plain ASCII here). A simple search will turn this up.
Life is made 10 times easier though if I explain it using a single file, it is for this reason I assume you are using it from here on out.
Normally I would throw some pictures up but I am typing this up from my notebook so you will have to settle for words.
If you have not already fire up your hex editor and open the Eureka_menu.msd.
Oooh shiny.
It probably means very little right now but hold on a second it will all become apparent soon.
It would have probably been better to use a smaller example file but what the hey it all works.
What I want you to do is select all the bytes from 0 to A2E (hex naturally) and then do a byte flip (16bit unsigned short is what hex workshop (my hex editor of choice) calls the one you want).
What have I just accomplished you may ask, changed bytes are show up in red for me so I now see 1B02 (hex) as the last changed piece of data, I personally pressed print screen here and dragged the result to my other monitor but scrolling also works.
Scroll down to the end of the file place your cursor at the 1B02 offset (6914 decimal), the start of a word section no?
Back to A2E count back 14 bytes: 1AF6, now go there. The start of the previous section? well I never would have thought that.
Now you can edit and what not to your hearts content (just change the pointer and it is all good), remember to flip the bytes back again though when you reinsert.
2 sidenotes, in the 10 "junk" bytes between pointers you will see some numbers counting up.
What they are I have no idea but experience/logic tells me they are reference numbers which you could use to for example to mkae 2 villagers say the same thing by changing the associated pointer (thus freeing some space) or more fun things.
ou may also see some %main character name% type things in other files, these appear to be reference values and they should be able to be shifted (I have not done it personally in this game but I have done similar things in others).
You also mentioned graphics , I have not looked all the way throught the rom but there are several sections (the criedits and several "pictures" do for example) that make use of 4bpp and 8bpp GBA format which any halfway decent tile editor should support, my prefered one being http://home.arcor.de/minako.aino/TilEd2002/
3d stuff is compressed and beyond the scope of this post (3d programming on the DS is likened to open glide and to disassmble that and mess around is above me).
A final unrelated note the .bmg files found in Animal Crossing and NSMB use a similar pointer system to this akthough it is a bit more involved (you flip the bytes once again but you ahve to lop off sections to make the addresses match up. I am including it all in an upcoming guide (12 pages fo 12 times new roman and counting, I have yet to add examples and the bulk of the text too) so I will not detail it here (of course if someone asks I will be happy to explain it).
Enjoy.
Edit: I do oy my title of type king.
You seem to have the translation aspect down so I went ahead and figured out how to repoint the text thus enabling you to dodge the text length issues (this is the technique x_comp spoke of).
I am sure you are aware of the DS using a file system to hold it's files, if not you need a program like NDSTS: http://www.gbadat.altervista.org/tools.htm or NDSTool (the most compatible version I have put on my site: http://www.4shared.com/file/2170119/a40ec269/ndstool.html ) to get at them.
NDSTS does not touch the header and is probably the better route to go as sometimes ndstool can make a rom stop working for some patchers.
Unfortunately ndsts does not allow you to change the filesize for the component of a rom you are changing so if you plan on expanding the text much you will come unstuck (FF3 likes to but a bunch of FF's between files to make it a nice round (hexadecimally speaking) file size).
While NDSTool works with 99.9% of all roms I have tested (using my EZ2/4 and their respective patchers) it is wise to be aware of this issue, if you are feeling exceptionally brave/bored you could repoint the header manually (I guess it is the altered placement of a system file that causes crashing when using NDSTool).
As a mentioned already the FF3 rom like to put several (average of about 30 bytes) of FF's between file sections so you could easily repoint to there.
Enought chit chat so lets get down to buisness, to explain the process I will use your example from post #18 although I have confirmed it to be the case for other files too though.
In your example the file you are playing with is called Eureka_menu.msd (got to love nice developers and the DS file system), if for some reason you do not wish to rip the file apart it is at offset 2DE3600 (hex) with all the menu/text I have found so far (credits aside) starting with MSDA (plain ASCII here). A simple search will turn this up.
Life is made 10 times easier though if I explain it using a single file, it is for this reason I assume you are using it from here on out.
Normally I would throw some pictures up but I am typing this up from my notebook so you will have to settle for words.
If you have not already fire up your hex editor and open the Eureka_menu.msd.
Oooh shiny.
It probably means very little right now but hold on a second it will all become apparent soon.
It would have probably been better to use a smaller example file but what the hey it all works.
What I want you to do is select all the bytes from 0 to A2E (hex naturally) and then do a byte flip (16bit unsigned short is what hex workshop (my hex editor of choice) calls the one you want).
What have I just accomplished you may ask, changed bytes are show up in red for me so I now see 1B02 (hex) as the last changed piece of data, I personally pressed print screen here and dragged the result to my other monitor but scrolling also works.
Scroll down to the end of the file place your cursor at the 1B02 offset (6914 decimal), the start of a word section no?
Back to A2E count back 14 bytes: 1AF6, now go there. The start of the previous section? well I never would have thought that.
Now you can edit and what not to your hearts content (just change the pointer and it is all good), remember to flip the bytes back again though when you reinsert.
2 sidenotes, in the 10 "junk" bytes between pointers you will see some numbers counting up.
What they are I have no idea but experience/logic tells me they are reference numbers which you could use to for example to mkae 2 villagers say the same thing by changing the associated pointer (thus freeing some space) or more fun things.
ou may also see some %main character name% type things in other files, these appear to be reference values and they should be able to be shifted (I have not done it personally in this game but I have done similar things in others).
You also mentioned graphics , I have not looked all the way throught the rom but there are several sections (the criedits and several "pictures" do for example) that make use of 4bpp and 8bpp GBA format which any halfway decent tile editor should support, my prefered one being http://home.arcor.de/minako.aino/TilEd2002/
3d stuff is compressed and beyond the scope of this post (3d programming on the DS is likened to open glide and to disassmble that and mess around is above me).
A final unrelated note the .bmg files found in Animal Crossing and NSMB use a similar pointer system to this akthough it is a bit more involved (you flip the bytes once again but you ahve to lop off sections to make the addresses match up. I am including it all in an upcoming guide (12 pages fo 12 times new roman and counting, I have yet to add examples and the bulk of the text too) so I will not detail it here (of course if someone asks I will be happy to explain it).
Enjoy.
Edit: I do oy my title of type king.
