Storing stringtable keys, like "Is this defined" would be acceptable in this specific case. And also the package/container names would be okey in this specific case.
But this only applies to base game's stringtables from un-encrypted PBO's. For CDLCs I would say no.
I assume your mostly vanilla mission is unlikely to use CDLC stringtable keys anyway.

Full data including translations:
https://www.bohemia.net/community/licenses/arma3-end-user-license

3.B. You are entitled to use the Program for your own use, but you are not entitled to:
ii. Publish and/or distribute the computer Program or any of its parts.

Getting data dynamically by reading the PBO's is also what I had in mind. Its quite a bit of work. You could make that optional. If Arma is installed, you can display the translated text. If not, then just "jup this key exists, but I don't know what text is in there. You need to install the Game to find out".

Thank you that you took the time to answer my inquery.

I have looked at the actual uses of most builtin Stringtable keys again and because of how they are used, I will most likely just store a sha512 hash of the keys. The user will just see that this is a builtin arma key when they hover over it.

This way no actual arma data is packaged with the extension. The repo will be updated with the actuall implementation very soon, I can update my issue with the direct link to the code that and data that will be used, just to be transparent and make it easy to check that I really only package what is allowed.

Will probably not go with the optional dynamic route, as I don't want to force the user to rely on an external tool and I really don't want to reimplement the pbo unpacking logic :). Further trying to limit configuration bloat and the current logic would probably fail with the keys that are defined multiple times.

Big Danke again for answering my question!