Translation Management For Software Projects
Published: 2022-12-17 21:51:37

**TLDR**; GitTranslate simplifies localization for software teams who are storing locale files in code. Native speakers update a spreadsheet online and developers get accurate translations delivered via pull request 😊 [www.git-translate.io](https://www.git-translate.io)

**Does this sound like you?**

Your working in a team on a software project. The user interface needs to support multiple different languages, so your team either picks an open source tool for this ([next-translate](https://www.npmjs.com/package/next-translate), [typesafe-i18n](https://github.com/ivanhofer/typesafe-i18n), [vue-i18n](https://kazupon.github.io/vue-i18n/), etc), or depending on your development framework, internationalization features might be baked right in (IOS, Android, AngularJs, etc).

Now, your team just needs to maintain a set of locale files in your code (e.g. \`.json\`, \`.xml\` \`.strings\`, etc). This is great! Your app is internationalized. Job done, right?

Well... not so fast. Now it's time to actually translate your files! So, you hire some translators, and you email them your files (or maybe slack). Eventually they come back and you notice that there's some errors. The translators didn't have enough context, so they translated some things incorrectly. There's a button that says "run" as in "run the program" but the Spanish file has "correr" as in "go for a run" 🤦🏻.

Alright, a few days later, after some back and forth, things are looking good so you download all the files and commit them to your repo. Then you launch! Wohooo! The launch goes great! You start getting some feedback from users and a new sprint starts. You've got lots of new features to work on and many of them will require changes to the translation files.... ugh here we go again... emailing the translators, copy/pasting between code and emails... and now the translations team has many different email threads to keep track of and frequently needs reminders about what needs to be done.  Features are getting delayed because of the localization process. There has to be a better way!

**Problems with existing solutions**

You start searching for solutions online... and you find some! There are many "translation management systems" out there to pick from, but...

They're **expensive**... like really expensive.. ugh.. moreover, they're **not built for software projects** like yours. They have some nice features. All of the strings can have additional context associated with them for the translators to use, plus there's a CLI to pull/push the translation files.

So, you bite the bullet and buy the expensive solution, but you run into some problems. You ideally don't want to merge (certainly not deploy) any code for a new feature unless it has all of the translations completed, but there's no "branching" concept built into the translation management tool you just bought, so you cant really use the pull/push command unless you're on the main branch (otherwise your pull requests will end up with a bunch of translations from other features and everything will get out of sync)

Your new process ends up being something like:

* New features get reviewed, then merged into `main` without any translations
* After you merge, someone has to remember push the new translations up to the system.
* The code in `main` can't actually be deployed until translations come back (all of them)... so if one feature is missing translations, then nothing can be deployed. Ugh, so now you end up spending a whole bunch of time and energy trying to remember what still needs translations and what doesn't.

For something that costs so much it didn't really solve your problem very well!

**Introducing GitTranslate**

You never needed a super expensive TMS built for a bunch of use-cases that don't apply to your software project. You needed [GitTranslate](https://www.git-translate.io)!

Built for software teams that store locale files in code, GitTranslate keeps your locale files up to date with a spreadsheet online. Native speakers update the spreadsheet and developers don't lift a finger.

* Branch tracking automatically keeps track of which translations belong to which branch, so features can be translated before they're even merged.
* Pull requests are opened automatically (against the right branch) whenever the spreadsheet is updated and new strings are automatically pushed up to the spreadsheet based on git actions that your team can customize (e.g. on every commit, or only when a certain label is added, etc)
* Auto translate saves you time by adding machine translations of new strings for every feature automatically, so you don't have to wait on the native speakers to translate the simple strings.
* The spreadsheet has a bunch of extra helpful columns that your team can fill in for the translators to add context, screenshots, etc, so the native speakers deliver the correct translations the first time.
* It's affordable because you're not paying for all of the other features you never needed with the other TMS.

Alright! That's my pitch! I'd love to hear what you think of this project! I'm looking for a people who have this problem and are interested in being a part of this project while it's built. You'll get to be involved in the process and help us figure out what features YOU NEED the most and you'll get special early access as it's built.