Viena programėlė, 24 rinkos: kelių platformų lokalizacija, skirta iOS ir Android

App lokalizavimo pagrindai iOS ir Android sistemoms

Programėlės lokalizavimas abiem platformoms prasideda nuo jų ekosistemų supratimo. iOS ir Android skiriasi ne tik programavimo kalbomis (Swift vs. Kotlin/Java), bet ir lokalizavimo, programėlių parduotuvės optimizavimo bei vartotojo sąsajos pritaikymo įrankiais. „iOS“ kūrėjai naudoja „Xcode“ su .strings failais arba .xcstrings, o „Android“ remiasi XML ištekliais res/values aplankuose. Abi sistemos palaiko daugiskaitos taisykles ir simbolių eilutes su vietos rezervavimo ženklais, tačiau diegimas skiriasi: „Android“ naudoja ICU-MessageFormat, o „iOS“ – NSString vietos rezervavimo ženklus, tokius kaip %@ ir %d. Praktinis pavyzdys: vertimas „1 rezultatas“ vs „%d rezultatai“ turi būti atliekamas naudojant „Android“ kiekio eilutes (one/other), o „iOS“ – specialius .stringsdict failus. Jei šie skirtumai ignoruojami, 24 kalbose atsiranda gramatinių klaidų.

Programėlių parduotuvės optimizavimas (ASO) reikalauja platformai būdingų metaduomenų. „Google Play“ parduotuvei reikia lokalizuoti pavadinimą (30 simbolių), trumpą aprašymą (80 simbolių) ir ilgą aprašymą (4000 simbolių). „Apple App Store“ limitai yra 30, 80 ir 4000 simbolių – panašūs, tačiau raktinių žodžių laukas (100 simbolių) egzistuoja tik „iOS“. Praktika rodo, kad raktiniai žodžiai „App Store“ dažnai turi didesnę reikšmę nei pavadinimas. Kitas skirtumas: „Android“ leidžia versti programėlės viduje esančius produktus tiesiogiai „Play Console“, o „iOS“ reikalauja atskirų lokalizuotų aprašymų „App Store Connect“. Kalbant apie teksto ilgį, kūrėjai turėtų tikėtis 30–50 % išplėtimo azijinėms kalboms.

Darbo eigos įrankiai, tokie kaip „Lokalise“ ar „Crowdin“, siūlo kelių platformų integraciją, tačiau pristatymas vyksta atskirai. Patikrintas metodas yra centrinio vertimo atminties (Translation Memory) naudojimas ir automatinis platformai skirtų failų generavimas. Svarbu: vertėjai turi žinoti kontekstą – mygtuko tekstas „Siųsti“ gali reikšti „Submit“ arba „Send“, priklausomai nuo konteksto. Ekrano nuotraukos ir vartotojo sąsajos išdėstymai turėtų būti pridėti. Teisiškai reikia atkreipti dėmesį, kad programėlių aprašymų vertimuose neturi būti klaidinančių teiginių; rekomenduojama atskira teisinė konsultacija kiekvienai tikslinei rinkai.

Internacionalizavimas: pasiruošimas abiem platformoms

Internacionalizavimas (i18n) yra kiekvieno sėkmingo lokalizavimo pagrindas. Jis prasideda nuo kodo ir teksto atskyrimo: visos rodomos eilutės turėtų būti išskirtos į išteklių failus, o ne užkoduotos kode. „iOS“ tai reiškia NSLocalizedString naudojimą, o „Android“ – nuorodą į @string išteklius. Dažna klaida yra eilučių sujungimas (pvz., „Jūs turite „ + count + „ pranešimus“). Tai neveikia daugelyje kalbų, nes žodžių tvarka skiriasi. Vietoj to reikėtų naudoti vietos rezervavimo ženklus su pozicijos parametrais: „iOS“ %1$@ ir %2$d, „Android“ – %1$s ir %2$d. Praktika rodo, kad net patyrę kūrėjai dažnai pamiršta internacionalizuoti tokias duomenis kaip datos ir skaičių formatai. NSDateFormatter („iOS“) ir SimpleDateFormat („Android“) visada turėtų būti nustatyti pagal vartotojo lokalę.

Paveikslėliai ir piktogramos su tekstu yra probleminiai: jie turi būti pakeisti be teksto ikonomis arba perpiešti kiekvienai kalbai. „iOS“ Assets.xcassets gali turėti lokalizuotus paveikslėlius, o „Android“ – res/ su kalbos kvalifikatoriais (pvz., res/drawable-de/). Taip pat maketai turi būti lankstūs: vokiški tekstai, remiantis patirtimi, yra 30 % ilgesni nei angliški, o japoniški dažnai trumpesni. Naudokite Auto Layout („iOS“) arba ConstraintLayout („Android“), kad būtų galima dinamiškai keisti aukščius ir pločius. Neigiamas pavyzdys: mygtukas su fiksuotu 100 px pločiu, rodantis „Einstellungen“, graikiškame vertime „Ρυθμίσεις“ nebus visiškai atvaizduotas.

Kitas aspektas yra rūšiavimas ir paieška. Rūšiuojant sąrašus reikia atsižvelgti į kalbos taisykles (pvz., umlautai vokiečių kalboje, kinų rūšiavimas pagal pinyin). Paieškai tekstai turėtų būti normalizuoti (pvz., nekreipti dėmesio į didžiąsias/mažąsias raides, suvienodinti diakritinius ženklus). Pasiruošimas taip pat apima lokalizavimo proceso nustatymą: kokie failai perduodami vertėjams? Kaip vykdomas kokybės užtikrinimas? Rekomenduojama nustatyti CI/CD dujotiekį, kuris kiekviename kūrimo etape tikrina lokalizavimo failų išsamumą. Atkreipkite dėmesį: internacionalizavimas turi būti baigtas prieš pirmąjį lokalizavimą – vėlesni pakeitimai reikalauja pakartotinių vertimų. Patartina atskira teisinė konsultacija dėl duomenų apsaugos reikalavimų įvairiose šalyse (pvz., BDAR ES).

Platformai būdingi UI skirtumai ir pritaikymai

iOS ir Android laikosi skirtingų dizaino gairių, kurios taip pat veikia lokalizaciją. iOS naudoja „Human Interface Guidelines“, daugiausia dėmesio skirdama aiškiai tipografijai ir nuosekliai navigacijai („Tab Bars“, „Navigation Bars“). Android su „Material Design“ remiasi šešėliais, aukščiais ir „Floating Action“ mygtukais. Šie skirtumai paveikia UI elementus: pavyzdžiui, iOS sąrašai pagal numatytuosius nustatymus turi baltą foną, o Android dažnai šviesiai pilką. Lokalizuotam turiniui tai reiškia, kad tekstas turi būti didelio kontrasto ir su pakankamu eilučių tarpu. Praktikoje matyti, kad vokiškas tekstas dėl ilgų žodžių (pvz., „Druckertreiberinstallation“) mažuose ekranuose greitai lūžta – iOS dažnai reikia automatinio eilučių pritaikymo su .lineBreakMode = .byWordWrapping, o Android – su android:maxLines ir ellipsize.

Šriftai skiriasi: iOS pagal numatytuosius nustatymus naudoja „San Francisco“, o Android – „Roboto“. Abu palaiko lotynų, kirilicą, kinų ir kt., tačiau ne lotynų šriftams, pvz., arabų (iš dešinės į kairę), reikalingi specialūs pritaikymai. iOS siūlo NSWritingDirection, o Android – android:gravity ir layoutDirection. Konkretus pavyzdys: simbolių ir teksto išdėstymas skirtukuose turi būti atspindėtas RTL kalboms. iOS pakanka suaktyvinti „Right-to-Left“ Info.plist faile, tačiau visi patys apibrėžti maketai turi atitikti autolayout. Android palaiko RTL nuo API 17, tačiau reikalauja papildomų atributų maketo failuose. Jei šio atspindžio trūksta, programa atrodo neprofesionaliai.

Kitas dalykas – daugiskaitos formų tvarkymas. Nors Android turi kiekių eilutes (zero, one, two, few, many, other), iOS naudoja .stringsdict su CLDR daugiskaitos taisyklėmis. Kūrėjai turi užtikrinti, kad kiekvienai kalbai būtų pateiktos tinkamos daugiskaitos kategorijos. Pavyzdžiui, lenkų kalba turi keturias formas: 1, 2-4, 5-21 ir daugiau. Testuojant reikėtų peržiūrėti visas kalbas. Taip pat skaičių formatai (pvz., 1.000 vs. 1,000) ir valiutos (€ Vokietijoje vs. € Prancūzijoje) turi būti suformatuoti pagal platformą. Patarimas: naudokite NSNumberFormatter (iOS) ir NumberFormat (Android) su atitinkama lokalė. Galiausiai: išbandykite programą tikruose įrenginiuose su skirtingomis kalbomis ir įsitikinkite, kad joks tekstas nėra nukirptas. Rekomenduojama pasinaudoti teisine konsultacija dėl prieinamumo reikalavimų (pvz., WCAG) abiem platformoms.

App Store optimizavimas (ASO) iOS ir Android

Programėlių parduotuvės optimizavimas (ASO) skiriasi tarp iOS ir Android pirmiausia algoritmais, reitingavimo veiksniais ir prieinamais laukeliais. „Apple App Store“ pagrindinį vaidmenį atlieka programėlės pavadinimas ir raktiniai žodžiai raktinių žodžių laukelyje, o paantraštė ir kategorija taip pat turi įtakos. „Google Play“ didžiausią svorį turi programėlės pavadinimas ir trumpasis aprašymas („Short Description“), po to seka pilnas aprašymas („Full Description“). Be to, „Google Play“ atsižvelgia į vartotojų įvertinimus, atnaujinimų dažnumą ir diegimų skaičių – tačiau tiksliai neatskleidžia veiksnių. Praktikoje abiem parduotuvėms turėtumėte pasirinkti vieningą prekės ženklo įvaizdį, tačiau išnaudokite jų ypatybes. „iOS“ verta išnaudoti 30 simbolių ribą raktinių žodžių laukelyje ir ieškoti atitinkamų paieškos terminų vietine kalba. „Android“ atveju trumpąjį aprašymą (ne daugiau 80 simbolių) laikykite glaustą, o ilgajame aprašyme natūraliai įterpkite raktinius žodžius.

Kitas skirtumas yra ekrano nuotraukų gairės: „Apple“ leidžia iki dešimties ekrano nuotraukų vienam dydžiui, „Google“ – iki aštuonių. Abi platformos naudoja ekrano nuotraukas kaip reitingavimo veiksnį, nes jos turi įtakos konversijų rodikliui. Todėl ASO abiem parduotuvėms reikalauja nuolatinio vaizdinių elementų optimizavimo. Praktikoje kiekvienai rinkai turėtumėte atlikti A/B testus – „Apple“ siūlo produkto puslapio optimizavimą, o „Google Play“ atlieka eksperimentus. Išbandykite skirtingus paveikslėlių tekstus, išdėstymus ir spalvas, kurie atitinka kultūrą. Venkite bendrinių sprendimų: ekrano nuotrauka, kuri gerai veikia Vokietijoje, Japonijoje gali būti mažiau efektyvi dėl kitokių skaitymo įpročių ar spalvų simbolikos.

Konkrečios rekomendacijos: kiekvienai tikslinei kalbai sudarykite raktinių žodžių sąrašą, apimantį tiek bendrinius, tiek nišinius terminus. Naudokite vietinius įrankius, tokius kaip „Apple Search Ads“ raktinių žodžių generatorius arba „Google“ raktinių žodžių planuoklę, skirtą „Play“. Reguliariai (bent kas tris mėnesius) atnaujinkite metaduomenis. Stebėkite reitingus ir konkurenciją atitinkamose parduotuvėse, tačiau neminėkite tiesioginių konkurentų. Atminkite, kad ASO nėra vienkartinis procesas, o nuolatinis optimizavimas. Dėl teisinių klausimų, susijusių su prekių ženklais ar klaidinančiais raktažodžiais, kreipkitės į teisės konsultantą.

Metaduomenų lokalizavimas: pavadinimai, aprašymai, raktažodžiai

Metaduomenų, tokių kaip pavadinimai, paantraštės, aprašymai ir raktažodžiai, lokalizavimas yra labai svarbus siekiant matomumo užsienio rinkose. Vien tik vertimo paprastai nepakanka, nes skiriasi paieškos įpročiai ir kalbinės struktūros. Programėlės pavadinimas kiekviena kalba turėtų perteikti pagrindinę funkciją ar naudą, bet taip pat apimti prekės ženklą. Daugelyje Azijos rinkų įprastas ilgesnis pavadinimas su aprašomaisiais elementais, o Vakarų šalyse pirmenybė teikiama trumpumui. „iOS“ atveju atkreipkite dėmesį į 30 simbolių ribą pavadinimui ir 30 simbolių paantraštei; „Android“ – 30 simbolių pavadinimui ir 80 simbolių trumpajam aprašymui. Ilgasis aprašymas „Google Play“ gali būti iki 4000 simbolių – išnaudokite šią erdvę išsamiai informacijai, tačiau natūralia kalba.

Raktažodžių tyrimui skirtingoms kalboms nereikėtų tik tiesiogiai versti, bet įtraukti sinonimus ir kultūrai būdingus terminus. Praktikoje pasiteisino kiekvienai tikslinei kalbai sudaryti 10–20 svarbiausių raktažodžių sąrašą ir patikrinti jį tokiais įrankiais kaip „Sensor Tower“ ar „App Annie“. „iOS“ atveju raktažodžių lauką galite užpildyti atskirai iki 100 simbolių; ten patenka tik tie terminai, kurių jau nėra pavadinime ar paantraštėje. „Google Play“ raktažodžių laukas nėra aiškiai išskirtas – raktažodžiai indeksuojami trumpajame ir ilgajame aprašymuose. Užtikrinkite, kad aprašymai nebūtų perkrauti raktažodžiais, nes tai gali lemti nuobaudas – „Google Play“ tikisi natūralios teksto struktūros.

Rekomendacija: kiekvienai rinkai atlikite atskirą raktažodžių tyrimą, geriausia su gimtakalbiais. Pritaikykite pavadinimą ir aprašymą prie vietinių ypatumų – pvz., Prancūzijoje dažnai tikimasi formalaus kreipinio, o JAV įprastas laisvesnis tonas. Taip pat reikia atsižvelgti į teisinius aspektus: kai kuriose šalyse tam tikri terminai, pvz., „nemokamai“ ar „geriausias“, gali būti vartojami tik su apribojimais. Dėl to pasitarkite su teisininkais. Išbandykite metaduomenis po atnaujinimo: stebėkite parodymų ir konversijų rodiklius mažiausiai dvi savaites prieš galutinai patvirtindami pakeitimus. Nepamirškite, kad ASO metaduomenys nėra statiški – jie turėtų būti atnaujinami pagal sezonines tendencijas ar naujas funkcijas.

Ekrano kopijos ir programėlių peržiūros skirtingose rinkose

Ekrano kopijos ir programėlių peržiūros (vaizdo įrašai) dažnai yra pirmasis vizualinis jūsų programėlės įspūdis parduotuvėje ir labai lemia paspaudimų bei atsisiuntimų rodiklius. Vien tik teksto vertimo paveikslėliuose nepakanka: kultūriniai spalvų suvokimo, skaitymo krypties ar žmonių bei simbolių vaizdavimo skirtumai gali pakeisti poveikį. Vakarų rinkose dažnai pirmenybė teikiama aiškiam, minimalistiniam dizainui, o Azijos šalyse, pvz., Japonijoje ar Pietų Korėjoje, įprasta didesnė informacijos tanka vienoje ekrano kopijoje. Elementų išdėstymą taip pat reikia pritaikyti prie skaitymo krypties: rinkoms, kuriose rašoma iš dešinės į kairę (pvz., arabų), reikėtų veidrodinių ekrano kopijų, kad žvilgsnio tėkmė atrodytų natūraliai.

Kuriant lokalizuotas ekrano kopijas rekomenduojamas modulinis maketas: fonas, tekstas ir vaizdiniai elementai atskiriami, kad kiekvienai rinkai reikėtų pakeisti tik teksto sluoksnį. Naudokite vietinius šriftus, kurie teisingai atvaizduoja atitinkamus simbolius. Atkreipkite dėmesį į kultūrinius kodus: nykščio rodymas ranka Artimuosiuose Rytuose ar Vakarų Afrikoje turi kitą reikšmę. Ekrano kopijose rodydami žmones, naudokite rinkai būdingą aprangą ar odos spalvą – venkite stereotipų. Spalvų pasirinkimas taip pat gali paveikti konversiją: Kinijoje raudona reiškia sėkmę, o Pietų Afrikoje gali būti siejama su liūdesiu. Praktiškai turėtumėte nustatyti pagrindines rinkas ir joms sukurti atskirus ekrano kopijų rinkinius, kuriuos patvirtintumėte A/B testais.

Programėlių peržiūros (vaizdo įrašai) yra sudėtingesnės, tačiau ypač vertingos konversijai. Lokalizuokite ne tik sakytinį tekstą, bet ir rodomą grafiką ar animacijas. Pasirūpinkite, kad vietinės kalbos versijos būtų sukurtos su tinkamais pranešėjais. Vaizdo įrašo trukmė turėtų būti iki 30 sekundžių ir rodyti pagrindines funkcijas. Šalyse, kuriose lėtas interneto ryšys, sumažinkite failo dydį – naudokite glaudinimą, per daug nepablogindami kokybės. Konkreti veiksmų rekomendacija: kiekvienai tikslinei rinkai sudarykite kultūrinių pritaikymų kontrolinį sąrašą (spalvos, simboliai, žmonės, skaitymo kryptis) ir leiskite vietinei komandai patikrinti išteklius. Po paskelbimo kas mėnesį vertinkite konversijų rodiklius ir prireikus koreguokite ekrano kopijas. Teisiškai apsidrauskite naudodami realių asmenų ar prekės ženklų atvaizdus – prireikus gaukite sutikimus.

Vertimo valdymas ir terminologijos darbas

Nuoseklus vertimo valdymas yra sėkmingo programėlės lokalizavimo „iOS“ ir „Android“ platformose pagrindas. Pirmas žingsnis – įdiegti vertimo valdymo sistemą (TMS), kuri centralizuotai valdo visus kalbos išteklius. Praktikoje pasiteisino tekstų laikymas atskirame nuo kodo sluoksnyje, pavyzdžiui, naudojant lokalizavimo failus, tokius kaip .strings („iOS“) ar .xml („Android“). Juos galima tiesiogiai importuoti į TMS ir iš ten perduoti vertėjams ar automatizuotoms sistemoms.

Itin svarbu prižiūrėti įmonės mastu naudojamą glosarijų ir stiliaus gidą. Glosarijus kiekvienai kalbai nustato privalomus terminų, produktų pavadinimų ir sąsajos elementų vertimus. Taip išvengiama situacijų, kai tas pats angliškas terminas skirtinguose kontekstuose verčiamas skirtingai. Stiliaus gidas apibrėžia toną, formulavimo taisykles (pvz., „Jūs“ ar „tu“ formą) ir atsižvelgia į platformos ypatumus: „Android“ mygtukai dažnai trumpesni, o „iOS“ leidžia ilgesnius tekstus. Stiliaus gide taip pat reikia fiksuoti parduotuvių simbolių limitus (30 simbolių pavadinimui „iOS“ ir 30 – „Google Play“).

Kitas svarbus aspektas – terminologijos darbas. Tai apima reguliarų naudojamų terminų nuoseklumo ir aktualumo tikrinimą. Praktikoje pasiteisino kas ketvirtį atliekama glosarijų peržiūra, dalyvaujant atitinkamiems skyriams. Be to, reikia kurti vertimo atmintis (Translation Memories), kurios atpažįsta pasikartojančias frazes ir taip didina efektyvumą. Pasirūpinkite, kad vertimo atmintys būtų naudojamos skirtingose platformose, nes daugelis tekstų (pvz., nustatymai, klaidų pranešimai) gali būti identiški „iOS“ ir „Android“.

Konkrečios rekomendacijos: naudokite TMS, pvz., „Crowdin“ ar „Phrase“, kurios tiesiogiai integruojasi su jūsų CI/CD grandine. Prižiūrėkite centrinį glosarijų, kuriame būtų bent 200 įrašų kiekvienai kalbai, ir sukurkite stiliaus gidą, atsižvelgiantį į platformos UI apribojimus. Prieš kiekvieną didesnį leidimą peržiūrėkite visus terminus, o pakeitimus dokumentuokite versijų kontrolės būdu.

Pastaba: dėl teisinių klausimų, susijusių su bendrųjų sąlygų ar privatumo pranešimų vertimu, kreipkitės į teisės konsultantą.

Darbo eigos: lokalizavimas judriuose kūrimo procesuose

Lokalizavimo integravimas į judrius kūrimo procesus reikalauja glaudaus kūrimo, vertimo ir kokybės užtikrinimo derinimo. Pasiteisino vadinamieji „lokalizavimo sprintai“, vykstantys lygiagrečiai su kūrimo sprintais. Jų metu jau sprinto planavimo etape identifikuojami verčiami tekstai ir užrašomi kaip naudotojų istorijos. Vertimas atliekamas šiek tiek pavėluotai, idealiu atveju per vieną sprintą, kad lokalizuoti tekstai būtų išbandyti kitame sprinte.

Pagrindinis elementas – automatizavimas. Naudokite Continuous Integration (CI) grandines, kurios prie kiekvieno kodo įsipareigojimo automatiškai ištraukia lokalizavimo failus ir įkelia juos į jūsų TMS. Po vertimo failai grąžinami atgal į saugyklą. „iOS“ tam tinka įrankis „Fastlane“ su veiksmu `lane :refresh_localization`; „Android“ galite naudoti „Gradle“ užduotis. Praktikoje pasiteisino lokalizavimo failų versijavimas atskirame šakoje, siekiant išvengti konfliktų.

Kitas iššūkis – pakeitimų valdymas. Jei sprinto metu keičiasi išeities tekstas, vertimus reikia atnaujinti. Čia padeda „string freeze“: keliom dienom iki sprinto pabaigos tekstai užšaldomi, o pakeitimai leidžiami tik dėl skubių klaidų taisymų. Visi nauji ar pakeisti teksto eilutės automatiškai pažymimi peržiūroje TMS. Bendradarbiavimui su vertėjais rekomenduojamas „Continuous Localization“ metodas, kai nedideli tekstų kiekiai verčiami nuolat, o ne paskutinę akimirką.

Konkrečios rekomendacijos: įgyvendinkite „Git“ pagrįstą darbo eigą su automatiniu lokalizavimo failų eksportu/importu. Apibrėžkite aiškias sąsajas tarp kūrėjų komandų ir vertėjų, pvz., naudodami „Slack“ integracijas. Įveskite dviejų savaičių sprinto ritmą, kuriame lokalizavimas yra neatsiejama „Definition of Done“ dalis. Išbandykite lokalizuotus kūrinius jau sprinto peržiūroje.

Pastaba: taikant judrius metodus, gali prireikti glaudaus derinimo su produktų valdymu, kad kalbiniai pakeitimai nebūtų nuvertinti. Jei lokalizuotą turinį naudojate reguliuojamose srityse (sveikata, finansai), pasitarkite su teisės konsultantu.

Testavimo strategijos lokalizuotoms programoms abiejose platformose

Lokalizuotų programų testavimas reikalauja daugiasluoksnės strategijos, kuri apima tiek automatinius, tiek rankinius patikrinimus. Pradėkite nuo automatizuotų testų teksto lygmeniu: naudokite scenarijus, kurie tikrina, ar visos eilutės yra teisingai lokalizuotos (nėra trūkstamų vertimų) ir ar laikomasi simbolių ilgio apribojimų. „iOS“ atveju galima naudoti UI testą su XCTest, kuris patikrina, ar vokiškoje lokalizacijoje neatsiranda anglų kalbos; „Android“ platformai yra „Espresso“ su panašiomis funkcijomis. Šie testai turėtų būti jūsų CI grandinės dalis ir vykti su kiekvienu kūrimu.

Be to, būtini kultūriniai ir kontekstiniai testai. Leiskite gimtakalbiams išbandyti programą kiekvienoje tikslinėje rinkoje tikrame įrenginyje. Tai darydami tikrinkite ne tik vertimo kokybę, bet ir teisingą datų, valiutų ir skaičių formatų atvaizdavimą. Atkreipkite dėmesį į platformai būdingus UI komponentus: „iOS“ sistemoje „Picker“ ir „Date Picker“ atvaizduojami kitaip nei „Android“, o tai gali sukelti skirtingus teksto ilgius. Taip pat patikrinkite, ar mygtukai ir etiketės nėra nupjaunami – ypač ilguose vokiškuose žodžiuose („Benachrichtigungseinstellungen“).

Kitas kritinis taškas yra dešinės į kairę kalbų (arabų, hebrajų) testavimas. Tiek „iOS“, tiek „Android“ siūlo maketo pritaikymus, kurie programoje turi būti teisingai įgyvendinti. Čia rekomenduojamas automatinis momentinių nuotraukų testas, kuris lygina ekrano kopijas skirtingomis kalbomis. Regresiniam testavimui galite naudoti tokius įrankius kaip „Firebase Test Lab“ arba „Xcode Cloud“, kad lygiagrečiai išbandytumėte lokalizuotus kūrimus daugelyje įrenginių.

Konkreti veiksmų rekomendacija: sukurkite rankinių testų kontrolinį sąrašą su bent 20 punktų kiekvienai kalbai, apimančiu kultūrinius ypatumus (pvz., spalvas, simbolius). Atlikite automatizuotus „String Completion“ testus bei UI momentinių nuotraukų testus kiekvienai kalbai. Pagal apimtį suplanuokite nuo pusės iki dviejų dienų testavimo laiko kiekvienai kalbai ir platformai. Dokumentuokite rastas klaidas bilietų sistemoje, nurodydami kalbos variantą ir įrenginio tipą.

Pastaba: lokalizuoto turinio teisinė peržiūra, ypač produktų aprašymų ar medicininių tekstų atveju, nėra padengta testais. Dėl to konsultuokitės su specialistu teisininku.

Įrankiai ir automatizavimas kelių platformų lokalizacijai

Veiksminga lokalizacija „iOS“ ir „Android“ reikalauja specializuotų įrankių, kurie palaiko abi platformas ir leidžia integruoti į esamus kūrimo procesus. Vertimų valdymo sistemos (TMS) sudaro pagrindą: jos tvarko vertimus, siūlo vertimo atmintį ir terminologijos duomenų bazes bei leidžia bendradarbiauti su vertėjais. Rinkdamiesi atkreipkite dėmesį, kad TMS apdorotų abiejų platformų gimtuosius eilučių formatus – „Android“ XML, „iOS“ .strings ar .xcstrings – ir siūlytų dvikryptį sinchronizavimą su jūsų kodo saugykla.

Automatizavimas sumažina rankinius veiksmus ir klaidų šaltinius. Nustatykite automatinį naujų eilučių ištraukimą iš šaltinio kodo: po kiekvieno įsipareigojimo kūrimo šakoje, API perduoda naujai pridėtus teksto blokus į TMS. Baigus vertimus, jie automatiškai įrašomi atgal į saugyklą, kad kūrėjai visada turėtų naujausią versiją. Populiarių versijų kontrolės sistemų, tokių kaip „Git“, prijungimas yra standartinis. Be to, suplanuokite vertimo atminties naudojimą, kad pakartotinai naudotumėte jau išverstus segmentus – tai taupo laiką ir užtikrina nuoseklumą.

Kokybės užtikrinimui naudokite automatizuotus testus, kurie tikrina, ar visos eilutės yra išverstos ir ar nepažeisti vietos rezervavimo ženklai. Daugelis TMS palaiko „Fake Translation“ režimus, kai eilutės dirbtinai pailginamos, kad būtų anksti pastebėtos maketo problemos. Taip pat naudokite mašininio vertimo integraciją kaip pirminį vertimą; tačiau rezultatai visada turėtų būti patikrinti gimtakalbių kalbininkų. Praktikoje pasiteisino hibridinis darbo eiga: pirmiausia mašininis šablonas, po to redagavimas TMS, galiausiai automatinis eksportas.

Konkreti veiksmų rekomendacija: pasirinkite TMS su atvira API ir kelių platformų palaikymu. Nustatykite vienodą rakto pavadinimo ir komentavimo standartą visoms eilutėms, kad suteiktumėte kontekstą vertėjams. Įveskite reguliarų „String-Freeze“ etapą prieš išleidimus, kad vertimai galėtų būti užbaigti. Išbandykite automatizuotą grandinę pirmiausia mažoje rinkoje, kol išplėsite ją visoms. Atkreipkite dėmesį, kad jūsų įrankių grandinė nesukurtų nuosavybinių priklausomybių – bet kuriuo metu turėtumėte galėti pereiti prie kito spendimo.

Teisiniai ir kultūriniai reikalavimai tikslinėse rinkose

Programėlės lokalizavimas neapsiriboja vertimu; jis taip pat turi atsižvelgti į teisines ir kultūrines kiekvienos tikslinės rinkos sąlygas. Teisiniu požiūriu ypač aktualūs duomenų apsauga, teisinės informacijos prievolė ir žymėjimo reikalavimai programėlėje atliekamiems pirkimams. ES reikia laikytis BDAR – Jūsų programėlėje turi būti aiški privatumo politika ir gautas vartotojo sutikimas. Kalifornijoje galioja CCPA, Pietų Korėjoje – Asmens duomenų apsaugos įstatymas. Taip pat amžiaus apribojimai ir nepilnamečių apsaugos nustatymai labai skiriasi; pasidomėkite programėlių parduotuvių sistemomis (pvz., „App Store“ amžiaus įvertinimas, „Google Play“ turinio įvertinimas). Dėl šių klausimų pasitarkite su savo teisės skyriumi arba specializuotu advokatu – šiame vadove pateikta informacija nepakeičia teisinės konsultacijos.

Kultūriniai reikalavimai apima vizualinius ir turinio aspektus. Spalvos skirtingose kultūrose gali turėti priešingas reikšmes: raudona Kinijoje simbolizuoja sėkmę, o Vakarų šalyse dažnai – pavojų. Venkite vaizduose ir simboliuose gestų, kurie vietoje galėtų pasirodyti įžeidžiantys (pavyzdžiui, „nykštys aukštyn“ kai kuriuose Artimųjų Rytų regionuose). Pritaikykite datų ir laiko formatus, valiutas bei matavimo vienetus prie regioninių standartų. Taip pat skaičių pateikimas – dešimtainiai skyrikliai, tūkstančių skyrikliai – turi būti teisingas. Naudokite lokalę atpažįstančias formatavimo bibliotekas, kad šie pritaikymai būtų atliekami automatiškai.

Be paprastos vartotojo sąsajos, mokėjimo būdai yra lemiamas kultūrinis veiksnys: Kinijoje siūlykite „Alipay“ ir „WeChat Pay“, Vokietijoje – tiesioginį debetą arba „PayPal“, JAV – kredito korteles. Užtikrinkite, kad Jūsų programėlė atsižvelgtų į vietines šventes ir įvykius – pavyzdžiui, specialią temą Naujiesiems metams ar nacionalines atmintinas dienas. Pats programėlės parduotuvės įrašas taip pat turi būti lokalizuotas: pavadinime, aprašyme ir raktažodžiuose naudokite šaliai būdingus terminus, o turinys turi būti kultūriškai tinkamas.

Rekomendacija veiksmams: kiekvienai tikslinei rinkai sukurkite kontrolinį sąrašą su teisiniais dokumentais (privatumo politika, paslaugų teikimo sąlygomis, teisine informacija) ir kultūriniais pritaikymais (spalvomis, paveikslėliais, mokėjimo būdais). Užsakykite gimtakalbius ekspertus, kurie patikrintų ekrano kopijas, tekstus ir simbolius. Įveskite atskirą kultūrinį komponentą, kuris pagal rinką įkelia atitinkamus išteklius. Skirkite pakankamai laiko teisinėms patikroms ir galimiems sertifikavimams – šie procesai gali trukti kelias savaites. Išbandykite lokalizuotą programėlę su vietiniais vartotojais, kad anksti atskleistumėte netikėtus kultūrinius nesusipratimus.

CI/CD integracija su lokalizavimo vamzdynais

Lokalizavimo integravimas į Jūsų CI/CD (Continuous Integration / Continuous Delivery) vamzdyną leidžia automatiškai ir sklandžiai įtraukti vertimus į kūrimo procesą. Tikslas – kad kiekvienas build'as automatiškai turėtų naujausius vertimus, be rankinių eksportų ar importų. Tam vamzdynas išplečiamas lokalizavimo etapu: po programėlės kompiliavimo išgaunami visi nauji ar pakeisti teksto stringai ir išsiunčiami į vertimo valdymo sistemą (TMS). Lygiagrečiai paleidžiami automatizuoti testai, kurie, pavyzdžiui, patikrina, ar visi stringai išversti ir nėra formatavimo klaidų.

Kai vertimai TMS baigiami, jie automatiškai įrašomi atgal į saugyklą (pvz., kaip Pull Request). Šis procesas gali vykti asinchroniškai, kad kūrimo srautas nebūtų blokuojamas. Įprastas modelis yra funkcijų šakų naudojimas: naujai leidimo šakai stringai užšaldomi ir perduodami TMS. Vertimai pristatomi testavimo laikotarpiu ir sujungiami prieš galutinį build'ą. Agiliose aplinkose galima versti nuolat – tačiau čia reikia atkreipti dėmesį, kad paskutiniai stringų pakeitimai prieš leidimą gali būti nevisiškai išversti.

Iššūkiai CI/CD integracijoje yra vertimo vėlavimas ir dar nelokalizuotų stringų tvarkymas. Yra keli sprendimai: (1) naudokite vietos rezervavimo simbolius arba atsarginius stringus, kad neišverstos vietos sąsajoje būtų rodomos angliškai arba neutraliu tekstu; (2) įgyvendinkite funkcijų perjungiklius, kurie paslepia funkcijas, kurių vertimai dar laukiami; (3) suplanuokite atskiras priešleidimo šakas, kuriose jungiami tik vertimai. Praktikoje pasiteisino automatizuoto eksporto ir rankinio vertimų patvirtinimo derinys – ypač kritiniam turiniui, pvz., teisiniams tekstams ar mokėjimo srautams.

Rekomendacija veiksmams: savo CI/CD platformoje (pvz., „Jenkins“, „GitLab CI“, „GitHub Actions“) nustatykite užduotį, kuri su kiekvienu nauju commit'u siunčia stringus į TMS. Naudokite TMS webhook'us, kad baigus vertimus būtų automatiškai sugeneruotas Pull Request. Apibrėžkite aiškius laiko langus vertimams prieš leidimus ir informuokite savo lokalizavimo komandą. Išbandykite vamzdyną automatizuotu „lokalumo patikrinimu“: scenarijus patikrina, ar visi raktai yra tikslinėse kalbose ir ar vietos rezervavimo simboliai nustatyti teisingai. Dokumentuokite visą darbo eigą, kad kūrėjai ir vertėjai bet kada matytų būseną. Atminkite: numatykite išimtis – ne kiekvienai rinkai reikia vienodo vertimo išsamumo, o kai kurie turiniai (pvz., ekrano kopijos) negali būti visiškai automatizuoti.

Dažnos klaidos ir sprendimai praktikoje

Dažna klaida atliekant kelių platformų lokalizavimą – manyti, kad vieną kartą išverstus tekstus galima identiškai naudoti abiejose platformose. Praktikoje išryškėja simbolių ilgio apribojimų skirtumai: „iOS“ mygtukų etiketės dažnai toleruoja mažiau simbolių nei „Android“ teksto laukai. To pasekmė – nukirpti žodžiai arba sugadintas maketas. Patikimas sprendimas – sukurti platformoms pritaikytus vertimo išteklius su atskiromis eilutėmis, optimizuotomis konkrečiai vartotojo sąsajai. Naudokite įrankius, kurie vizualizuoja simbolių limitus pagal platformą, ir iš anksto testuokite tikruose įrenginiuose.

Kita dažna problema – nevienodas metaduomenų lokalizavimas. Dažnai programėlės pavadinimai ir raktiniai žodžiai verčiami beveik identiškai abiem parduotuvėms, neatsižvelgiant į skirtingus „Apple“ ir „Google“ algoritmus. Patirtis rodo, kad „Google Play“ parduotuvė jautriau reaguoja į raktinių žodžių tankį pavadinime, o „App Store“ labiau vertina aprašomuosius raktinius žodžius. Sprendimas: kiekvienai rinkai ir platformai sukurkite atskiras metaduomenų eilutes, atitinkančias vietinius paieškos įpročius, ir naudokite A/B testavimą kritinėms kombinacijoms.

Taip pat dažnai nepaisoma kultūrinių niuansų. Spalvų kodas, kuris Vokietijoje signalizuoja profesionalumą, kitoje šalyje gali būti suvokiamas neigiamai. Užuot bendrai keitus spalvas, kiekvienai tikslinei rinkai atlikite trumpą kultūrinę analizę. Tas pats galioja simboliams: nykštys aukštyn ar varnele ne visur turi tą pačią reikšmę. Pragmatiškas požiūris – sukurti stiliaus gairių papildymą, kuriame būtų užfiksuoti platformai ir kultūrai pritaikyti piktogramų, ekrano nuotraukų ir vartotojo sąsajos elementų pakeitimai.

Paskutinė dažna klaida – kontekstinės rašybos ir gramatikos patikrų nepaisymas. Mašininio vertimo rezultatai dažnai būna formaliai teisingi, bet nenatūralūs. Praktikoje pasiteisina dviejų etapų kokybės užtikrinimas: pirmiausia automatizuotas formatavimo klaidų ir nenuoseklios terminologijos patikrinimas, paskui vertimo eksperto gimtosios kalbos peržiūra. Skirkite tam pakankamai laiko sprinte – geriausia kaip fiksuotą žingsnį prieš išleidimą.

Kontrolinis sąrašas ir ateities tendencijos: programėlių lokalizavimo tendencijos

Pragmatiškas kelių platformų lokalizavimo kontrolinis sąrašas padeda nepraleisti esminių žingsnių. Prieš pradėdami patikrinkite internacionalizavimą: ar visos vartotojo sąsajos eilutės yra išorinės? Ar platformos palaiko rašymą iš dešinės į kairę? Atkreipkite dėmesį į pakankamai vietos teksto išplėtimams – patirtis rodo, kad vokiečių kalbai gali prireikti iki 40% daugiau simbolių nei anglų kalbai. Taip pat sukurkite platformoms pritaikytus lokalizavimo testus: testuokite tikruose įrenginiuose su atitinkamomis sistemos kalbomis, o ne tik simuliatoriuje.

Metaduomenų lokalizavimui turėtumėte kiekvienai rinkai ir platformai atskirai atlikti raktinių žodžių paiešką. Naudokite vietinius paieškos terminus, kuriuos galima suderinti su „App Store Connect“ ir „Google Play Console“. Atnaujinkite ekrano nuotraukas ir programėlės peržiūras su lokalizuotais tekstais, tačiau atkreipkite dėmesį į kultūriškai tinkamus vaizdų motyvus. Reguliarus visų vietinių įrašų auditas – bent kas tris mėnesius – padeda išlaikyti aktualumą ir svarbą.

Darbo srautų srityje DI pagrįstų vertimų integravimas su žmogaus patikra tampa standartu. Tokios tendencijos kaip nenutrūkstamas lokalizavimas (vertimas lygiagrečiai su kūrimu) ir automatinis ekrano nuotraukų generavimas su lokalizuotais tekstais įgyja vis didesnę reikšmę. Praktikoje vertimų atminties (TM) ir neuroninio mašininio vertimo derinys pasirodo esąs efektyvus, tačiau reikalauja kruopščios terminologijos priežiūros. Investuokite į centrinį žodyną, kurį naudoja visi suinteresuotieji – kūrėjai, vertėjai ir produktų savininkai.

Kita ateities tendencija: vis dažniau naudojant programėlių komponentus, tokius kaip „SwiftUI“ ir „Jetpack Compose“, reikia pritaikytų lokalizavimo strategijų. Kadangi šios sistemos leidžia dinaminius vartotojo sąsajos elementus, jau projektavimo etape turėtumėte planuoti lanksčius teksto ilgius. Taip pat didėjanti programėlėje atliekamų pirkimų ir prenumeratos modelių svarba reikalauja tikslaus kainų, valiutų ir teisinių tekstų lokalizavimo. Dėl to pasitarkite su teisės ekspertu, kad atitiktumėte vietinius teikėjo identifikavimo ir duomenų apsaugos reglamentus.

Apibendrinant: sėkmingas programėlės lokalizavimas nėra vienkartinis projektas, o nuolatinis procesas. Reguliariai tikrinkite lokalizuotų programėlių veiklos rezultatus atitinkamoje parduotuvėje, rinkite naudotojų atsiliepimus ir pritaikykite savo strategiją. Turėdami tvirtą kontrolinį sąrašą ir stebėdami naujausias tendencijas, būsite gerai pasirengę profesionaliai veikti 24 rinkose.

Biudžetas, sąnaudos ir bendradarbiavimas su paslaugų teikėjais

Kryžminės platformos programėlės lokalizavimo išlaidas sunku bendrai įvertinti, nes jos priklauso nuo apimties, kalbų skaičiaus ir kokybės reikalavimų. Taisyklė: vertimo išlaidos už žodį yra mažiausias postas. Žymiai didesnės yra išlaidos internacionalizacijai (i18n), vartotojo sąsajos pritaikymui ir testavimui. Vidutinės programėlės su 10 000 žodžių ir 10 kalbų biudžetas turėtų būti 20 000–50 000 EUR, įskaitant techninius pritaikymus ir kokybės užtikrinimą. Paslaugų teikėjo pasirinkimas labai įtakoja išlaidas ir kokybę.

Bendradarbiaujant su vertimo agentūromis ar laisvai samdomais vertėjais, aiški specifikacija yra lemiama. Apibrėžkite terminologijos žodynus, stiliaus gidus ir informacinę medžiagą. Atkreipkite dėmesį, kad paslaugų teikėjas suprastų tiek iOS, tiek Android kontekstą – ypač teksto išteklių ir formatavimo vietos rezervavimo ženklų atveju (pvz., %@ iOS, %s Android). Paprašykite bandomųjų vertimų, kad patikrintumėte kokybę. Daugelis paslaugų teikėjų siūlo vertimo atmintis (TM), kurios užtikrina nuoseklumą ir ilgainiui taupo išlaidas.

Dažna klaida yra manyti, kad užtenka vienkartinio vertimo. Programėlės reguliariai atnaujinamos, todėl reikalingas nuolatinis lokalizavimo procesas. Planuokite pasikartojančias atnaujinimų išlaidas – dažnai 10–20 % pradinio vertimo sumos už kiekvieną leidimą. Taip pat dažnai neįvertinamas lokalizuotų programėlių testavimo darbo krūvis: kiekvienai kalbai ir platformai turėtumėte skirti bent dvi valandas rankinio testavimo, o kritinėse programėlės srityse – žymiai daugiau. Automatiniai ekrano nuotraukų testai gali padėti sumažinti darbo krūvį.

Renkantis programėlių lokalizavimo paslaugų teikėją, atkreipkite dėmesį į patirtį su judriais darbo srautais ir CI/CD integracija. Klauskite apie nuorodų projektus ir testų ataskaitas. Geras paslaugų teikėjas siūlo ne tik vertimą, bet ir kultūrinį konsultavimą bei techninę pagalbą. Teisiškai svarbu, kad sutartyje užtikrintumėte vertimų naudojimo teises ir laikytumėtės duomenų apsaugos reikalavimų. Tai nepakeičia teisinės konsultacijos, bet turėtų būti įtraukta į sutartį.

Lokalizavimo sėkmės matavimas: KPI ir analizė

Norėdami įvertinti lokalizavimo investicijų grąžą, turėtumėte naudoti išmatuojamus rodiklius, kurie viršija vien vertimo kokybę. Be atsisiuntimų rodiklio tikslinėse rinkose („App Store Connect“ ir „Play Console“), ypač svarbios yra vartotojų įsigijimo išlaidos (CPI) ir konversijos rodiklis atitinkamame parduotuvės puslapyje lokalizuotiems metaduomenims. Platformai būdingas KPI yra programėlėje atliekamų pirkimų dalis, kuri užbaigiama per lokalizuotus mokėjimo ekranus – čia tiesiogiai matomas kultūriškai pritaikytų tekstų poveikis.

Taip pat informatyvus yra išlaikymo rodiklis (grįžtamumo rodiklis) po 7 ir 30 dienų: vartotojai, kurie programėlę naudoja savo gimtąja kalba, paprastai išlieka aktyvesni ilgiau. Naudokite abiejų parduotuvių analizės įrankius (iOS: „App Analytics“; Android: „Play Console Insight“), kad palygintumėte veikimą pagal šalį ir kalbą. Kitas svarbus rodiklis yra pagalbos bilietų skaičius, susijęs su kalbos problemomis. Šių bilietų sumažėjimas po lokalizavimo raundo rodo pagerėjusią vartotojo patirtį.

Tačiau turėtumėte saugotis lygindami atskiras rinkas, nes išoriniai veiksniai, tokie kaip konkurencija ar rinkodaros kampanijos, gali iškraipyti skaičius. Geriau tinka A/B testas: vienai rinkos vartotojų daliai parodykite lokalizuotą versiją, kitai – nelokalizuotą, ir išmatuokite skirtumus atsisiuntimuose, pirkimuose ir įvertinimuose. Tokius testus galima atlikti naudojant „Firebase A/B Testing“ arba gimtąsias parduotuvių A/B funkcijas.

Be to, rekomenduojama reguliariai peržiūrėti programėlės įvertinimus ir atsiliepimus tikslinėmis kalbomis. Neigiami atsiliepimai, nurodantys vertimo klaidas ar kultūrinius nesusipratimus, yra aiškus signalas, kad reikia patobulinti lokalizavimą. Dokumentuokite visus KPI rodiklius prietaisų skydelyje, kad galėtumėte stebėti pažangą per kelis leidimus. Taip išvengsite, kad atskiros rinkos dėl prastos lokalizacijos nepastebimai atsiliktų. Praktikoje matoma, kad nuolatinis vartotojų duomenų stebėjimas yra vienas efektyviausių būdų pagerinti lokalizacijos kokybę ir poveikį.