I built a free tool to translate Android, iOS, and Flutter string files (and here's how the translation actually works under the hood)

Every time I've localized an app, it's gone one of two ways: hand-translate
the strings myself (slow, and my Spanish/French/whatever is not great), or
set up a full localization platform for what's really a five-minute job on
a small project.

So I built StringLingo AI — a free
tool that translates:

• Android strings.xml
• iOS Localizable.strings
• Flutter .arb files
• Or just plain pasted text

Upload the file, pick a target language, download a translated file with
the same keys and structure. No account, nothing stored.

The part I actually want feedback on

The interesting problem wasn't the UI, it was not breaking your strings
while translating them. Localization files are full of things a naive
translation pass will mangle:

xml
<string name="welcome_message">Hello %1$s, you have %2$d new messages</string>

Comments

[Amit Feldman]

Nice tool — a translator that handles XML, .strings, and ARB in one place is exactly the unglamorous utility mobile teams end up needing at 11pm. I ran my usual launch-day scan on string-lingo-ai.vercel.app while reading, sharing in case it's useful:

• HSTS is preloaded and nosniff, Referrer-Policy, and Permissions-Policy are all set — you're ahead of most launches I scan.
• Content-Security-Policy is missing — the one gap worth closing. On Vercel it's a small headers block in vercel.json (or headers() in next.config if it's Next.js). Even a starter default-src 'self' plus your API/AI endpoints mitigates XSS and data-injection.
• X-Frame-Options is also unset — one line (frame-ancestors 'self' inside the CSP covers it too) and clickjacking is off the table.
• SEO side is clean: title, meta description, exactly one H1, robots.txt and sitemap all good. TLS fine, 52 days on the cert.

I run these passive launch scans for free — happy to send the full report (14 checks with the timing breakdown) if you want it. Congrats on shipping!

[kamrandev-star]

Thanks for the scan, genuinely useful! You're right on both counts —
CSP and X-Frame-Options are the two I hadn't gotten to yet. Adding a
starter CSP now. Appreciate you flagging it rather than just moving on.

[Amit Feldman]

Deployed and verified — just re-ran the scan on the live site: 16/16 checks pass now.

CSP is in place (default-src 'self' with the Google Fonts allowances), X-Frame-Options: DENY, and everything else was already clean. Nice turnaround.

One small observation from the CSP: script-src and style-src both carry 'unsafe-inline'. That's fine while you have inline scripts/styles, but if you ever move them to files you can drop those tokens and meaningfully tighten XSS resistance. Nonce-based CSP is the gold standard there but honestly not worth the complexity at this stage.

Since you asked about the deeper pass earlier — the free scan covers headers/TLS/SEO surface. The full Quick Scan ($49) goes further: exposed files & secrets (.env, .git, backups), dependency/SRI checks, forms & auth surface, performance budget, and a prioritized fix list with copy-paste configs for Vercel. It's at gumroad.com/l/keikf if you want the full picture before traffic picks up.

Either way — solid launch hygiene now. Good luck with StringLingo.