Content or logic: where the line runs
Most arguments about where interface text should live are really arguments about a line that nobody has drawn. Draw it first and the rest gets easy.
The line runs between when something is shown and what it says.
The two halves
Logic decides when. A user has no collections yet, so the empty state appears. The payment failed with this reason, so this message and not another one. The user has completed step two, so step three unlocks. All of that depends on your data, your states and your rules. It belongs in your product, in code, in review, tested.
Content is what appears. The words, the order of the sentences, the example, the warning, the link to the longer explanation. It depends on what your users misunderstand this quarter, and it changes far more often than the rule that triggers it.
Once you see them as two things, the awkwardness of the current setup has a name: they are stored together, so they have to change together.
Three questions that place anything
When you are unsure which half something belongs to:
Does it depend on state? If you need to know something about the user or the data to decide, it is logic.
Would a non-developer ever want to change it alone? If yes, and the answer is "that requires a release", you have found a piece of content living in the logic half.
What happens if it is wrong? Wrong logic shows the right sentence at the wrong moment. Wrong content shows the right moment with the wrong sentence. The first is a bug, the second is an edit, and they should not need the same process.
The hard cases
Conditional wording. "You have 1 collection" versus "You have 3 collections". That is content with a variable in it, not logic. The rule that counts is logic; the sentence with a placeholder is content.
Sequences. An onboarding flow is logic: who sees which step, in what order, under what conditions, when it counts as done. Each step's words are content. Keeping those apart is what lets you rewrite a step without touching the flow.
Errors with codes. The code is a contract and belongs in logic. The explanation attached to it is content, and it is usually the part that is wrong.
What the split buys you
Two speeds. Logic changes with your releases, which is right, because it can break things. Content changes when someone notices it is wrong, which is also right, because a sentence cannot break your product.
Two owners. The person who knows the rule and the person who knows the words are rarely the same person, and now they do not have to queue behind each other.
One less argument. "Should this be configurable?" stops being a design discussion. If it is content, it is editable by definition.
The part that stays with you
Delivery is separate from presentation, and that separation is what makes the whole thing work. A content system hands over the text; your application decides where it goes, what it looks like, and whether it appears at all.
That is also the honest limit. Nothing renders itself inside your interface, which means you build the panel, the tooltip and the step. In exchange, the sentence in it is not a code change, and nobody is counting how many users saw it.
Where to start
Take one screen. Write two lists: the rules that decide what it does, and the sentences it shows. If some items land in both lists, you have found the parts that are stuck together, and those are the ones to separate first.