Hey HN,

I think I've found what could make localization of software simpler and, by accident, might lead to a new generation of software that is powered by files (?), version control, and git enabled workflows like branches && PRs.

# What I am building

I am building "Stripe for localization" which means infrastructure that eases localization (i18n) via dev tools (CLI, automation via CI/CD, IDE extension, ESLint for translations), an editor for translators to manage translations, and potentially more (share your feedback!).

# One major problem

Localization is a coordination issue between different departments. Creating translations is the easy part. But, how can developers and translators collaborate together with ease? How do developers know whether translations exist and they can deploy to production? How can translators provide feedback on the UI e.g. the German translation is too long and breaks the UI?

# The insight

1. Software engineering teams use version control enabled workflows for localization: Conduct changes (commits) -> Open a PR (preview, discuss & automate) -> deploy.

2. Trying to sync states of multiple teams, especially of one (software engineers) use version control workflows like branches with each other is a massive pain without the upside of version control powered automation (CI/CD).

3. Wait a second. The workflow of change -> pr -> agree are universal (?) to any content driven collaboration. Couldn't we achieve cross team collaboration and automation on one source of truth if we pull translators into git repos [0]?

# Abusing git as backend

The either great or absolutely horrible decision now is to build everything on git, including the editor, a (newborn - be gentle with feedback :D) baby of VSCode + Figma to manage translations.

## Pros

- no hosting, accounts, and synchronization required.

- use git workflows like pull requests.

- automation via CI/CD.

- single source of truth that developers and translators collaborate on.

- unified architecture for dev tools and apps - low barrier for adoption. just one config file is needed.

## Cons

- uff, abusing a CLI as backend that runs in the browser on top of a virtual filesystem is challenging.

- scalability issues. larger repos (>30MB) take minutes to load or crash the browser

- complicated workflows. ask a translator what a commit is.

- the benefit of git might not justify the engineering and education effort we are conducted right now

# Try it out yourself (and roast me)

You can test the editor here https://inlang.com/editor/github.com/inlang/example.

While we are at it, could you try to contribute a translation? Can be jibberish, but it would make my day if I the contribution flow works :D

## Footnotes

[0] March 2022 "git as single source of truth" - https://github.com/inlang/inlang/discussions/115