Skip to main content
Translations localize the notifications you send with SuprSend. Instead of maintaining separate templates for each language, you can create a single template with translation keys that are automatically replaced with the appropriate language content based on the user’s locale setting.
Key concept: One template + multiple translation files = localized notifications for all your users.

How translations work

SuprSend handles localization automatically when sending notifications—no extra code required. The flow:
  1. Detect locale → Reads user’s $locale (set via API with $set_locale action or $locale parameter). Falls back to account default if unset.
  2. Find translation file → Searches using fallback hierarchy:
    • Exact match: es_MX.json (for es_MX locale)
    • Language fallback: es.json
    • Default fallback: en.json
  3. Replace keys → Replaces {{t "key_name"}} tags with translated values from the selected file. Interpolates variables like {{t "greeting" name=user.first_name}}.
  4. Send notification → Delivers localized content to the user.

Translation directory structure

Translation files must be organized by locale codes:
translations/
├── en/                  # English (base language)
   ├── en.json         # General translations
   └── auth.en.json    # Authentication-specific translations
└── en_GB/              # English (Great Britain)
    ├── en_GB.json      # General translations
    └── orders.en_GB.json # Order management translations
Naming convention: SuprSend supports underscore format (en_GB) for locale codes.
Files within each locale directory follow naming patterns based on their scope. Use the format that matches your needs:
TypeFormatDescriptionExample
Language only{language}.jsonTranslations for a specific language without regional variationsen.json
Language + Region{language}_{region}.jsonTranslations for a specific language in a specific region or countryen_GB.json
Namespaced files{namespace}.{language}.jsonTranslations for a specific feature or module in a specific languageauth.en.json

Fallback logic

SuprSend automatically finds the best translation using a fallback system. If a translation isn’t available, it tries the next best option:
  1. First try: Exact match for the user’s locale (es_MX.json for Spanish - Mexico)
  2. Second try: General language file (es.json for Spanish)
  3. Last try: Default language file (en.json for English)
When does fallback happen?
  • The translation file doesn’t exist
  • The translation key isn’t in the file
Result: Users always get a translation, even if it’s not in their exact language.
Best practice: Always maintain an en.json file as the base language. It ensures your system always has a fallback even if locale-specific keys are missing.

Translation key types

Translation keys can be organized using two main approaches:
  • Normal keys
  • Namespaced keys
Simple key-value pairs:
{
  "welcome": "Welcome!",
  "goodbye": "See you later!"
}
{{t "welcome"}}           <!-- Normal key -->
Benefits:
  • Simple and straightforward - Easy to understand and implement
  • Quick to set up - No need to plan namespaces upfront
  • Perfect for small projects - Ideal when you have limited translation keys
  • Direct access - Shorter syntax in templates
Potential conflict example:
{
  "title": "Welcome to our app",     // Auth page title
  "title": "Order confirmation"      // Order page title - CONFLICT!
}

Setup

Setting up translations in SuprSend requires three steps:
1

Upload translation files

Navigate to DashboardDevelopersTranslations and upload JSON files.Upload translation files interfaceCommit changes to make translations live. Learn more about managing translation files.
2

Set user locale

Set the user’s locale via API. The older method used preferred language, but you can now use locale directly with $set_locale action or $locale parameter. The locale determines which translation file SuprSend will use for that user’s notifications.Example:
{
  "$set_locale": "en_GB"
}
Use standard ISO locale codes like en_US, es_ES, fr_FR, en_GB, etc.
3

Use in templates

Add translation keys to templates using the {{t}} tag:
Subject: {{t "greeting"}}
Body: {{t "welcome_message"}}, {{user.first_name}}!
Preview your translations:
  1. Open template editor and add {{t}} tags
  2. Click Preview (top right corner)
  3. Select different locales from the dropdown
  4. Verify output matches expectations Language dropdown for previewing translations
🎉 Notifications will now automatically display in each user’s preferred language.

Using translations in templates

Use the {{t}} tag to localize content. Examples for common scenarios:
  • Basic usage
  • Dynamic content
  • Advanced: JSONNET
Static text that doesn’t change based on user data.
Subject: {{t "welcome"}}
Body: {{t "goodbye"}}
{
  "welcome": "Welcome!",
  "goodbye": "See you later!"
}
Output: "Welcome!" and "See you later!"
Group related translations by feature/module to avoid key name conflicts.
  {{t "auth:login"}}
  {{t "orders:status"}}
{
  "auth:login": "Sign in to continue",
  "orders:status": "Order status"
}
Output: "Sign in to continue" and "Order status"Use auth:title and orders:title instead of conflicting title keys.

One template for all languages

Instead of maintaining separate templates for each language, SuprSend uses a single template with translation keys. The template structure stays the same across all languages—only the text content changes. The problem it solves: Traditional approaches require duplicating templates for each language, which leads to:
  • Layout inconsistencies when updating styles across multiple files
  • Increased maintenance when fixing bugs or making design changes
  • Risk of forgetting to update all language versions
How it works: Create one template with translation keys, and SuprSend automatically replaces them with the appropriate language content:
<div class="welcome-card">
  <h1>{{t "welcome_title"}}</h1>
  <p>{{t "welcome_message" name=user.first_name}}</p>
  <button>{{t "get_started"}}</button>
</div>
File structure:
  • Traditional approach
  • SuprSend approach
Each language requires a separate template file:
templates/
├── welcome_en.html
├── welcome_es.html
├── welcome_fr.html
└── welcome_de.html

Managing translation files

Manage your translation files through the SuprSend dashboard or programmatically via API and CLI.

Translation process

SuprSend uses a commit-based process to manage translation changes safely. Development → Commit → Production
  1. Make changes - Add, edit, or delete translation files in the dashboard
  2. Review drafts - All changes are saved as drafts until committed
  3. Commit changes - Commit translations to make them live
  4. Version control - Every commit creates a new version with full history
Translation process

Add new translation files

Upload new translation files to add support for additional languages or create namespaced translations.
1

Navigate and select file

Go to DevelopersTranslations. Upload your JSON translation file and verify the file structure matches the required format.
File naming: Use correct naming convention (en.json, es_MX.json, or auth.en.json for namespaced files).
2

Upload file

Click the Next button to add the file.Upload translation file
3

Commit changes

Click Commit to make the translation file live.Commit translations

Edit existing translation files

Download, edit locally, and re-upload translation files.
1

Open translation file

Go to the translation file you want to edit.
2

Download file

Click Download to save the translation file locally for editing.Download translation file
3

Edit, upload and commit

Make your edits to the downloaded JSON file, then click Upload to replace the existing file. Finally, click Commit to make your translation changes live.

Delete translation files

Remove translation files that are no longer needed.
1

Delete file

Find the translation file you want to remove, and click Delete.Delete translation file
2

Commit deletion

Click Commit to publish the deletion.Commit translations
Deletion impact: Removing a translation file affects all users in that locale. They will fall back to the language file or default locale. Ensure you have fallback translations available.

Version control

All translation changes are automatically versioned with complete history and rollback capabilities.
1

Open version history

Go to DevelopersTranslations, click on a translation file, then open the Version History tab.
2

Select and rollback

Select the version you want to restore and click Rollback. Confirm the action.Rollback translation
3

Commit changes

Click Commit to make the rollback live.Commit translations
Rollback immediately affects all users in that locale. Test before rolling back.

Automating translation with CLI

Manage your translations programmatically using SuprSend’s CLI. For CLI commands and workflows, see the CLI translations overview.

Translation Management APIs

Programmatically manage translations using SuprSend’s Management APIs. For API documentation and endpoints, see the Translation Management API reference.

Supported locales

SuprSend supports standard ISO locale codes following the language_COUNTRY format:
Locale CodeLanguageCountry/Region
af_ZAAfrikaansSouth Africa
ar_AEArabicUnited Arab Emirates
ar_SAArabicSaudi Arabia
ar_EGArabicEgypt
az_AZAzerbaijaniAzerbaijan
be_BYBelarusianBelarus
bg_BGBulgarianBulgaria
bn_BDBengaliBangladesh
bs_BABosnianBosnia and Herzegovina
ca_ESCatalanSpain
cs_CZCzechCzech Republic
cy_GBWelshUnited Kingdom
da_DKDanishDenmark
de_ATGermanAustria
de_CHGermanSwitzerland
de_DEGermanGermany
el_GRGreekGreece
en_AUEnglishAustralia
en_CAEnglishCanada
en_GBEnglishUnited Kingdom
en_IEEnglishIreland
en_INEnglishIndia
en_NZEnglishNew Zealand
en_USEnglishUnited States
en_ZAEnglishSouth Africa
es_ARSpanishArgentina
es_CLSpanishChile
es_COSpanishColombia
es_ESSpanishSpain
es_MXSpanishMexico
es_PESpanishPeru
es_VESpanishVenezuela
et_EEEstonianEstonia
eu_ESBasqueSpain
fa_IRPersianIran
fi_FIFinnishFinland
fr_BEFrenchBelgium
fr_CAFrenchCanada
fr_CHFrenchSwitzerland
fr_FRFrenchFrance
gl_ESGalicianSpain
gu_INGujaratiIndia
he_ILHebrewIsrael
hi_INHindiIndia
hr_HRCroatianCroatia
hu_HUHungarianHungary
hy_AMArmenianArmenia
id_IDIndonesianIndonesia
is_ISIcelandicIceland
it_CHItalianSwitzerland
it_ITItalianItaly
ja_JPJapaneseJapan
ka_GEGeorgianGeorgia
kk_KZKazakhKazakhstan
km_KHKhmerCambodia
kn_INKannadaIndia
ko_KRKoreanSouth Korea
ky_KGKyrgyzKyrgyzstan
lo_LALaoLaos
lt_LTLithuanianLithuania
lv_LVLatvianLatvia
mk_MKMacedonianNorth Macedonia
ml_INMalayalamIndia
mn_MNMongolianMongolia
mr_INMarathiIndia
ms_MYMalayMalaysia
my_MMBurmeseMyanmar
ne_NPNepaliNepal
nl_BEDutchBelgium
nl_NLDutchNetherlands
no_NONorwegianNorway
pa_INPunjabiIndia
pl_PLPolishPoland
pt_BRPortugueseBrazil
pt_PTPortuguesePortugal
ro_MDRomanianMoldova
ro_RORomanianRomania
ru_RURussianRussia
si_LKSinhalaSri Lanka
sk_SKSlovakSlovakia
sl_SISlovenianSlovenia
sq_ALAlbanianAlbania
sr_RSSerbianSerbia
sv_SESwedishSweden
sw_KESwahiliKenya
ta_INTamilIndia
te_INTeluguIndia
th_THThaiThailand
tr_TRTurkishTurkey
uk_UAUkrainianUkraine
ur_PKUrduPakistan
uz_UZUzbekUzbekistan
vi_VNVietnameseVietnam
zh_CNChinese (Simplified)China
zh_HKChinese (Traditional)Hong Kong
zh_TWChinese (Traditional)Taiwan
zu_ZAZuluSouth Africa
Don’t see your locale? SuprSend supports all standard ISO 639-1 language codes and ISO 3166-1 alpha-2 country codes. Contact support if you need help with a specific locale.

Best practices

  • 🔑 Keep keys short: auth:login > authentication_login_button_text
  • 🔢 Always define plural forms: zero, one, other for consistent behavior
  • 📄 Maintain en.json as your canonical source
  • 🏷️ Use translation keys everywhere — avoid raw text in templates
  • 🏢 Don’t translate brand names — keep them consistent across locales

Troubleshooting

Even with proper setup, issues may be encountered. Here are common problems and their solutions:
Possible causes:
  • Changes not committed
  • Invalid JSON format
  • User locale not set
  • Key missing in fallback files
Solutions:
  1. Check if changes are committed - Uncommitted translations won’t be used
  2. Verify file format - Ensure valid JSON syntax
  3. Check user locale - Confirm user profile has correct locale set
  4. Review fallback chain - Check if key exists in fallback files
Possible causes:
  • Incorrect locale format
  • Case-sensitive key names
  • Outdated version
Solutions:
  1. Verify locale format - Use en_US, not en-us
  2. Check key name - Keys are case-sensitive (greetingGreeting)
  3. Review version history - Ensure you’re on the latest version
Possible causes:
  • Incorrect syntax
  • Variable name mismatches
  • Wrong namespace format
Solutions:
  1. Syntax check - Ensure proper {{t "key"}} format
  2. Variable names - Check variable names match translation file
  3. Namespace format - Use namespace:key, not namespace.key