Jedna aplikace, 24 trhů: Meziplatformní lokalizace pro iOS a Android

Základy lokalizace aplikací pro iOS a Android

Lokalizace aplikace pro obě platformy začíná pochopením jejich ekosystémů. iOS a Android se liší nejen v programovacím jazyce (Swift vs. Kotlin/Java), ale také v nástrojích pro lokalizaci, optimalizaci App Store a úpravy UI. Vývojáři pro iOS používají Xcode se soubory .strings nebo .xcstrings, zatímco Android spoléhá na XML zdroje ve složkách res/values. Oba systémy podporují pravidla pro množná čísla a řetězce s placeholdery, ale implementace se liší: Android používá ICU-MessageFormat, iOS naopak NSString placeholdery jako %@ a %d. Praktický příklad: Překlad „1 výsledek“ vs. „%d výsledků“ musí v Androidu probíhat pomocí Quantity-Strings (one/other), v iOS pomocí speciálních .stringsdict souborů. Pokud jsou tyto rozdíly ignorovány, dochází k gramatickým chybám ve 24 jazycích.

Optimalizace App Store (ASO) vyžaduje metadata specifická pro platformu. Pro Google Play Store je třeba lokalizovat název (30 znaků), krátký popis (80 znaků) a dlouhý popis (4000 znaků). V Apple App Store jsou limity podobné – 30, 80 a 4000 znaků, ale pole pro klíčová slova (100 znaků) existuje pouze u iOS. V praxi se ukazuje, že klíčová slova v App Store mají často větší váhu než název. Další rozdíl: Android umožňuje překlad produktů v aplikaci přímo v Play Console, iOS vyžaduje samostatné lokalizované popisy v App Store Connect. Co se týče délky textu, vývojáři by měli počítat s roztažením o 30–50 % u asijských jazyků.

Nástroje pro pracovní postup jako Lokalise nebo Crowdin nabízejí multiplatformní integraci, ale doručení probíhá odděleně. Osvědčeným přístupem je použití centrální překladové paměti (Translation Memory) a automatické generování souborů specifických pro platformu. Důležité: Překladatelé musí znát kontext – popisek tlačítka „Odeslat“ může v závislosti na kontextu znamenat „Submit“ nebo „Send“. Měly by být přiloženy screenshoty a rozvržení UI. Z právního hlediska je třeba dbát na to, aby překlady popisů aplikací neobsahovaly zavádějící tvrzení; doporučuje se vlastní právní poradenství pro každý cílový trh.

Internacionalizace: Příprava pro obě platformy

Internacionalizace (i18n) je základem každé úspěšné lokalizace. Začíná oddělením kódu a textu: všechny zobrazované řetězce by měly být uloženy v souborech zdrojů, nikoli pevně zakódovány v kódu. Pro iOS to znamená použití NSLocalizedString, pro Android odkaz na @string zdroje. Častou chybou je spojování řetězců (např. „Máte „ + count + „ zpráv“). To v mnoha jazycích nefunguje, protože se pořadí slov liší. Místo toho je třeba použít placeholder s parametry pozice: u iOS %1$@ a %2$d, u Androidu %1$s a %2$d. V praxi se ukazuje, že i zkušení vývojáři často zapomínají internacionalizovat data, jako jsou formáty data a čísel. NSDateFormatter (iOS) a SimpleDateFormat (Android) by měly být vždy nastaveny na národní prostředí uživatele.

Obrázky a ikony s textem jsou problematické: musí být buď nahrazeny ikonami bez textu, nebo znovu vykresleny pro každý jazyk. V iOS mohou Assets.xcassets obsahovat lokalizované obrázky, v Androidu res/ s jazykovými kvalifikátory (např. res/drawable-cs/). Také rozvržení musí být flexibilní: německé texty jsou obvykle o 30 % delší než anglické, japonské často kratší. Používejte Auto Layout (iOS) nebo ConstraintLayout (Android) pro umožnění dynamických výšek a šířek. Negativní příklad: Tlačítko s pevnou šířkou 100 px zobrazující „Nastavení“ se v řeckém překladu „Ρυθμίσεις“ nezobrazí celé.

Dalším aspektem je třídění a vyhledávání. Při třídění seznamů je třeba dodržovat jazyková pravidla (např. přehlásky v němčině, čínské třídění podle pchin-jinu). Pro vyhledávání by měl být text normalizován (např. ignorovat velká/malá písmena, sjednotit diakritická znaménka). Příprava zahrnuje také stanovení lokalizačního procesu: které soubory budou předány překladatelům? Jak probíhá zajištění kvality? Doporučuje se nastavení CI/CD pipeline, která při každém sestavení kontroluje úplnost lokalizačních souborů. Upozornění: Internacionalizace musí být dokončena před první lokalizací – následné změny vyžadují nové překlady. Doporučuje se vlastní právní poradenství k požadavkům na ochranu údajů v různých zemích (např. GDPR v EU).

Platformově specifické rozdíly v UI a úpravy

iOS a Android se řídí odlišnými designovými pravidly, která ovlivňují i lokalizaci. iOS používá Human Interface Guidelines s důrazem na čistou typografii a konzistentní navigaci (Tab Bars, Navigation Bars). Android s Material Designem sází na stíny, elevaci a Floating Action Buttons. Tyto rozdíly se promítají do prvků UI: například seznamy v iOS mají standardně bílé pozadí, v Androidu často světle šedé. Pro lokalizovaný obsah to znamená, že texty musí mít vysoký kontrast a dostatečné řádkování. V praxi se ukazuje, že německé texty kvůli dlouhým slovům (např. „Druckertreiberinstallation“) na malých obrazovkách rychle zalamují – v iOS je častěji nutné automatické přizpůsobení řádků pomocí .lineBreakMode = .byWordWrapping, v Androidu pomocí android:maxLines a ellipsize.

Písma se liší: iOS standardně používá San Francisco, Android Roboto. Obě podporují latinku, cyrilici, čínštinu atd., ale u nelatinkových písem jako arabština (zprava doleva) jsou nutné speciální úpravy. iOS nabízí NSWritingDirection, Android android:gravity a layoutDirection. Konkrétní příklad: uspořádání ikon a textu v tab baru musí být pro jazyky RTL zrcadleno. V iOS stačí aktivace „Right-to-Left“ v Info.plist, ale všechna vlastní rozvržení musí být kompatibilní s autolayoutem. Android podporuje RTL od API 17, vyžaduje však další atributy v layoutových souborech. Pokud toto zrcadlení chybí, působí aplikace neprofesionálně.

Dalším bodem je zpracování množných čísel. Zatímco Android disponuje Quantity-Strings (zero, one, two, few, many, other), iOS používá .stringsdict s pravidly CLDR pro množná čísla. Vývojáři musí zajistit, aby pro každý jazyk byly poskytnuty správné kategorie množných čísel. Polština má např. čtyři tvary: 1, 2-4, 5-21 a výše. Při testování by se měly projít všechny jazyky. Také formáty čísel (např. 1.000 vs. 1,000) a měny (€ v Německu vs. € ve Francii) musí být formátovány specificky pro platformu. Tip: používejte NSNumberFormatter (iOS) a NumberFormat (Android) s příslušným locale. Na závěr: testujte aplikaci na reálných zařízeních s různými jazyky a ujistěte se, že žádné texty nejsou oříznuty. Doporučuje se vlastní právní poradenství k požadavkům na přístupnost (např. WCAG) pro obě platformy.

Optimalizace App Store (ASO) pro iOS a Android

Optimalizace App Store se mezi iOS a Android liší především v algoritmech, faktorech hodnocení a dostupných polích. V Apple App Store hrají ústřední roli název aplikace a klíčová slova v poli Keywords, zatímco podtitul a kategorie také ovlivňují. V Google Play mají největší váhu název aplikace a krátký popis (Short Description), následované úplným popisem (Full Description). Google Play navíc zohledňuje hodnocení uživatelů, frekvenci aktualizací a počet instalací – bez konkrétního uvedení faktorů. V praxi byste měli pro oba obchody zvolit jednotný vzhled značky, ale využít jejich charakteristiky. Pro iOS se vyplatí vyčerpat 30znakový limit pro klíčová slova v poli a v místním jazyce vyhledat relevantní vyhledávací výrazy. Pro Android byste měli krátký popis (maximálně 80 znaků) udržet přesný a v dlouhém popisu přirozeně začlenit klíčová slova.

Další rozdíl spočívá v pravidlech pro snímky obrazovky: Apple povoluje až deset snímků na velikost, Google až osm. Obě platformy používají snímky obrazovky jako faktor hodnocení, protože ovlivňují míru konverze. ASO pro oba obchody proto vyžaduje kontinuální optimalizaci vizuálních aktiv. V praxi byste měli pro každý trh provádět A/B testy – Apple nabízí optimalizaci stránky produktu, Google Play provádí experimenty. Testujte různé texty obrázků, rozvržení a barvy, které kulturně odpovídají. Vyhněte se generickým přístupům: snímek, který funguje dobře v Německu, může v Japonsku kvůli odlišným čtecím návykům nebo barevné symbolice dopadnout hůře.

Konkrétní doporučení: Pro každý cílový jazyk definujte seznam klíčových slov zahrnující jak obecné, tak nische výrazy. Používejte místní nástroje jako Apple Search Ads Keyword Generator nebo Google Keyword Planner pro Play. Pravidelně upravujte metadata, alespoň každé tři měsíce. Sledujte hodnocení a konkurenci v jednotlivých obchodech, aniž byste jmenovali přímé konkurenty. Mějte na paměti, že ASO není jednorázový proces, ale vyžaduje průběžnou optimalizaci. Pro právní otázky týkající se ochranných známek nebo zavádějících klíčových slov se prosím poraďte s právním poradcem.

Lokalizace metadat: Názvy, popisy, klíčová slova

Lokalizace metadat, jako jsou názvy, podnadpisy, popisy a klíčová slova, je zásadní pro dohledatelnost na zahraničních trzích. Prostý překlad většinou nestačí, protože se liší vyhledávací zvyklosti a jazykové struktury. Název aplikace by měl v každém jazyce sdělovat hlavní funkci nebo přínos, ale zároveň obsahovat značku. V mnoha asijských trzích je běžný delší název s popisnými prvky, zatímco v západních zemích se preferuje stručnost. Pro iOS dodržujte limit 30 znaků pro název a 30 znaků pro podnadpis; pro Android je limit 30 znaků pro název a 80 znaků pro krátký popis. Dlouhý popis v Google Play může mít až 4000 znaků – využijte tento prostor pro podrobné informace, ale v přirozeném jazyce.

Při rešerši klíčových slov pro různé jazyky nepřekládejte pouze doslovně, ale zahrňte synonyma a kulturně specifické výrazy. V praxi se osvědčuje vytvořit pro každý cílový jazyk seznam 10–20 nejrelevantnějších klíčových slov a ověřit je pomocí nástrojů jako Sensor Tower nebo App Annie. Pro iOS můžete pole klíčových slov vyplnit samostatně až 100 znaky; uvádějte pouze výrazy, které se již nevyskytují v názvu nebo podnadpisu. U Google Play pole pro klíčová slova explicitně neexistuje, ale klíčová slova se indexují z krátkého a dlouhého popisu. Dbejte na to, aby popisy nepůsobily přeplácaně klíčovými slovy, protože to může vést k penalizaci – Google Play očekává přirozenou textovou strukturu.

Doporučení: Pro každý trh proveďte samostatnou rešerši klíčových slov, ideálně s rodilými mluvčími. Přizpůsobte název a popis také místním zvláštnostem – ve Francii se například očekává formální oslovení, zatímco v USA je běžný uvolněný tón. Je třeba zohlednit i právní aspekty: v některých zemích lze výrazy jako „zdarma“ nebo „nejlepší“ používat jen za určitých podmínek. Nechte si v této věci poradit od právníka. Po aktualizaci metadata testujte: sledujte zobrazení a míru konverze alespoň dva týdny, než změny finalizujete. Pamatujte, že ASO metadata nejsou statická – měla by se aktualizovat podle sezónních trendů nebo nových funkcí.

Snímky obrazovky a náhledy aplikací na různých trzích

Snímky obrazovky a náhledy aplikací (videa) jsou často prvním vizuálním dojmem z vaší aplikace v obchodě a rozhodujícím způsobem ovlivňují míru prokliku a stažení. Pouhý překlad textu na obrázcích nestačí: kulturní rozdíly ve vnímání barev, směru čtení nebo zobrazování lidí a symbolů mohou změnit účinek. Na západních trzích se často preferuje jasný, minimalistický design, zatímco v asijských zemích jako Japonsko nebo Jižní Korea je běžná vyšší informační hustota na jednom snímku. Také uspořádání prvků musí být přizpůsobeno směru čtení: pro trhy s písmem zprava doleva (např. arabština) byste měli snímky zrcadlit, aby tok pohledu působil přirozeně.

Při tvorbě lokalizovaných snímků obrazovky se doporučuje modulární rozvržení: pozadí, text a vizuální prvky jsou odděleny, abyste pro každý trh mohli vyměnit pouze textovou vrstvu. Používejte přitom místní písma, která správně zobrazují příslušné znaky. Dbejte na kulturní kódy: ruka ukazující palec má na Blízkém východě nebo v západní Africe jiný význam. Na snímcích zobrazujte osoby s oblečením nebo barvou pleti typickou pro daný trh – vyhněte se však stereotypům. Také volba barev může ovlivnit konverzi: v Číně červená symbolizuje štěstí, zatímco v Jižní Africe může být spojována se smutkem. V praxi byste měli identifikovat hlavní trhy a pro ně vytvořit samostatné sady snímků, které ověříte v A/B testech.

Náhledy aplikací (videa) jsou náročnější, ale obzvláště cenné pro konverzi. Lokalizujte nejen mluvený text, ale také vloženou grafiku nebo animace. Dbejte na to, abyste vytvořili místní jazykové verze s vhodnými mluvčími. Délka videa by neměla přesáhnout 30 sekund a měla by ukazovat hlavní funkce. V zemích s pomalým připojením k internetu minimalizujte velikost souboru – používejte kompresi, aniž byste příliš ovlivnili kvalitu. Konkrétní doporučení: Pro každý cílový trh vytvořte kontrolní seznam kulturních úprav (barvy, symboly, osoby, směr čtení) a nechte si materiály zkontrolovat místním týmem. Po zveřejnění provádějte měsíční vyhodnocení konverzních poměrů a v případě potřeby snímky upravte. Právně zajištěni byste měli být při použití vyobrazení skutečných osob nebo značek – v případě potřeby si vyžádejte souhlas.

Správa překladů a práce s terminologií

Konzistentní správa překladů je základem úspěšné lokalizace aplikací na iOS a Android. Prvním krokem je zavedení systému pro správu překladů (TMS), který centrálně spravuje všechny jazykové zdroje. V praxi se osvědčilo udržovat texty v oddělené vrstvě od kódu, například pomocí lokalizačních souborů jako .strings (iOS) nebo .xml (Android). Ty lze pak přímo importovat do TMS a odtud předávat překladatelům nebo strojovým systémům.

Klíčová je údržba celopodnikového glosáře a stylistické příručky. Glosář stanovuje pro každý jazyk závazné překlady odborných termínů, názvů produktů a prvků uživatelského rozhraní. Tím se zabrání tomu, aby byl stejný anglický výraz v různých kontextech překládán odlišně. Stylistická příručka definuje tón, pravidla formulace (např. vykání nebo tykání) a řeší specifika jednotlivých platforem: na Androidu jsou tlačítka často kratší, zatímco iOS umožňuje delší texty. Ve stylistické příručce by měly být také uvedeny limity počtu znaků obchodů (30 znaků pro název na iOS, 30 na Google Play).

Dalším důležitým aspektem je práce s terminologií. Patří sem pravidelné ověřování konzistence a aktuálnosti používaných výrazů. V praxi se osvědčilo čtvrtletní přezkoumání glosářů odbornými odděleními. Kromě toho by se měly vytvářet překladové paměti (Translation Memories), které rozpoznávají opakující se fráze a zvyšují tak efektivitu. Dbejte na to, aby byly překladové paměti použitelné napříč platformami, protože mnoho textů (např. nastavení, chybové zprávy) může být na iOS a Android shodných.

Konkrétní doporučení: Používejte TMS jako Crowdin nebo Phrase, které nabízejí přímou integraci do vašeho CI/CD pipeline. Udržujte centrální glosář s alespoň 200 položkami na jazyk a zaveďte stylistickou příručku zohledňující také omezení uživatelského rozhraní jednotlivých platforem. Před každým větším vydáním zkontrolujte všechny termíny a změny dokumentujte pomocí verzování.

Poznámka: V případě právních otázek týkajících se překladu obchodních podmínek nebo prohlášení o ochraně osobních údajů se obraťte na právního poradce.

Pracovní postupy: Lokalizace v agilních vývojových procesech

Integrace lokalizace do agilních vývojových procesů vyžaduje úzké propojení vývoje, překladu a zajišťování kvality. Osvědčily se tzv. „lokalizační sprinty“, které probíhají souběžně s vývojovými sprinty. Texty k překladu jsou identifikovány již v plánování sprintu a zaznamenány jako user stories. Překlad probíhá s časovým odstupem, ideálně v rámci jednoho sprintu, aby bylo možné lokalizované texty otestovat v následujícím sprintu.

Klíčovým prvkem je automatizace. Využívejte Continuous Integration (CI) pipeline, které při každém commitu kódu automaticky extrahují lokalizační soubory a odešlou je do vašeho TMS. Po překladu jsou soubory vráceny zpět do repozitáře. Pro iOS se nabízí nástroj Fastlane s akcí `lane :refresh_localization`; pro Android můžete použít Gradle tasky. V praxi se osvědčilo verzovat lokalizační soubory v samostatné větvi, aby se předešlo konfliktům.

Další výzvou je správa změn. Pokud se v průběhu sprintu změní zdrojový text, musí být překlady aktualizovány. Zde pomáhá „string freeze“: několik dní před koncem sprintu se texty zmrazí a mění se pouze v případě naléhavých oprav chyb. Všechny nové nebo změněné řetězce jsou automaticky označeny v náhledu v TMS. Pro spolupráci s překladateli se doporučuje přístup „continuous localization“, kdy se překládají malé objemy textů průběžně, nikoli najednou na konci.

Konkrétní doporučení: Implementujte workflow založený na Gitu s automatickým exportem/importem lokalizačních souborů. Definujte jasná rozhraní mezi vývojářskými týmy a překladateli, např. prostřednictvím integrací se Slackem. Zaveďte dvoutýdenní sprintový rytmus, kde je lokalizace pevnou součástí definice hotového (Definition of Done). Lokalizované sestavení testujte již v rámci sprint review.

Poznámka: U agilních metod může být nutná úzká koordinace s produktovým managementem, aby se podcenily jazykové změny. V případě použití lokalizovaného obsahu v regulovaných oblastech (zdravotnictví, finance) si vyžádejte právní poradenství.

Testovací strategie pro lokalizované aplikace na obou platformách

Testování lokalizovaných aplikací vyžaduje vícevrstvou strategii, která zahrnuje jak automatické, tak manuální kontroly. Začněte automatizovanými testy na úrovni textu: použijte skripty, které kontrolují, zda jsou všechny řetězce správně lokalizovány (žádné chybějící překlady) a zda jsou dodržena omezení délky znaků. Pro iOS lze použít UI test s XCTest, který kontroluje, zda se v německé lokalizaci neobjevuje angličtina; pro Android je k dispozici Espresso s podobnými funkcemi. Tyto testy by měly být součástí vaší CI pipeline a spouštět se při každém sestavení.

Kromě toho jsou nepostradatelné kulturní a kontextové testy. Nechte rodilé mluvčí otestovat aplikaci na reálném zařízení v každém cílovém trhu. Přitom kontrolujete nejen kvalitu překladu, ale také správné zobrazení formátů data, měny a čísel. Dbejte na platformově specifické UI komponenty: na iOS se Picker a Date Picker zobrazují jinak než na Androidu, což může vést k různým délkám textu. Otestujte také, zda nejsou oříznuta tlačítka a popisky – zejména u dlouhých německých slov („Benachrichtigungseinstellungen“).

Dalším kritickým bodem je testování jazyků psaných zprava doleva (arabština, hebrejština). iOS i Android nabízejí úpravy rozvržení, které musí být v aplikaci správně implementovány. Zde se doporučuje automatický snapshot test, který porovnává snímky obrazovky v různých jazycích. Pro regresi můžete použít nástroje jako Firebase Test Lab nebo Xcode Cloud k paralelnímu testování lokalizovaných sestavení na mnoha zařízeních.

Konkrétní doporučení: vytvořte kontrolní seznam pro manuální testy s alespoň 20 body na jazyk, který pokrývá kulturní zvláštnosti (např. barvy, symboly). Provádějte automatizované testy „String Completion“ a UI snapshot testy pro každý jazyk. Naplánujte podle rozsahu půl až dva dny testování na jazyk a platformu. Dokumentujte nalezené chyby v ticketovacím systému s uvedením jazykové varianty a typu zařízení.

Poznámka: Právní přezkum lokalizovaného obsahu, zejména u popisů produktů nebo lékařských textů, není testy pokryt. V této věci se poraďte s odborným právníkem.

Nástroje a automatizace pro cross-platform lokalizaci

Efektivní lokalizace pro iOS a Android vyžaduje použití specializovaných nástrojů, které podporují obě platformy a umožňují začlenění do stávajících vývojových procesů. Systémy pro správu překladů (TMS) tvoří páteř: spravují překlady, nabízejí překladové paměti a terminologické databáze a umožňují spolupráci s překladateli. Při výběru dbejte na to, aby TMS zpracovával nativní formáty řetězců obou platforem – XML pro Android, .strings nebo .xcstrings pro iOS – a nabízel obousměrnou synchronizaci s vaším repozitářem kódu.

Automatizace snižuje manuální kroky a zdroje chyb. Nastavte automatické extrakce nových řetězců ze zdrojového kódu: po každém commitu do vývojové větve odešle API nově přidané textové části do TMS. Překlady se po dokončení automaticky zapisují zpět do repozitáře, takže vývojáři mají vždy aktuální stav. Připojení běžných systémů pro správu verzí, jako je Git, je standardem. Plánujte také využití překladové paměti pro opakované použití již přeložených segmentů – to šetří čas a zajišťuje konzistenci.

Pro zajištění kvality používejte automatizované testy, které kontrolují, zda jsou všechny řetězce přeloženy a zda nebyly poškozeny zástupné symboly. Mnoho TMS podporuje režimy „fake translation“, kdy jsou řetězce uměle prodlouženy, aby bylo možné včas odhalit problémy s rozvržením. Dále využívejte integraci strojového překladu jako předpřeklad; výsledky by však měli vždy zkontrolovat rodilí lingvisté. V praxi se osvědčil hybridní pracovní postup: nejprve strojový předloha, poté redakce v TMS, následně automatizovaný export.

Konkrétní doporučení: zvolte TMS s otevřeným API a cross-platform podporou. Definujte jednotný standard pro pojmenování klíčů a komentování všech řetězců, aby byl překladatelům poskytnut kontext. Zaveďte pravidelnou fázi „string freeze“ před vydáními, aby mohly být překlady dokončeny. Nejprve otestujte automatizovanou pipeline na malém trhu, než ji nasadíte na všechny. Dbejte na to, aby váš nástrojový řetězec nevytvářel proprietární závislosti – měli byste být kdykoli schopni přejít na jiné řešení.

Právní a kulturní požadavky na cílových trzích

Lokalizace aplikace se neomezuje pouze na překlad; musí také zohledňovat právní a kulturní podmínky každého cílového trhu. Z právního hlediska jsou důležité zejména ochrana osobních údajů, povinnost uvést impressum a předpisy pro označování nákupů v aplikaci. V EU je třeba dodržovat GDPR – vaše aplikace musí obsahovat jasné prohlášení o ochraně osobních údajů a získat souhlas uživatele. V Kalifornii platí CCPA, v Jižní Koreji zákon o ochraně osobních údajů. Rovněž věkové hodnocení a nastavení ochrany mládeže se výrazně liší; informujte se o systémech obchodů s aplikacemi (např. věkové hodnocení App Store, hodnocení obsahu Google Play). V této věci se poraďte se svým právním oddělením nebo specializovaným právníkem – informace v této příručce nenahrazují právní poradenství.

Kulturní požadavky se týkají vizuálních a obsahových aspektů. Barvy mohou mít v různých kulturách protichůdné významy: Červená symbolizuje v Číně štěstí, v západních zemích často nebezpečí. Vyhněte se v obrázcích a symbolech gestům, která by mohla být místně urážlivá (např. „palec nahoru“ v některých blízkovýchodních regionech). Přizpůsobte formáty data a času, měny a jednotky měření regionálním standardům. Také zobrazení čísel – desetinný oddělovač, oddělovač tisíců – musí být správné. Používejte knihovny pro formátování citlivé na národní prostředí, aby se tyto úpravy prováděly automaticky.

Kromě samotného uživatelského rozhraní jsou rozhodujícím kulturním faktorem platební metody: V Číně nabízejte Alipay a WeChat Pay, v Německu inkaso nebo PayPal, v USA kreditní karty. Ujistěte se, že vaše aplikace zohledňuje místní svátky a události – například speciální téma k Novému roku nebo národní pamětní dny. Samotný záznam v obchodě s aplikacemi musí být také lokalizován: název, popis a klíčová slova by měly obsahovat výrazy specifické pro danou zemi a být kulturně vhodné.

Doporučení k akci: Vytvořte pro každý cílový trh kontrolní seznam s právními dokumenty (prohlášení o ochraně osobních údajů, obchodní podmínky, impressum) a kulturními úpravami (barvy, obrázky, platební metody). Pověřte rodilé mluvčí experty kontrolou snímků obrazovky, textů a symbolů. Zaveďte vlastní kulturní komponentu, která podle trhu načítá odpovídající assety. Naplánujte dostatek času na právní kontroly a případné certifikace – tyto procesy mohou trvat několik týdnů. Otestujte lokalizovanou aplikaci s uživateli na místě, abyste včas odhalili neočekávaná kulturní nedorozumění.

Integrace CI/CD s lokalizačními pipeline

Integrace lokalizace do vaší CI/CD pipeline (Continuous Integration / Continuous Delivery) umožňuje automatizovaně a bezproblémově začlenit překlady do vývojového procesu. Cílem je, aby každé sestavení automaticky obsahovalo nejaktuálnější překlady bez manuálních exportů nebo importů. K tomu se pipeline rozšíří o lokalizační fázi: Po zkompilování aplikace jsou všechny nové nebo změněné textové řetězce extrahovány a odeslány do systému pro správu překladů (TMS). Souběžně se spouštějí automatizované testy, které například kontrolují, zda jsou všechny řetězce přeloženy a zda neobsahují chyby formátování.

Jakmile jsou překlady v TMS dokončeny, jsou automaticky zapsány zpět do repozitáře (např. jako pull request). Tento proces může probíhat asynchronně, aby nebyl blokován vývojový tok. Běžným vzorem je použití funkčních větví: Pro novou větev vydání se řetězce v určeném okamžiku „zmrazí“ a předají do TMS. Překlady jsou pak doručeny během období testování a sloučeny před konečným sestavením. V agilních prostředích lze překládat průběžně – zde je však třeba mít na paměti, že pozdní změny řetězců před vydáním nemusí být zcela přeloženy.

Výzvami integrace CI/CD jsou latence překladů a zpracování řetězců, které dosud nebyly lokalizovány. Jako řešení máte několik možností: (1) Použijte zástupné symboly nebo fallbackové řetězce, které zobrazí nepřeložená místa v uživatelském rozhraní anglicky nebo neutrálním textem. (2) Implementujte funkční přepínače, které skryjí funkce, jejichž překlad ještě není hotový. (3) Naplánujte samostatné větve před vydáním, do kterých se slučují pouze překlady. V praxi se osvědčila kombinace automatizovaného exportu a ručního schválení překladů – zejména u kritického obsahu, jako jsou právní texty nebo platební toky.

Doporučení k akci: Nastavte v platformě CI/CD (např. Jenkins, GitLab CI, GitHub Actions) úlohu, která při každém novém commitu odešle řetězce do TMS. Využijte webhooky TMS k automatickému vytvoření pull requestu při dokončení překladů. Definujte jasná časová okna pro překlady před vydáními a komunikujte je s vaším lokalizačním týmem. Otestujte pipeline pomocí automatizované „kontroly lokality“: Skript zkontroluje, zda všechny klíče v cílových jazycích existují a zda jsou zástupné symboly správně nastaveny. Zdokumentujte celý pracovní postup, aby vývojáři a překladatelé mohli kdykoli nahlédnout do stavu. Při všem počítejte s výjimkami – ne každý trh vyžaduje stejnou hloubku překladu a některý obsah (např. snímky obrazovky) nelze plně automatizovat.

Časté chyby a řešení v praxi

Častým omylem při lokalizaci napříč platformami je předpoklad, že jednou přeložené texty lze identicky použít pro obě platformy. V praxi se projevují rozdíly v omezení délky znaků: popisky tlačítek v iOS často pojmou méně znaků než textová pole v Androidu. Důsledkem jsou oříznutá slova nebo narušený layout. Osvědčeným řešením je vytvoření platformově specifických překladových zdrojů s oddělenými řetězci optimalizovanými pro dané UI. Používejte nástroje, které vizualizují limity znaků na platformu, a testujte včas na skutečných zařízeních.

Další problémovou oblastí je nejednotná lokalizace metadat. Často se názvy aplikací a klíčová slova překládají pro oba obchody téměř identicky, aniž by se zohlednily odlišné algoritmy Applu a Googlu. Zkušenosti ukazují, že Google Play Store citlivěji reaguje na hustotu klíčových slov v názvu, zatímco App Store klade větší důraz na popisná klíčová slova. Řešení: vytvořte pro každý trh a platformu samostatné metadata řetězce, které zohledňují místní vyhledávací zvyklosti, a využijte A/B testování pro kritické kombinace.

Často se přehlížejí také kulturní nuance. Barevný kód, který v Německu signalizuje profesionalitu, může být v jiné zemi vnímán negativně. Namísto paušální výměny barev byste měli pro každý cílový trh provést stručnou kulturní analýzu. Totéž platí pro symboly: palec nahoru nebo zaškrtnutí nemají všude stejný význam. Pragmatickým přístupem je vytvoření dodatku ke stylovému průvodci, který stanoví platformově specifické a kulturní úpravy pro ikony, snímky obrazovky a prvky UI.

Posledním častým nedostatkem je zanedbání kontroly pravopisu a gramatiky v kontextu. Strojové překlady často poskytují formálně správné, ale nepřirozené formulace. V praxi se osvědčuje dvoustupňové zajištění kvality: nejprve automatizovaná kontrola chyb formátování a nekonzistentní terminologie, poté recenze rodilým mluvčím – odborníkem na lokalizaci. Naplánujte si na to dostatek času v sprintu – ideálně jako pevný krok před vydáním.

Kontrolní seznam a výhled: trendy v lokalizaci aplikací

Pragmatický kontrolní seznam pro lokalizaci napříč platformami pomáhá nezapomenout na žádný zásadní krok. Před zahájením prověřte internacionalizaci: Jsou všechny UI řetězce externalizovány? Podporují platformy jazyky psané zprava doleva? Dbejte na dostatek místa pro rozšíření textu – zkušenosti ukazují, že němčina může potřebovat až o 40 % více znaků než angličtina. Dále nastavte platformově specifické lokalizační testy: testujte na skutečných zařízeních s příslušnými systémovými jazyky, nejen v simulátoru.

Pro lokalizaci metadat byste měli pro každý trh a platformu samostatně rešeršovat klíčová slova. Používejte místní vyhledávací výrazy, které lze porovnat v App Store Connect a Google Play Console. Aktualizujte snímky obrazovky a náhledy aplikací s lokalizovanými texty, ale dbejte na kulturně vhodné vizuální motivy. Pravidelný audit všech místních záznamů – alespoň každé tři měsíce – pomáhá udržovat aktuálnost a relevanci.

V oblasti pracovních postupů se standardem stává integrace překladů podporovaných umělou inteligencí s lidskou kontrolou. Trendy jako kontinuální lokalizace (překlad souběžně s vývojem) a automatické generování snímků obrazovky s lokalizovanými texty nabývají na významu. V praxi se kombinace překladových pamětí (TM) a neuronového strojového překladu ukazuje jako efektivní, vyžaduje však pečlivou péči o terminologii. Investujte do centrálního glosáře, který používají všichni zúčastnění – vývojáři, překladatelé i product ownery.

Další výhled: rostoucí využívání komponent aplikací, jako jsou SwiftUI a Jetpack Compose, vyžaduje přizpůsobené lokalizační strategie. Jelikož tato prostředí umožňují dynamické UI prvky, měli byste již ve fázi návrhu plánovat flexibilní délky textů. Rovněž rostoucí význam nákupů v aplikaci a předplatných vyžaduje přesnou lokalizaci cen, měn a právních textů. Nechte si zde poradit od právního experta, abyste splnili místní předpisy týkající se označení poskytovatele a ochrany soukromí.

Závěrem: úspěšná lokalizace aplikací není jednorázový projekt, ale kontinuální proces. Pravidelně kontrolujte výkonnost svých lokalizovaných aplikací v daném obchodě, sbírejte zpětnou vazbu uživatelů a přizpůsobujte svou strategii. S pevným kontrolním seznamem a přehledem aktuálních trendů jste dobře připraveni profesionálně působit na 24 trzích.

Rozpočet, náklady a spolupráce s poskytovateli služeb

Náklady na cross-platformovou lokalizaci aplikace lze jen těžko paušálně vyčíslit, protože závisí na rozsahu, počtu jazyků a požadavcích na kvalitu. Obecně platí: náklady na překlad za slovo jsou nejmenší položkou. Výrazně vyšší jsou náklady na internacionalizaci (i18n), úpravy UI a testování. U středně velké aplikace s 10 000 slovy a 10 jazyky byste měli počítat s rozpočtem 20 000–50 000 EUR, včetně technických úprav a zajištění kvality. Volba poskytovatele služeb výrazně ovlivňuje náklady i kvalitu.

Při spolupráci s překladatelskými agenturami nebo freelancery je klíčové jasné zadání. Definujte terminologické glosáře, styly a referenční materiály. Dbejte na to, aby poskytovatel rozuměl kontextu iOS i Android – zejména u řetězcových zdrojů a formátovacích zástupných znaků (např. %@ pro iOS, %s pro Android). Vyžádejte si zkušební překlady pro ověření kvality. Mnoho poskytovatelů nabízí překladové paměti (TM), které zajišťují konzistenci a dlouhodobě šetří náklady.

Častou chybou je předpoklad, že jednorázový překlad stačí. Aplikace jsou pravidelně aktualizovány, proto je nutný kontinuální lokalizační proces. Počítejte s opakovanými náklady na aktualizace – často 10–20 % z částky za prvotní překlad na jednu verzi. Rovněž náklady na testování lokalizovaných aplikací jsou často podceňovány: na každý jazyk a platformu si vyhraďte alespoň dvě hodiny manuálního testování, u kritických částí aplikace výrazně více. Automatizované testy snímků obrazovky mohou pomoci náklady snížit.

Při výběru poskytovatele služeb pro lokalizaci aplikací dbejte na zkušenosti s agilními pracovními postupy a integrací CI/CD. Ptejte se na referenční projekty a zkušební zprávy. Kvalitní poskytovatel nabízí nejen překlad, ale také kulturní poradenství a technickou podporu. Z právního hlediska je třeba zajistit, aby byla práva k užití překladů smluvně ošetřena a byly dodrženy předpisy o ochraně osobních údajů. To nenahrazuje právní poradenství, ale mělo by být součástí smlouvy.

Měření úspěšnosti lokalizace: KPI a analýzy

Pro hodnocení návratnosti investic do lokalizace byste měli použít měřitelné ukazatele, které přesahují pouhou kvalitu překladu. Kromě míry stažení v cílových trzích (App Store Connect a Play Console) jsou klíčové zejména náklady na získání uživatele (CPI) a míra konverze na příslušné stránce obchodu pro lokalizovaná metadata. Platformově specifickým KPI je podíl nákupů v aplikaci uskutečněných přes lokalizované platební obrazovky – zde se přímo projevují dopady kulturně přizpůsobených textů.

Důležitá je také míra retence (míra návratu) po 7 a 30 dnech: uživatelé, kteří aplikaci používají ve svém rodném jazyce, podle zkušeností zůstávají aktivní déle. Využijte analytické nástroje obou obchodů (iOS: App Analytics; Android: Play Console Insight) k porovnání výkonu podle zemí a jazyků. Dalším důležitým ukazatelem je počet podpůrných ticketů souvisejících s jazykovými problémy. Pokles těchto ticketů po kole lokalizace naznačuje zlepšení uživatelské zkušenosti.

Při porovnávání jednotlivých trhů byste však měli být opatrní, protože externí faktory jako konkurence nebo marketingové kampaně mohou čísla zkreslit. Lepší je provést A/B test: jedné části uživatelů na daném trhu zobrazte lokalizovanou verzi, druhé části nelokalizovanou, a měřte rozdíly ve stažení, nákupech a hodnoceních. Takové testy lze provést pomocí Firebase A/B Testingu nebo nativních A/B funkcí obchodů.

Doplňkově se doporučuje pravidelně sledovat hodnocení a recenze aplikace v cílových jazycích. Negativní kritiky poukazující na chyby v překladu nebo kulturní nedorozumění jsou jasným signálem k úpravě lokalizace. Zdokumentujte všechny KPI v dashboardu, abyste mohli sledovat pokrok v průběhu několika vydání. Tím předejdete tomu, aby některé trhy kvůli špatné lokalizaci nepozorovaně zaostávaly. V praxi se ukazuje, že kontinuální monitorování uživatelských dat je jedním z nejefektivnějších způsobů, jak zlepšit kvalitu a dopad lokalizace.