<aside> 💡 This is a hack I like to share with clients, as a way of streamlining work on in app content, with the added bonus of building out the same tooling you’ll need for localization and internationalization.

Be sure to read Future Proofing Your Codebase For Global Readiness prior to this article.

</aside>

This is something I have seen at most of the companies I have worked at, and it’s a bit of a pet peeve.

1. Someone in product or design notices a typo or something that could be worded better in an in app prompt or display.
2. They file a Jira ticket for a bug.
3. An engineer edits the offending prompt in code.
4. The engineer submits a pull request.
5. Other engineers take time to approve the pull request.
6. The edits are then merged into the main branch of the code base and deployed to users.

Engineers are expensive. This is a huge waste of time and a mis-use of a scarce resource. A company easily spends several hundred dollars to fix a simple typo.

What if UI/UX people could just login to a Content Management System (CMS), edit the text, and be done with it?

In this article, I’ll describe how to do this using a Translation Management System (TMS), both to solve this problem, and also build out the exact same tooling that you can use to roll out additional languages when you are ready.

Translating From Draft English to Finished English

The basic method I am describing here is to localize or translate your in app content from draft English to finished English. Developers can create placeholder content in the code base without. fretting over the details. UI/UX and product staff can come in and “translate” these prompts to make them suitable for users. This is a great approach for several reasons:

• Software engineers often speak English as a second language, and may not always be the best people to write user facing copy
• Engineers, even if they are native English speakers, are often not the best people to write user facing copy.
• Engineers are scarce and expensive. They should be focused on functional improvements and fixing bugs, not editing text.
• Product and UX staff are often not proficient at coding. Allowing them to edit text in a CMS-like environment enables them to make changes without involving engineers.

Typically, what you’ll do is store draft English content in a generic English message catalog (e.g. messages.en.json). The translation platform will return finished copy in a US English message catalog (e.g. messages.en-US.json), which is displayed to users.

<aside> 👉 I am assuming that US English is your home language, but this process applies equally well to other languages.

</aside>

What Is A TMS?