Why you should never hard-code user-facing strings - and what to do instead

When developing your code, you should never hard-code user-facing strings - i.e. embed them directly into the source code.

Why?

Hard-coding slows down the localization process tremendously. Either you will have to extract the strings to pass them on to your translators, which is a slow, error-prone, and expensive process, or it forces translators to read through source code to identify segments that require translation, risking both omissions and inadvertent changes that will interfere with the website’s functionality.

It also often means the developer has to stay involved throughout the translation process — pulling strings, sending files, re-integrating translations — instead of handing off a clean package and getting on with other work.

In short, hard-coded content is difficult to version control and maintain, which can lead to translation issues and significantly higher localization costs.

The solution: external resource files

The fix is straightforward: move every user-facing string out of your code and into a dedicated external resource file (a .json, .po, .resx, .strings, or .xml file, depending on your platform). Make sure your code then references a key rather than the text itself, and define the value for the key in the resource file.

Use a separate resource file per locale. Use the full locale with a country code to support regional differences, e.g. nl-NL. Your application loads the correct file based on the user's locale. The code itself never changes, and cannot break due to changes made by translators.

Why this makes your life easier too

Externalizing strings is not just a gift to your translator. It benefits your whole team.

Faster updates. Changing a button label or fixing a typo no longer requires a code change and a redeployment. A content manager can update a resource file directly.

Cleaner code. Functional code and display text are separated. Your code becomes easier to read and maintain.

Easier testing. You can check all your UI strings in one place without running through every screen of your application.

Scalability. Adding a new language later means commissioning a new resource file, not rebuilding your codebase.

Conclusion

Externalizing your strings is a small habit with a large payoff. It makes your codebase cleaner, your content more manageable, and your product genuinely ready for new markets.

Thinking about localizing your software for the Dutch-speaking market?

I've put together a free localization preparation checklist for software teams.

It will be available soon, but readers of my blog can have it earlier, since I appreciate you being here!

Get in touch if you'd like a free copy.