As a local web agency, our clients’ – and our own – custom web projects usually need to have translation management included. As trivial as it may seem, this means we usually have two options to manage translations: do it in-house, or use an outside tool.

You might have guessed that having home-built tools that are tested, under control and mastered by our team, rather than expensive third-party solutions, might save us a lot of money in the long run!

It is exactly what happened recently at Coteries. It is with this spirit that we decided to take back control of our translation system, which we had outsourced for some projects to an expensive 3rd-party solution.

Defining the objectives of a proper translation management tool

The premise was rather simple:

  1. We needed a solid common ground for translation in order not to lose any time with such trivial tasks in the future
  2. We needed everyone in the development team to be able to maintain and develop it
  3. We wanted the translations to be easily changed by non developers, meaning our designers and digital marketers
  4. We wanted the translations always to be up to date within the projects
  5. We wanted the integration to be seamless
  6. We wanted it to be cheap

Setting a clear brief always helps us to choose the right direction for proper tailor-made solutions.

Choosing a simple option to manage translations

We are using the Google Suite as a collaborative working platform and as such, we are quite used to Google Sheets. It seemed like a logical pragmatic choice to use it as the base for translation management.

Managing translations efficiently with the proper format

Then we required an optimal format for easy day-to-day use.

Easy enough: column 1 would be displaying the translation keys and there would be a header row containing all the web or mobile app languages.

This matrix can then easily be parsed into a JSON tree which can be fed to translations files.

The translations being mostly used in the backend, it made sense that we would create a standalone node tool that could be easily imported as a devDependency.

Building a simple “self-hosted” translation command

To build the tool, we broke down the task as follows:

  1. Fetch an Excel grid from the Google Sheet file using a Google service account
  2. Parse the grid into a JSON tree (language -> key -> value)
  3. Serialize it into the desired format (JSON for the web, .xml and .strings for mobile apps)
  4. BONUS: report on missing translation keys

As we wanted the tool to be easily available for all projects, it should be accessible under one easy command, so we decided to call it “translator”.

It still needed to be somehow driven: what’s the Google Sheet? What’s the worksheet? what’s the output format and directory? Then a translator.json should be added in the target project, containing that information and it would be read by the translator command and drive its execution.

We can now run it concurrently with any npm task, and it will always pull the translations alongside this task:



“scripts”: {

“start”: “npx concurrently \”react-scripts start\” \”npm translate\””, 

“translate”: “translator”



Building tailor-made development solutions

Et voilà! Except for the coding time, this tool will be free, you will have a custom collaboration tool to work easily on your translations, and the translations should always be up to date.

You can access it freely here:

The system is yours and can be easily extended to make best use of external tools, like Google Translate or Deepl, directly into your spreadsheet.

You can also tweak any output type or format to directly output strongly typed typescript or whichever you prefer.

Feel free to contact us if you need a specific custom-tool to develop!