Ahh the GBA way.
As you are probably well aware the DS uses a file system, in the case of every commercial rom known it is the nitrorom file system, I assume you have basic maipulation tools (ndstool or the frontends DSLazy/DSbuff, ndsts, hdshv, crystaltile2, nitro explorer....). I mention these only as you will now have to forget them for the most part; DS roms read files and then use the internal limits of the files to work with, in rare cases the intial file will be read and then parsed for new info (think like an API) but this is not something hackers tend to work with as it is game or even file type specific and can get a bit messy (NARC (stuff like mario kart) and SDAT (the various sound hacks for tetris, megaman, pokemon and whatnot that are floating around) files being the major exceptions here).
Braindead way: simply make the file long and rebuild with NDStool based method or something similar (crystaltile2, ndsts and ndshv are out as they only support files of the same length). If it does not work remember it is most likely the rom does not get along with ndstool so pick a new tool like nitroexplorer.
Easy way: files are not necessarily end to end and while this can mean quad word aligned it can also mean megabytes (tetris DS' sdat file in the US and Japanese releases being a good example).
You can dupe the DS file system into thinking the file is longer and make use of this padding for your text.
Tweak on easy way: this is as close as you will come to the GBA method. You tweak the DS file system to read the file you want to edit to the end of the rom or wherever you have space to play with*. Note the end of the rom may not be read unless you also alter the 4 bytes at 80 hex in the rom (this is the value used by modern/safe trimming tools and for such a simple trick you might as well avoid any hassle).
http://nocash.emubase.de/gbatek.htm#dscartridgeheader
*an aside of sorts, when ripping files from roms to try and make space (useful when we were stuck with NOR based carts or some hundred megs or less but not so useful now we have SDHC carts clocking over 10 gigs at times). The usual way was to find a small file of equivalent format (be it from the game itself or another) and replace it (SDAT files were a common target and as data from these hacks appeared it led to the rise of the "undub" hacks and similar techniques led to level, sprite and model hacks) but even with these file replacements you could still end up over limits so more advanced hacks included duping the game to read the same file twice or more (changing the pointers to read the same thing), today you can use such an ability to create space for yourself.
Data you need for such a thing
http://nocash.emubase.de/gbatek.htm#dscart...roromfilesystem
Note in all three cases you will have to deal with not only the nitro file system but the internal pointers of the files you are editing (and their internal pointers of the internal files for things like NARC which may well contain text files and SDAT), traditionally this is the 8th through 12th bytes (possibly 10th if it is a small file) of the DS SDK files (SDAT, various files within SDAT, NARC and so on) but any can be used.
Alternative: text in a game, often this will mean Japanese which has to be 16 bit characters by virtue of the language (an increasing number of European and US games also favour 16 bit characters). Making the game use 8 bits instead of 16 effectively halves space requirements which means with a bit of creative editing you can avoid increasing file size.
This is quite good in the case of text contained within a binary or even within another file system (culcept, tony hawks, phoenix wright examples of games with filesystems within filesystems) although the latter can make use of a simple repoint to the end of the file.
like a 250 dollar kit back when DDR4 was Intel only