🌍 Localize Your Slack Ops Bot for Global Teams With AI Translation

Our ops bot spoke English. That was fine until we opened an office in Munich and another in São Paulo, and suddenly half the people reading our deploy notifications were parsing them in a second language at 9pm their time. The information was getting through, but slowly and with less confidence. I decided the bot should speak each person’s language. AI made bulk translation feasible, but I learned quickly that machine-translated ops copy needs a human native speaker’s eye before it ships to a real workspace.

Localization is more than translation

A localized bot does three things. It detects the reader’s preferred language, it serves the message text in that language, and it does so without breaking the Block Kit structure or the variable interpolation. The translation itself is where AI shines, but the structure around it, knowing which user gets which locale and keeping the formatting intact, is plain engineering. Get the engineering right and the model’s job becomes a clean, reviewable task.

Detecting the user’s locale

Slack exposes a user’s locale if your app requests it. With users.info and the include_locale flag, you get an IETF tag like de-DE or pt-BR:

async function getUserLocale(client, userId) {
  const res = await client.users.info({ user: userId, include_locale: true });
  return res.user.locale || "en-US";
}

I cache this per user; it rarely changes, and calling users.info on every message would chew through rate limits.

Keying messages by locale

I never translate at send time for static strings. I maintain a catalog of message keys with translations, generated ahead of time and reviewed. At send time I just look up the key for the user’s locale:

function t(key, locale, vars = {}) {
  const lang = locale.split("-")[0];
  const template = catalog[key]?.[lang] || catalog[key]?.en;
  return template.replace(/\{(\w+)\}/g, (_, v) => vars[v] ?? "");
}

This keeps placeholders like {service} and {status} intact across languages, which matters because translation tools love to “helpfully” translate or reorder your variable names.

Generating the catalog with AI

The AI’s job is the bulk translation pass that fills the catalog. I feed it the English strings with context about where each appears, because “Open” as a button means something different from “Open” as a status.

const prompt = `Translate these Slack bot UI strings to ${targetLang}.
Keep placeholders like {service} EXACTLY as-is, untranslated.
Match the tone: concise, professional ops messaging.
Return JSON mapping each key to its translation.

${JSON.stringify(stringsWithContext, null, 2)}`;

The model is a fast junior translator here. It produces a solid first draft for every string at once, which would take a human days. But I do not ship that draft directly.

Pro Tip: Tell the model to preserve placeholders verbatim and then validate it. Write a check that every {var} in the source still appears in the translation. A “translated” placeholder is the most common way a localized bot silently breaks.

The non-negotiable human review

Machine translation of ops copy gets the meaning right and the nuance wrong. “Acknowledge” might come back as a stiff or ambiguous word; an idiom in your English copy might translate into nonsense. So every generated catalog goes to a native speaker on that team for a review pass before it reaches the workspace. We use a simple spreadsheet: English on the left, AI draft in the middle, the reviewer’s corrected version on the right. Only the right column ships.

This is the same principle that governs every bot I deploy: the AI does the fast, broad first draft, and a human who knows better reviews it before it touches real users. A wrong translation in a deploy alert is not just embarrassing; it can cause someone to misread the severity of an incident.

Rendering localized Block Kit

With a reviewed catalog, the actual send is trivial. I build blocks using t() for every string:

async function sendLocalizedDeploy(client, channel, userId, vars) {
  const locale = await getUserLocale(client, userId);
  await client.chat.postMessage({
    channel,
    text: t("deploy.fallback", locale, vars),
    blocks: [
      { type: "header", text: { type: "plain_text", text: t("deploy.title", locale, vars) } },
      { type: "section", text: { type: "mrkdwn", text: t("deploy.body", locale, vars) } },
    ],
  });
}

Note the text fallback is also localized; notifications and screen readers use it.

Tokens and signatures

The bot token stays in an environment variable and never reaches the model. The model only ever sees UI strings to translate, never a credential or a real user’s data. Any interactive components, like a language-switcher button in the App Home, post back to a public endpoint, so Bolt verifies the Slack signing secret on every request against the raw body and timestamp. If you hand-roll an endpoint, verify that HMAC yourself and reject stale requests.

Tuning and fit

I refined the translation prompt in the prompt workspace, checking placeholder preservation across several languages, then saved the stable version to prompts. The localization templates in the prompt packs cover the placeholder-safety phrasing so you do not have to discover it the hard way. For building the catalog tooling I used Cursor and Claude, reviewing each change, and the broader bot patterns live in the Slack category.

Conclusion

A localized ops bot meets your global teammates in their own language, which means they read your alerts faster and with more confidence. Detect locale from Slack, key messages by language, let AI generate the bulk translation draft, and never ship a string a native speaker has not reviewed. Validate that placeholders survive translation, verify every inbound signature, and keep tokens out of the model. The AI translates broadly; a human polishes before it speaks to your workspace. That is what turns rough machine output into copy your team actually trusts.