Setting the width to C bytes (3 groups of 4 bytes) gives some kind of pattern, with an initial value.

Starting at C the F151 flips to give 51F1, the last one give C71B which also appears to line up (be careful looking at your hex editor as the ... you see in it is actually the value 2e which is the value for .).

The middle 4 bytes appear to be counting upwards when flipped, occasionally with a big leap. Possibly as a reference value or something. I would want to check if the big leaps line up with the large runs of 00000 within the text section.

The last 4 bytes I am less sure of. They don't appear to be length values (sometimes pointers will have the pointer saying where it is and the length so the game does not have to do any maths with the next pointer to figure it out) if the pointers are anything to go by. For markup values as you would expect more to be the same, especially given the contents of the text (all those menu entries with radically different markup... nah) but there are runs of the same value later so probably worth experimenting with other numbers there. Equally in the text I see things like "@STuPiD@" and while the @ symbols could be something else in the game it might be markup as well.

That said if you are just translating the middle section and the end section, if it is markup, don't matter as long the pointer sections reflect the contents.

The D4 06 (06D4) value right at the start is troubling. For many DS formats it is a so called magic stamp that indicates the type of file (it is where we get things like SDAT, SSEQ, NCGR, NFTR and so forth). It is not however mandatory at all and can be anything the format writer wants it to be. Another good bet for that sort of thing is how many sections, or how long the pointer section is. If you have another text file from the game, or from another region, it could be good to compare here. In any case 51F0/C (the last value in the table divided by the length of each sections) gives 6D4, or 06D4 if you don't drop the leading 0.
It could also mean my start, middle and end section names get to be reworded -- if it is a magic stamp of a sort then that would make the first value what I called the "middle" section above, the line identifiers, which is in line with the sorts of things you see in formats (ever written a spreadsheet with line names in the first column? same deal).

 

From a glance:

The first 4 bytes = number of text or pointers
Next read a set of 0xC bytes (with the number of set = number of pointers from first 4 bytes)

For the 0XC bytes
4 bytes = some kind of counter, should remain the same
4 bytes = number of letters. Ex. In Eng file, "Yes" counts as 3, in Jpn file, "うん" counts as 2 (regardless of how many bytes a letter uses.)
4 bytes = pointer address (you need to add 4 bytes to this for the correct address.)


Ex. in English script (We'll read the numbers backward)
first 4 bytes = 000006D4, so you know you'll have 06D4 sets of pointers and each set has 0xC bytes,

first set
00002711 keep it
00000003 = 3 letters
000051F1 = text pointer (add 4 to get 51F5)
So, go to 51F5, read 3 letters (in this case it uses ASCII, so read 3 bytes and convert it to text).

second set
2712 keep it
02 = 2 letter
51F6 = text pointer at 51F6+4

and so on...

Note: This is based solely on what I saw in the file. It might be more complicated than this. You just have to try changing text & pointer and put it back in the game and play it.

 

Sorry for the double posting.

I coded a tool and its working perfect! Thanks so much to all!
This thread can be closed.