„Přidat španělštinu“ zní jako jeden úkol, dokud se do toho člověk nepustí pořádně. Překlad se dotýká každého popisku na každé obrazovce, každé validační hlášky, každé e-mailové šablony, každého tlačítka, každé položky v navigaci, každého oznámení — a hlavně i obsahu, který si vytvořil sám zákazník. Platforma, která s tím od začátku nepočítá, obvykle zvládne prohodit texty na pár místech, ale švy jsou brzy vidět — a právě u nich uživatel ztrácí důvěru. My jsme zvolili delší cestu.
Jazyk se u nás nastavuje pro každého uživatele zvlášť. Každý si ho zvolí jednou a rozhraní ho pak provází všude — v nabídkách, formulářích, pohledech, systémových hláškách, hlavičkách plánovaných e-mailů i v chybových dialozích, které vyskočí při výpadku sítě. Přepnutí jazyka se projeví okamžitě: nepotřebuje k němu administrátora, znovunačtení stránky ani přeinstalaci. Ve stejné instanci může současně pracovat víc lidí, každý ve svém jazyce, aniž by o sobě navzájem věděli.
Platforma se dodává s několika plně přeloženými jazyky. Každý pevně zabudovaný text rozhraní — a jsou jich tisíce — někdo prošel a přeložil ručně, ne strojově vysypal. To má svůj význam: strojový překlad sice trefí slovní zásobu, ale mine idiom, a to stačí k tomu, aby jinak vypiplaný produkt působil amatérsky. Vestavěné překlady prošly kontrolou člověka.
Čím se systém liší, je překlad na úrovni vlastní implementace zákazníka. Typy, které si instance nadefinuje, vlastnosti, které k nim připojí, moduly, do kterých je seskupí, uložené dotazy i filtry — to všechno lze přeložit do každého jazyka, který má dané prostředí zapnutý. Uživatel mluvící česky vidí Zákazník, jeho německy mluvící kolega u téhož záznamu vidí Kunde — a oba se přitom dívají na naprosto stejnou definici typu i stejný záznam. Správa překladů je jedno centrální místo, které vypíše každý přeložitelný text v implementaci; filtrování podle typu pomáhá udržet přehled, když se v rozsáhlém modelu nasčítá hodně textu.
Víc než holé pokrytí je důležitá konzistence, a tak si platforma udržuje řetězec záloh (fallback). Když u nově přidané vlastnosti chybí německý překlad, uživatel nevidí prázdno — ukáže se předdefinovaná výchozí hodnota, obvykle v jazyce implementace, zřetelně označená, aby vynikla a vybízela k doplnění pořádného překladu. Chybějící texty se tak nezvrhnou v trapné mezery v rozhraní a ve správě překladů se snadno najdou: umí vyfiltrovat právě položky, které do daného jazyka ještě přeložené nejsou.
Filtry a uložené dotazy fungují stejně. Filtr pojmenovaný v jednom jazyce Po splatnosti se v jiném jazyce zobrazí ve své obdobě, přičemž jde zjevně o tentýž kus konfigurace. Uživatelé z různých zemí tak sdílejí společný slovník uložených pohledů, aniž by kdokoli musel udržovat dvě souběžné kopie každého dotazu.
REST API si o jazyk řekne standardně, přes HTTP. Aplikace, která data odebírá, si může vyžádat odpovědi třeba ve francouzštině a dostane popisky i chybové hlášky francouzsky, zatímco samotná data zůstávají stejná. Díky tomu se API dá bez obav použít i pro white-label portály a partnerská napojení, kde se jazyk koncového uživatele různí.
Udržovat překlady v aktuálním stavu, jak se datový model vyvíjí, je svého druhu disciplína a platforma se snaží, aby byla zvládnutelná. Když přidáte novou vlastnost nebo filtr, správa překladů ji ukáže jako čekající položku. Často stačí krátká týdenní revize a pokrytí zůstává těsné. Prostředí, které expanduje do nových regionů, obvykle vystačí s jedním průchodem správou překladů s pohledem na konkrétní jazyk — a nový jazyk je hotový.
Lokalizace patří mezi věci, které rozhodují o tom, jestli se platforma dá nasadit v mezinárodních organizacích, nebo ne. Bereme ji jako základ, ne jako dodatek — a je to znát v detailech, což je asi to nejlepší doporučení, jaké taková funkce může dostat.