inlang

lete. b) hardcoded heuristics are easier to iterate on, more cost efficient (0 costs) and easier to deploy (no API calls needed). # The message FINALLY AUTO GENERATION OF THE CONFIG https://www.loom.com/share/85d77004aa4c4bea9752d959c229e577 . The irony is that this is not needed anymore. The plugin API simplified the config interface so much that initializing configs only differs by the used plugins and their respective configs. The only useful thing that chatgpt provides is deriving what files in a filesystem are translation files. But a hardcoded version might be faster and more resilient. Learning: The GPT hype is ... well hype. The amount of work that went into this feature is insane. The work boils down to software engineering. Sure, tools will emerge that make prompt engineering easier but so does the previous ML hypetrain led to endless nocode machine learning tools. Yet, there is no "disruptive everyone builds ML models" (for GPT "everyone will become a developer") nocode machine learning tool in sight. Maybe signaling that the premise of ML NoCode/GPT of "this works for everything" is not true. Deriving what files are translation files, yep. Deriving an entire config file, maybe not. ## Footnotes [0] https://github.com/inlang/inlang/discussions/408#discussion-4914727

lopers 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