Run your i18n strings from a Google Sheet

Why localize from a Sheet

i18n is a table by nature: a key column and a column per locale. A spreadsheet shows the whole matrix at once, so a translator can see the English source next to the French cell they are filling in, and a missing translation is an obvious blank. Hand-editing JSON or PO files, by contrast, is a job only developers can do.

PasteSheet serves that grid as clean JSON over a fast, cached endpoint. Your app fetches the strings for a locale and renders them; translators just edit cells in Google Sheets. Add a column, add a language — no schema change, no migration, no release to get new copy in front of users.

How to structure the sheet

One tab, one row per string key, one column per locale:

• A key column — the stable identifier your app looks up, like checkout.title.
• A column per locale — en, es, fr, de — holding the translated copy.
• Optional context or notes columns to brief translators without leaving the sheet.
• Fetch one key at a time, or pull the whole tab and cache it as your locale bundle.

Fetch translations as JSON

Point your app at the endpoint and read the strings. Filter to one key, or pull them all and build a locale map:

curl "https://pastesheet.com/your-endpoint/Strings?key=checkout.title"

{
  "data": [
    {
      "key": "checkout.title",
      "en": "Checkout",
      "es": "Pagar",
      "fr": "Commander",
      "de": "Zur Kasse"
    }
  ]
}

Read-only, so it is safe to hand to translators

Because the endpoint is read-only by design, it is safe to expose publicly or hand to a teammate: consumers can read and query the data but can never change the sheet. And there is no Google Cloud project, OAuth screen, or service account to set up — you paste a share URL and get a live API.

What it costs

Frequently asked questions

Sources

• Files you can store in Google Drive (size limits) — Google

Related use cases