We’re building Tolgee Apps: a way for anyone to extend Tolgee with their own plugins. Think of it like a project dashboard page, a panel next to a translation, or a webhook that reacts when a key changes. All running as a sandboxed iframe, talking to Tolgee through a signed, scoped API token.
Before we open this up to the world, we wanted to stress test it ourselves. So in June we ran a 3 day internal hackathon. Here’s how it went, what we built, and what’s coming next.
How the hackathon looked
We ran it Wednesday to Friday, June 10 to 12. Solo projects only, everyone builds their own thing.
The goal wasn’t to win a prize. It was to test what Tolgee Apps can actually do, find the rough edges, and figure out what the core platform still needs to support real use cases.
Wednesday started with a kickoff at 9:00. At 14:00 everyone pitched their idea and got feedback from the group, then it was straight into development with a hard stop at 7PM. Thursday had a hard stop at 5PM, then we headed to a pub for some fun together. Friday was hacking before lunch, then demos after: 15 minutes per person to show what they built.
We all scored every project except our own, ranking them worst to best.
What people built
Five people built five very different things, all on the same alpha SDK (@tolgee/apps-sdk). Here’s what each one does.
Jirka: an AI app store where the apps don’t really exist
Jirka’s project was the wildest idea of the hackathon: Tolgee App Store.
The store has no real apps. Every “app” is generated live by a Claude agent, and that same agent is the app’s backend forever. It renders every page, answers every request, and reacts to every interaction, on the fly. From the user’s side, it just looks like a normal Tolgee app they installed. They have no idea a model is quietly writing and running it behind the scenes.
Under the hood, each installed app gets its own child process with a goal queue: every unit of agent work is a “goal” that has to declare when it’s done, and the agent gets re-prompted if it stops early. Content gets published either as static (cached, served without asking the agent again) or dynamic (answers one request, then thrown away). It’s a genuinely new idea for how a plugin platform could work when the plugin is an AI, not code someone shipped once.
Zuzka: how good is our AI translation, really
Zuzka built Statistics, an app that answers a question we get asked a lot: how accurate is Tolgee’s AI translation?
For every AI translated string that a human later reviewed, it computes a match score. Word level edit distance between what the AI produced and what the reviewer finally approved. 100% means the reviewer changed nothing. It buckets results (100%, 90-99%, 80-89%, 70-79%, under 70%) and breaks them down per language, on a dashboard page and in a panel next to the translation you’re working on.
It also builds a full contributor leaderboard: who’s doing post-edits vs. translating from scratch vs. reviewing, a derived trust score, tiers, and gamified badges (yes, including a joke badge for people who type “maga” a lot, don’t ask).
What’s most interesting is what happened mid-hackathon: the app started out computing match scores itself, walking through translation history one by one. By the end of the week, we’d shipped a native ai-match-stats endpoint on the platform, and Zuzka’s app became a thin adapter on top of it. Exactly the kind of signal this hackathon was supposed to produce: an app pushed a real feature back into Tolgee’s core.
Capabilities used: dashboard page, translation tools panel (both the normal and “no cell selected” variants), webhooks, and read scopes on translations, keys, and activity.
Dima: two apps, both about visibility
Dima (Dmitrii) built two things.
Tolgee Insights is a read only analytics dashboard: progress per language, activity over time, key growth, human vs. TM vs. machine translation split, top contributors, QA issue heatmaps, duplicate translations, and character limit violations. Almost every number links straight back into the right filtered view in Tolgee. It’s frontend only, no webhooks, just a dashboard page pulling from the REST API (including a full project scan for the bigger stats, capped at 100k keys so it doesn’t run forever).
WPML Translation Management turns a Tolgee project into a translation vendor for WordPress sites running WPML. A project manager generates an API token in Tolgee, pastes it into WPML’s settings, and WPML starts sending translation jobs straight to Tolgee. Jobs get imported as keys, translated by the team, and exported back as XLIFF automatically. It even handles two different ways WPML can talk to a translation vendor, including a companion WordPress bridge plugin for the trickier one.
Capabilities used: dashboard page, webhooks (SET_TRANSLATIONS, CREATE_KEY), and translation edit/create scopes for the WPML app.
Barus: a guide that tells you what to do next
Barus built Activation Guide, an app for a very real problem: people sign up, poke around, and don’t know what to actually do next.
It reads a project’s real state (keys, translation and review percentage, recent import activity, whether content delivery is set up), scores three stages (setup, translation, delivery) from 0 to 100, and tells you which one needs attention next, in a genuinely encouraging tone written by AI and grounded in your actual project data. Not “you’re missing X”, more “here’s the next small step.”
It also has an “in-context” tab: answer two quick questions about your stack, and it generates a ready-to-paste brief for your coding assistant, so you can hand it to Claude or Cursor and have in-context editing set up in your app without digging through docs yourself.
Capabilities used: dashboard page, decorators, webhooks, and an AI backend that double checks every token against Tolgee itself before spending a single request, since the alpha SDK doesn’t verify tokens on its own yet.
Daniel: git integration
Dan built Git Sync, an app that keeps a Tolgee project and a Git repository's locale files in sync, in both directions.
You connect a repo, pick a branch, a file format (JSON, XLIFF, .properties, .po, Android XML, Apple .strings, Flutter .arb, YAML, and more), and a path pattern like locales/{languageTag}.json. From there the app tracks three states at once: what's in Tolgee, what's in Git, and what things looked like at the last successful sync. That third baseline is what makes it a real three-way merge instead of a naive overwrite. It can tell the difference between "changed in Tolgee", "changed in Git", "changed in both" (a conflict you resolve by picking a winner), and "converged", including handling file deletions in both directions.
A webhook flags the dashboard as "out of sync" the moment someone edits a translation in Tolgee. Every push or pull is checked against a fingerprint of the last preview, so you can never apply a change against a world that has since moved on.
Capabilities used: dashboard page, webhooks, and edit scopes on translations, keys, and languages (that last one because pulling a deleted locale file can delete a whole language in Tolgee).
Results
Zuzka
Dan
Barus
The ranking was a good reminder that user experience beats technical complexity. Some projects did more impressive things under the hood, but the ones that presented well and were easy to understand came out on top.
What’s next
This hackathon did exactly what we hoped: it found real gaps in the platform (some of which got fixed the same week), and it proved the concept works for very different use cases, from analytics to CMS integrations to an app that’s secretly just an AI agent.
Tolgee Apps is still alpha. Our plan is to get it to production by the end of September. Once that’s live, anyone will be able to build and install their own apps on Tolgee, the same way our team did during this hackathon.
If you have an idea for something you’d want to build on top of Tolgee, we’d love to hear about it.
