There are some people that did things before for this game, and its sequels and harvest moon (which is broadly similar in engine to this). If I have done anything myself with this game's text it has been too many years since and I can't recall much.
Pointers as in the translation/programming concept or more general colloquial term?
Assuming the former then most of the time they are either in the same file as the text itself or in the same directory as a smaller file (rarely see this for text, more for archive files where having a small file is beneficial). For menus then you might find there are fixed length sections instead, or you might find more delimited text with no overt pointers (rarely done on consoles outside that sort of thing as it takes more processing power and the Read Only part of the ROM means you theoretically can know where everything is/will be forever before it leaves to get made into carts).
You then get to figure out the relationship between the pointer numbers (usually at the start of the file) and the text itself.
Classically (as in go back to 8 and much 16 bit stuff) every line on the screen would have its own pointer and the pointers served as a means to start a new line. This is tedious to handle for devs so they soon opted for new line commands within the text but I still have examples of every line needs its own pointer on the DS.
To that end most things these days will be pointer per either screen of text (so usually about 3 lines) or section of text if it is scrolling/multiple screens in an interaction.
With that in mind I usually get a list of all end of sections (usually have a nice full stop I can use as a larger than necessary list or at lot of the time will have a 00 or some marker to end things which you can happily search for as it is only used to end sections) and put that into a spreadsheet. Compare that to the pointers (including take one from the other), compare what the pointers say to what I find at that location/what the next obvious location for a pointer might be/should be and most times I can then figure out what is what without having to analyse the game's code to have it tell me exactly what it is doing. You probably also have multiple text files within a game, maybe regions to compare against and other things that might give it away.
I generally note there are three types of pointers, maybe four in some scenarios.
1) Classic pointers. File level and memory level available but overwhelmingly going to be file level for DS text unless you find the text in the ARM9.bin or overlay files (both of those operating in memory and thus likely to be addressed like you find it in memory).
Anyway give or take byte flipping (see big and little endian) then where the pointer says is where you will find the end of line/start of next section.
2) Offset pointers.
Much like above but rather than starting at the start of the file they might instead start somewhere within the file (an offset in programming parlance). Usually this means the start of the text section but can be other things.
3) Relative pointers.
Something of a hangover from older days of computing where instructions were a bit more limited and thus the theoretical space savings justified such a thing. Anyway basic idea is you take the location of the pointer itself and add the data there (if pointer is at 40h and says 120h there then you add it together to get 160h). You will tend to notice this more when if you do the find all start/end sections trick then each section ends up a set distance away from where it should be (if pointers are at 36h,40h,44h,48h then it would be out by 4h more each time). Theoretically you could have an offset relative pointer but I don't think I have ever seen one.
4) Is either size itself or sector based stuff. Size itself is fairly obvious and rather than pointers to locations then each section is noted as a size value. Rare for text but have seen it, especially for some scripting stuff. Sectors is more for optical disc based things (32 bits gives you around 4 gigs of addressable space, OK for a CD, less OK for a hard drive or dual layer DVD or indeed single layer DVD. To that end you make say sectors of 200KB. Put whatever you like in there and if the file finishes before the end of the sector you write the rest off -- if you ever have seen on Windows "file size" and "size on disc" then this is that in action). Not seen it on the DS though outside of technically fixed length if a version of this.
While pointers are usually pointers you can find other data variously with them. This can include markup (make this section bold/italic/red/jiggling/...), note what characters are talking so as to show a suitable portrait, size values alongside pointers (easier to have there than run a this minus the next calculation I guess) and in the case of stuff like the DS NARC format or some other archives you can use a bit in the pointer to indicate compression -- as noted above 32 bits, which the DS is a 32 bit console, gives you 4 gigs which is a bit ridiculous for DS files so the NARC format uses the upper bit to indicate compression at the cost of only being able to then use 2 gig files (still ridiculous for the DS).
Pointer maths is sometimes a thing as well but usually for archives and 3d formats. Relative pointers is a type of maths but usually its own thing, here you will see things like shifts being used to increase or decrease effective sizes (while the DS is 32 bits you have to think about it if you want put a 32 bit number in there, so put say 27 in, shift it a few times, lose some clarity for lower bits but that just means you space it out to given boundaries*. In PC games and some vanishingly rare console ones you might see various flavours of Boolean operation done to change numbers, and if there is the potential for the upper bit to be an indicator/flag of some form then you would presumably be doing an operation like that as a mask (AND anything with 0111 1111 and the upper bit of the 8 will be 0 regardless).
Hopefully you have also seen something like
https://www.romhacking.net/documents/[469]nds_formats.htm to see some of the sorts of data normally included in files (though the big one is usually around 8h in the file will be the file size, and this applies even to a lot of non Nintendo formats).
*one of the other reasons you might have a size value and a pointer in the same thing. If every file starts on some multiple of 200h you might need the size value separately to do whatever.
Once you have the pointers some like to slice up the file accordingly, usually more for archives.
https://web.archive.org/web/20170218180937/http://min.midco.net/cracker/filecutter.zip is a command line tool that can be told to slice out this much data at this location, and spreadsheets can make nice batch files to use it.
Memory level I noted above and might as well cover it as I have had things use it on the DS (it is generally considered bad form to put data within code these days but 5pm on a Friday night with a deadline due and corners get cut, with only your localisation team a few months later ever theoretically having to know,
https://www.loekalization.com/ covering many such stories and woes). So anyway the binary will loaded into a fixed location in memory every time it boots, and overlays get swapped out also to known/fixed locations. As such it makes sense to refer to them where they get found in memory (
http://problemkaputt.de/gbatek.htm#dsmemorymaps aka 3?????? give or take byte flipping, similar to how many will say GBA pointers start with 8 as most GBA ROMs read from the 0800000 through 09FFFFFF range and as they are usually under 16 megs then yeah). If you need more space in a DS game binary (not as easy as expanding size like normal files) then I do generally note that if it is a wifi using game that all the wifi error codes (many of which will probably never have been seen on any game when the wifi was current, never mind a specific game today when wifi is a third party server) so that can squeak in a few bytes which is mostly what you need as such things tend to be more location names, menus and other very short segments of text.
I could probably do more depth or some examples (though I do have some in the hacking guide
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ ) but I will leave it there for now.
