I don't envisage any cases in which simple AP removal* would interfere at the highest technical levels with a translation, and anybody vaguely competent at DS ROM manipulation (not even hacking -- if you can operate a file viewer/ndstool/dslazy/dsbuff/... and an compression program enough compress and decompress) can likely combine AP patches with translations for those that want such things. Personally I still say get a flash cart that handles it all rather than messing around with these compatibility layer things but it is what it is I suppose. It might even be as simple as applying the AP patch, then applying the translation patch (which is probably in xdelta format or something similarly potent) but telling it to ignore input verification/checking**.
*for something like the pokemon typing game then maybe the extra code added to send things over wifi or something would also be the same places a translation would make use of. You would then have to be some flavour of ROM hacker to sort this, though even then it will hopefully not be too bad (space is an issue in DS games but there is usually enough free space able to be made available that you are not going to have to optimise things to make it all fit a la some older devices.
**old school ROM hacks tended to use the IPS format. IPS is limited in a lot of ways (size, inability to add data, no ability to relocate data/deal with insertions), one of the bigger ones is the lack of input verification. This particularly troubles SNES hackers where various ROMs from different sources will either come with or without headers (with header then shifting everything it expects forward by the same amount as the header) but everybody suffers as people will try to apply it to different versions, different regions, corrupt dumps, otherwise hacked versions...
Newer patch methods will then do an initial check to try to make sure the ROM presented for patching is the version it expects. If you patch the AP out then it will not appear as such and it will tell you, and maybe refuse to patch unless you tell it to ignore input checking/source verification or whatever it is called in your particular translation of the patching program.
Anyway general theory of how to combine.
Anti piracy in ROMs so far as I know is limited to the executable parts, which is to say mainly the ARM9.bin and its overlays. For the PC it can get more fun*** but generally DS checks amount to some number (which can be hundreds or thousands) of things doing the check and seeing if it gets the result it expects if you are running on a flash cart/emulator. The people taking out the anti piracy get to find all these checks and nullify them however they will. The easiest way, one which is accepted by basically everybody, is to NOP (so called no-operation or an operation that ultimately does nothing other than waste a cycle or two) the checks and force their outcomes to the good version (possibly by jumping to the good outcome or preventing a jump). This can all be done in place on a ROM without adding extra sections of code to emulate responses and whatever else.
***
This video, and the series it is part of, is a pretty nice introduction to what goes on and what historically happened on the PC. The N64 also had something like this, most famously with banjo tooie which only dropped in 2012
https://gbatemp.net/threads/banjo-tooie-for-n64-finally-cracked.338824/ but enough with this aside.
A ROM hack or translation could do any number of things to the executable parts of the ROM, for most purposes then translations for every DS game I have pulled apart or otherwise seen won't touch them at all but you never know what a dev or hacker did until you check. Even if the ROM hacker/translation group did change the binary it should be in totally different areas to the AP defeating stuff. I can think of perfectly valid reasons for the translators to mess with the AP areas as well but should be no big deal if you first sort the AP and then sort the translation/hack side of things.
Your job in combining them would be to get the modifications to the ARM9 and overlays, and any changes for the hack/translation into one file.
If it is uncompressed it is easy enough. I would not be surprised either way when I open a DS ROM and look at its binaries. On some occasions some dumpers even compressed the binary when it was not compressed to begin with but let us not go there, and most of those should have been nuked anyway.
If it is compressed then technically you should really decompress both versions, merge any changes into one new file, recompress or otherwise dodge the need for compression and carry on accordingly.
The hack/translation probably also has a bunch of other files inside the DS ROM it changed so you would also need to get the changed files (a simple file compare program will tell you this, or you can copy the lot instead if it is just AP you want to combine with a hack/translation) in there as well.
Somewhat amusingly I would probably use IPS in making this -- IPS is very basic but as all it essentially does is make changes rather than check to make sure it has the file it expects then it will do the job just fine here, and you are not likely to run into size limits with this (the DS has 4 megs of memory, any executable file has to be less than that, IPS tops out at just under 16 megabytes) and nobody will likely shuffle the binary forward or backward like in other files in the ROM that use pointers. The routine would run get uncompressed ARM9 or overlay files. Generate IPS patches to convert to AP patched version and another to go to translated version. Do AP patch, do new IPS version of translator/hacker patch as well to AP patched version, compress if necessary, rebuild ROM with all the other files that needed changing.
Thinking about it then it would probably be possible to automate a lot of that, maybe add some checks to confirm people are trying to do what you think they are trying to do, and make ultimately it happen but that would be a thing for a different day. Wonder if I could make a distant cousin to my old ARM7 swapper program.
I have probably just confused you more. If you want a very basic thing you could try, other than the thing above about disabling verification, that might well fail but is worth trying anyway, especially if it is a translation of a European language game to another European language.
Do the AP patch to a ROM
Do the translation patch to another ROM.
Fully unpack the AP ROM and translation/hacked ROM into separate folders. ndstool should do well here.
https://filetrip.net/nds-downloads/...ntendo-ds-rom-tool-ndstool-1-50-1-f29352.html
Copy the contents of the data folder into the AP game's data folder, overwriting everything in the process. This should leave the overlays and arm9.bin, arm7.bin and all the stuff in the AP folder alone.
Reassemble the game with ndstool (example commands on the link).
Hopefully this should be an AP patched and translated game. If not then you have to start merging changes to binaries.