Why is your tooltip text in Git?
Your tooltip text is in Git. Not because anyone decided that, but because the tooltip needed words and the component needed to render something, so the words went where the component was.
That is a reasonable way for it to start. It is a strange place for it to stay.
What Git is good at
Version control exists to answer questions about change: what changed, who changed it, why, and can we go back. It answers them with branches, reviews, history and the ability to revert, and for code that is exactly right.
A sentence in your interface needs one of those four. History is useful. Branching a sentence is not. Reviewing a typo fix costs more than the typo. And reverting a paragraph is rarely the thing you want, because the previous version was usually wrong in a different way.
So you get the whole apparatus for a fraction of the benefit, and you pay for it every time a word has to change.
What it costs, concretely
A release per sentence. The text reaches your users when your code does. If you deploy weekly, a wrong word lives for a week.
A developer per sentence. Not because they want to own it, but because commit access is what the file requires.
A review per sentence. Someone has to approve a change to a string they did not write, in a language question they have no opinion about, in a queue with actual bugs.
A merge conflict now and then, for a sentence two people fixed in two branches in the same week.
None of that is a failure of your process. It is your process working as designed, applied to something it was not designed for.
The test that settles it
Ask what happens if the sentence is wrong on a Friday afternoon.
If the answer involves a hotfix, your interface text is on the release path. If the answer is "someone edits it and it is live", it is not. There is no third answer, and which one you have is decided by where the string lives.
What moving it out actually means
It does not mean losing history, and it does not mean losing review. It means both of those stop being the release mechanism.
Each explanatory string gets an address. Your app requests it by that address. The text has its own versions and its own publishing moment, separate from your deploys. A change goes live because someone published it, not because a pipeline finished.
Your developers do the integration once. After that the words are no longer their problem, which is the part they usually appreciate most.
What stays in Git, and should
Everything that is logic. When a message appears, which state triggers it, what the interface does next. The condition stays code, because it is code.
The sentence goes where sentences belong: somewhere the person who knows what it should say can change it and publish it, and see it in the product five minutes later.
Where to start
Do not migrate everything. Take the tooltips on one screen, give them addresses, and fetch them by key. Then change one of them without opening your editor.
If that feels faster than what you have now, you have your answer about the rest.