Show HN: Stripe for localization that abuses Git as back end(github.com)
github.com
Show HN: Stripe for localization that abuses Git as back end
https://github.com/inlang/inlang
1 comments
I haven't read your repo very carefully, but this strikes me as strange:
> - no hosting, accounts, and synchronization required.
> - use git workflows like pull requests.
that seems self-contradictory? "git" tool has no support for pull requests, only websites like github support it. And "git" only deals with local files, you need to either _host_ your own git repo, have _account_ on github, or use some sort of (rare) _synchronization_ system.
When you say "git", do you mean "github.com" by any chance? Because then you can use 'repos/contents' API endpoint to get and update contents without emulating git in javascript.
> - no hosting, accounts, and synchronization required.
> - use git workflows like pull requests.
that seems self-contradictory? "git" tool has no support for pull requests, only websites like github support it. And "git" only deals with local files, you need to either _host_ your own git repo, have _account_ on github, or use some sort of (rare) _synchronization_ system.
When you say "git", do you mean "github.com" by any chance? Because then you can use 'repos/contents' API endpoint to get and update contents without emulating git in javascript.
Updated to "extra accounts":
no hosting, extra accounts, or synchronization required. use git(hub) workflows like pull requests.
no hosting, extra accounts, or synchronization required. use git(hub) workflows like pull requests.
The phrasing is not precise. No accounts are required for our service. A GitHub account is required ofc.
I will update the readme!
I will update the readme!
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