Languages and localization

Sparkus programs can be run in more than one language at the same time. Each participant sees screens, labels, and messages in their own language, while an admin manages the underlying wording from one place.

How multi-language programs work

A program is not limited to a single language. When a program supports several languages, each participant is shown the interface — labels, instructions, notifications — in whichever language applies to them, without needing separate copies of the program.

The platform ships with a broad catalogue of languages it understands (covering major world languages), but the languages actually offered to participants are narrower and controlled at two levels:

Company (tenant) level — an admin chooses which languages are enabled for the organization overall, and which one is the company’s default. If a company doesn’t explicitly restrict this, it’s treated as open to the platform’s standard customer-facing language set.
Program level — within a company’s enabled languages, a program admin chooses the subset of languages that specific program supports, and which of those is that program’s default. A program can’t offer a language the company hasn’t enabled — if the company’s list changes, program’s choices are automatically kept in line with it.

Today, the primary languages actively used by customers are English and Turkish, with other languages present in the catalogue for future or partial use — so “multi-language support” should be understood as a general platform capability rather than a promise that every catalogue language is fully translated everywhere.

The translation hierarchy: how wording is decided

Every piece of user-facing text in the system (button labels, messages, field names, and similar strings) is tracked as a translatable “key” — a stable identifier with a translated piece of text attached for each language. What text actually gets shown for a given key follows a simple three-level hierarchy, always resolved from most specific to least specific:

Program override (most specific) — if this exact program has its own custom wording for a key, in a given language, that wording wins, no matter what anyone else has set.
Company override (organization-wide) — if there’s no program-specific wording, but the company has set its own custom wording for that key, the company’s version is used. This lets an organization standardize terminology across all of its programs without editing every program individually.
System default (platform-wide) — if neither the program nor the company has customized a key, the platform’s built-in default text is used. This is the wording every key has out of the box.

In short: the most specific override always wins. A program-level customization beats a company-level customization, which beats the system default. This lets Sparkus ship sensible defaults for everything, while still giving an organization — or an individual program inside that organization — the ability to say “here, we want different wording.”

A couple of refinements to be aware of:

If a language isn’t the participant’s own and no translation exists at any level, the system generally falls back to English rather than showing nothing.
Turkish is treated more strictly: because Turkish is a primary, fully-supported customer language, the system does not silently fall back to English for Turkish users. If a Turkish translation is genuinely missing, the text shows as blank rather than switching languages on the user — a deliberate signal that a translation gap needs to be filled, not papered over.
An override that’s accidentally identical to (or a near-duplicate of) the system’s default English text is treated as “no real override,” so the ordinary default still applies. This avoids programs and companies accidentally locking in an untranslated placeholder as if it were an intentional customization.

What an admin does day to day

From a program’s language configuration screen, an admin can:

Choose the program’s supported languages — pick which of the company’s enabled languages this program should offer, and set the program’s default language (used when a specific participant’s language can’t be determined).
Write the program’s own name and description in each language — rather than relying only on system defaults, an admin can author a distinct name and description per language for the program itself.
Review and override specific labels/messages — a searchable list of translatable keys shows, for each language, the system’s default text alongside this program’s own override (if any). From here an admin can:
- See at a glance which keys are missing a translation for a given language.
- Type in a program-specific override for any key/language combination — this becomes the “program override” in the hierarchy above, and takes effect immediately for that program only.
- Clear a program-specific override, which simply reverts that key back to whatever the company or system default provides.
- Add brand-new translatable keys (for custom content that doesn’t already have one), following a structured naming pattern so keys stay organized and searchable.
- Remove a key entirely when it’s no longer needed.

This connects directly to Terminology & Labels work (choosing what things are called across the product) and to per-language message wording for notifications and other communications — both are expressions of the same override mechanism described above, just applied to different categories of text.

Bulk translation (import/export)

Editing translations one at a time is fine for a handful of tweaks, but admins can also work in bulk:

Export — pull out the current set of translatable keys and their text (system defaults plus any company/program overrides) as a file, useful for handing off to a translator or reviewing offline.
Import — upload a file of translations (as a spreadsheet-style file or a structured data file) to apply many changes at once, scoped to the same program/company/system levels described above. Before anything is saved, the system shows a preview of what will change — flagging each row as a brand-new translation, an update to an existing one, or a row that will be skipped — so an admin can confirm the bulk change before committing it. After committing, a summary reports how many entries were added, updated, or skipped, and flags anything that failed to import.

Bulk import/export works at whichever level the admin is operating at (a specific program, a company overall, or the shared system defaults), following the same override precedence as everyday manual edits.