This is applicable to almost any piece of software with text in it. When starting your new app, you should make sure you are using a separate language file for the strings in your app. This makes text reusable, and you can change it all in one place.
Once your app gains a community, if you did this, you can also get translators!
With Photon i made the massive mistake of hardcoding everything up until the app became massive, and my PR for un-hardcoding all the strings looks like this:
It was worth it though! Because the community has translated it into 11 languages!
There's two approaches you can use here.
You can use a list of strings used in the app and have each string only occur once. Then using translation files you can translate each of those strings into another language.
This usually works fine, but has the downside of losing the context of a string. Context can matter a lot when translating, you often see this when the wrong translation is used, which is a correct translation but not for the context it's in. It can also be tricky when two strings are the same not by definition, but by chance. When in another language those strings should not be the same, this can't be resolved easily.
So for situations where a better translation is required another approach is used. Instead of strings directly, placeholders are used. These placeholders should be structured in such a way, the context is obvious and people could find where it's used easily. These placeholders are also unique, where two strings that are the same by chance don't use the same placeholder. Then for each language, including the "primary" language, a translation file is used. That translation file translates the placeholders into the correct string. For translating the translator uses the placeholders and the primary language file to translate the strings. Good tools for this exist that allow the same strings to be translated once, but show the context so the translator can decide to use different translations for the same string in a different context.
Using the placeholder approach is a bit more work and adds some overhead, but I've seen it used to produce awesome results. It prevents the pitfalls of the simpler approach.