After 3 years of tab-switching between flutter localization files, I finally built the thing Xcode has had since 2023
A scene that I bet half of you recognize:
It's Friday afternoon. You add a new key to app_en.arb. Then app_ar.arb. Then app_ku.arb, app_fr.arb, app_es.arb. You're four tabs deep, you've already lost track of which file you're in the build that says "login_button" because you missed one.
The format isn't the problem. ARB is fine. The problem is that you're editing N parallel files when you should be editing one grid.
Apple solved this for iOS in 2023 with String Catalogs — one file, one editor, every locale as a column. It's so much better that going back to parallel .arb files feels primitive.
So I built it for Flutter. It's called Stringboard, it's a VS Code extension, it's free, MIT, no telemetry, no cloud, no account.
v0.1 is intentionally minimal. What's on the v0.2 candidate list:
- EasyLocalization JSON support
- Search/filter bar across keys
- "Add language" button to scaffold a new locale
- Add button for new key record
- Right-click "Edit in Stringboard" on .arb files in the explorer
- CSV import/export for handing strings to human translators
Genuine question for this sub: if you had to pick ONE of those for v0.2, which would actually save you time? I'd rather build the one thing you'd use weekly than ship five features nobody asked for.
Links:
- Marketplace: https://marketplace.visualstudio.com/items?itemName=MohammedRzgar.stringboard
- Source (MIT): https://github.com/Mhamad-Rzgar/Stringboard
Happy to answer anything about the implementation