One App, 24 Markets: Cross-Platform Localization for iOS and Android

App lokalizācijas pamati iOS un Android platformām

Lietotņu lokalizācija abām platformām sākas ar izpratni par katras ekosistēmu. iOS un Android atšķiras ne tikai programmēšanas valodā (Swift vs Kotlin/Java), bet arī lokalizācijas rīkos, App Store optimizācijā un UI pielāgojumos. iOS izstrādātāji izmanto Xcode ar .strings vai .xcstrings failiem, savukārt Android izmanto XML resursus mapēs res/values. Abas sistēmas atbalsta daudzskaitļa noteikumus un virknes ar vietturiem, bet ieviešana atšķiras: Android izmanto ICU-MessageFormat, bet iOS – NSString vietturus, piemēram, %@ un %d. Praktisks piemērs: tulkojums “1 rezultāts” pret “%d rezultāti” Android jāveic ar Quantity-Strings (one/other), savukārt iOS – ar speciāliem .stringsdict failiem. Ja šīs atšķirības ignorē, rodas gramatikas kļūdas 24 valodās.

App Store optimizācijai (ASO) nepieciešami platformai specifiski metadati. Google Play veikalā jātulko nosaukums (30 rakstzīmes), īss apraksts (80 rakstzīmes) un garais apraksts (4000 rakstzīmes). Apple App Store ierobežojumi ir līdzīgi – 30, 80 un 4000 rakstzīmes, bet atslēgvārdu lauks (100 rakstzīmes) pastāv tikai iOS. Praksē atslēgvārdiem App Store bieži ir lielāks svars nekā nosaukumam. Vēl viena atšķirība: Android ļauj tulkot lietotnē iegādājamos produktus tieši Play Console, savukārt iOS pieprasa atsevišķus lokalizētus aprakstus App Store Connect. Teksta garumā izstrādātājiem jārēķinās ar 30–50 % palielinājumu Āzijas valodās.

Darba plūsmas rīki, piemēram, Lokalise vai Crowdin, piedāvā starpplatformu integrāciju, bet piegāde notiek atsevišķi. Ieteicamā pieeja ir izmantot centralizētu tulkojumu atmiņu (Translation Memory) un automātiski ģenerēt platformai specifiskus failus. Svarīgi: tulkotājiem jāzina konteksts – pogas etiķete “Sūtīt” atkarībā no konteksta var nozīmēt “Submit” vai “Send”. Jāpievieno ekrānuzņēmumi un UI izkārtojumi. Juridiski jāņem vērā, ka lietotņu aprakstu tulkojumos nedrīkst būt maldinoši apgalvojumi; ieteicams konsultēties ar juristu katrā mērķa tirgū.

Internacionalizācija: sagatavošanās abām platformām

Internacionalizācija (i18n) ir jebkuras veiksmīgas lokalizācijas pamats. Tā sākas ar koda un teksta atdalīšanu: visi attēlojamie teksti jāievieto resursu failos, nevis jāiekļauj kodā. iOS tas nozīmē NSLocalizedString izmantošanu, Android – atsauces uz @string resursiem. Bieža kļūda ir teksta savienošana (piemēram, “Jums ir ” + count + “ ziņas”). Tas daudzās valodās nedarbojas, jo vārdu secība atšķiras. Tā vietā jāizmanto vietturi ar pozīcijas parametriem: iOS %1$@ un %2$d, Android ar %1$s un %2$d. Praksē pat pieredzējuši izstrādātāji bieži aizmirst internacionalizēt datumus un skaitļu formātus. NSDateFormatter (iOS) un SimpleDateFormat (Android) vienmēr jāiestata atbilstoši lietotāja locale.

Attēli un ikonas ar tekstu ir problemātiski: tie vai nu jāaizstāj ar bezteksta ikonām, vai jāpārzīmē katrai valodai. iOS Assets.xcassets var saturēt lokalizētus attēlus, Android res/ ar valodas kvalifikatoriem (piem., res/drawable-de/). Arī izkārtojumiem jābūt elastīgiem: vācu teksti parasti ir par 30 % garāki nekā angļu, japāņu – bieži īsāki. Izmantojiet Auto Layout (iOS) vai ConstraintLayout (Android), lai nodrošinātu dinamisku augstumu un platumu. Negatīvs piemērs: poga ar fiksētu platumu 100 px, kas rāda “Einstellungen”, grieķu tulkojumā “Ρυθμίσεις” netiks attēlota pilnībā.

Vēl viens aspekts ir kārtošana un meklēšana. Kārtojot sarakstus, jāievēro valodas noteikumi (piem., umlauti vācu valodā, ķīniešu kārtošana pēc piņjiņa). Meklēšanai teksti jānormalizē (piem., ignorēt lielos/mazos burtus, vienādot diakritiskās zīmes). Sagatavošana ietver arī lokalizācijas procesa noteikšanu: kādus failus nodot tulkotājiem? Kā notiek kvalitātes nodrošināšana? Ieteicams izveidot CI/CD cauruļvadu, kas katrā būvējumā pārbauda lokalizācijas failu pilnīgumu. Ņemiet vērā: internacionalizācijai jābūt pabeigtai pirms pirmās lokalizācijas – vēlākas izmaiņas prasa atkārtotus tulkojumus. Ieteicama sava juridiskā konsultācija par datu aizsardzības prasībām dažādās valstīs (piem., VDAR ES).

Platformai specifiskās UI atšķirības un pielāgojumi

iOS un Android ievēro atšķirīgas dizaina vadlīnijas, kas ietekmē arī lokalizāciju. iOS izmanto Human Interface Guidelines, koncentrējoties uz skaidru tipogrāfiju un konsekventu navigāciju (cilnes, navigācijas joslas). Android ar Material Design balstās uz ēnām, pacēlumu un peldošajām darbības pogām. Šīs atšķirības ietekmē UI elementus: piemēram, iOS sarakstiem pēc noklusējuma ir balts fons, Android bieži – gaiši pelēks. Lokalizētam saturam tas nozīmē, ka jāizvēlas teksti ar augstu kontrastu un pietiekamu rindu atstarpi. Praksē redzams, ka vācu teksti garu vārdu dēļ (piem., „Druckertreiberinstallation“) mazos ekrānos ātri pārceļas – iOS biežāk nepieciešama automātiska rindu pielāgošana ar .lineBreakMode = .byWordWrapping, Android – ar android:maxLines un ellipsize.

Fonti atšķiras: iOS pēc noklusējuma izmanto San Francisco, Android – Roboto. Abi atbalsta latīņu, kirilicu, ķīniešu u.c., bet ne-latīņu rakstībām, piemēram, arābu valodai (no labās uz kreiso), nepieciešami speciāli pielāgojumi. iOS piedāvā NSWritingDirection, Android android:gravity un layoutDirection. Konkrēts piemērs: simbolu un teksta izkārtojums cilnes joslā RTL valodām jāatspoguļo. iOS pietiek ar „Right-to-Left“ iespējošanu Info.plist, bet visiem pašu definētajiem izkārtojumiem jābūt atbilstošiem autolayout. Android atbalsta RTL no API 17, bet nepieciešami papildu atribūti izkārtojuma failos. Ja šī atspoguļošana trūkst, lietotne izskatās neprofesionāli.

Vēl viens punkts ir daudzskaitļa formu apstrāde. Kamēr Android izmanto Quantity-Strings (zero, one, two, few, many, other), iOS izmanto .stringsdict ar CLDR daudzskaitļa noteikumiem. Izstrādātājiem jānodrošina, ka katrai valodai tiek sniegtas pareizās daudzskaitļa kategorijas. Poļu valodai, piemēram, ir četras formas: 1, 2-4, 5-21 un vairāk. Testējot jāpārskata visas valodas. Arī skaitļu formāti (piem., 1.000 vs 1,000) un valūtas (€ Vācijā vs € Francijā) jāformatē atbilstoši platformai. Padoms: izmantojiet NSNumberFormatter (iOS) un NumberFormat (Android) ar attiecīgo lokalizāciju. Nobeigumā: testējiet lietotni reālās ierīcēs ar dažādām valodām un pārliecinieties, ka neviens teksts netiek nogriezts. Ieteicama atsevišķa juridiskā konsultācija par pieejamības prasībām (piem., WCAG) abām platformām.

App Store optimizācija (ASO) iOS un Android

App Store optimizācija starp iOS un Android atšķiras galvenokārt algoritmos, ranžēšanas faktoros un pieejamajos laukos. Apple App Store liela nozīme ir lietotnes nosaukumam un atslēgvārdiem atslēgvārdu laukā, savukārt apakšvirsraksts un kategorija arī ietekmē. Google Play vislielāko svaru ir lietotnes nosaukumam un īsajam aprakstam (Short Description), kam seko pilnais apraksts (Full Description). Turklāt Google Play ņem vērā lietotāju vērtējumus, atjaunināšanas biežumu un instalāciju skaitu – tomēr bez konkrētas faktoru norādes. Praksē jums jāizvēlas vienots zīmola tēls abiem veikaliem, bet jāizmanto katra specifiskās īpašības. iOS ir vērts izmantot 30 rakstzīmju limitu atslēgvārdiem un pētīt atbilstošus meklēšanas terminus vietējā valodā. Android īso aprakstu (maksimums 80 rakstzīmes) jāveido precīzu, un garajā aprakstā dabiski jāiekļauj atslēgvārdi.

Vēl viena atšķirība ir ekrānuzņēmumu vadlīnijās: Apple atļauj līdz desmit ekrānuzņēmumiem vienā izmērā, Google – līdz astoņiem. Abas platformas izmanto ekrānuzņēmumus kā ranžēšanas faktoru, jo tie ietekmē konversijas rādītāju. ASO abiem veikaliem tāpēc prasa nepārtrauktu vizuālo materiālu optimizāciju. Praksē jums katram tirgum jāveic A/B testi – Apple piedāvā produktu lapas optimizāciju, Google Play veic eksperimentus. Testējiet dažādus attēlu tekstus, izkārtojumus un krāsas, kas kulturāli atbilst. Izvairieties no vispārīgiem risinājumiem: ekrānuzņēmums, kas Vācijā darbojas labi, Japānā citu lasīšanas paradumu vai krāsu simbolikas dēļ var būt vājāks.

Konkrēti rīcības ieteikumi: katrai mērķa valodai izveidojiet atslēgvārdu sarakstu, kas ietver gan vispārīgus, gan nišas terminus. Izmantojiet vietējos rīkus, piemēram, Apple Search Ads atslēgvārdu ģeneratoru vai Google atslēgvārdu plānotāju Play. Regulāri atjauniniet metadatus, vismaz reizi trijos mēnešos. Novērojiet ranžējumus un konkurenci attiecīgajos veikalos, tomēr nepieminot tiešos konkurentus. Ņemiet vērā, ka ASO nav vienreizējs process, bet gan nepārtraukta optimizācija. Juridiskos jautājumos par preču zīmēm vai maldinošiem atslēgvārdiem konsultējieties ar juristu.

Metadatu lokalizācija: Virsraksti, apraksti, atslēgvārdi

Metadatu, piemēram, virsrakstu, apakšvirsrakstu, aprakstu un atslēgvārdu lokalizācija ir būtiska, lai nodrošinātu atrodamību ārvalstu tirgos. Vienkāršs tulkojums parasti nav pietiekams, jo atšķiras meklēšanas paradumi un valodas struktūras. Lietotnes virsrakstam katrā valodā jānorāda pamatfunkcija vai ieguvums, bet tajā jāiekļauj arī zīmols. Daudzos Āzijas tirgos ir ierasts garāks virsraksts ar aprakstošiem elementiem, savukārt Rietumvalstīs priekšroka tiek dota īsumam. iOS gadījumā ievērojiet 30 rakstzīmju ierobežojumu virsrakstam un 30 rakstzīmes apakšvirsrakstam; Android ierīcēm ierobežojums ir 30 rakstzīmes virsrakstam un 80 rakstzīmes īsajam aprakstam. Google Play garā apraksta garums var būt līdz 4000 rakstzīmēm – izmantojiet šo vietu detalizētai informācijai, taču dabiskā valodā.

Atslēgvārdu izpētē dažādām valodām nevajadzētu tikai tieši tulkot, bet iekļaut sinonīmus un kultūrspecifiskus terminus. Praksē ir pierādījies, ka katram mērķvalodā ir jāizveido 10–20 atbilstošāko atslēgvārdu saraksts un jāvalidē, izmantojot tādus rīkus kā Sensor Tower vai App Annie. iOS gadījumā atslēgvārdu lauku var aizpildīt atsevišķi ar līdz 100 rakstzīmēm; tajā ievieto tikai terminus, kas jau nav iekļauti virsrakstā vai apakšvirsrakstā. Google Play atslēgvārdu lauks nav skaidri norādīts, bet atslēgvārdi tiek indeksēti īsajā un garajā aprakstā. Pārliecinieties, ka apraksti nav pārslogoti ar atslēgvārdiem, jo tas var novest pie sodiem – Google Play gaida dabisku teksta struktūru.

Ieteikums: Katram tirgum veiciet atsevišķu atslēgvārdu izpēti, ideālā gadījumā ar dzimtās valodas runātājiem. Pielāgojiet virsrakstu un aprakstu arī vietējām īpatnībām – piemēram, Francijā bieži tiek gaidīta formāla uzruna, savukārt ASV ir ierasts brīvāks tonis. Jāņem vērā arī juridiskie aspekti: dažās valstīs noteiktus terminus, piemēram, "bezmaksas" vai "labākais", drīkst lietot tikai ar nosacījumiem. Lai to noskaidrotu, konsultējieties ar juristu. Pēc atjauninājuma pārbaudiet metadatus: sekojiet līdzi seansu un reklāmguvumu rādītājiem vismaz divas nedēļas, pirms galīgi apstiprināt izmaiņas. Atcerieties, ka ASO metadati nav statiski – tie jāatjauno atbilstoši sezonālām tendencēm vai jaunām funkcijām.

Ekrānuzņēmumi un lietotņu priekšskatījumi dažādos tirgos

Ekrānuzņēmumi un lietotņu priekšskatījumi (video) bieži ir pirmais vizuālais iespaids par jūsu lietotni veikalā un būtiski ietekmē klikšķu un lejupielāžu rādītājus. Ar vienkāršu teksta tulkošanu uz attēliem nepietiek: kultūras atšķirības krāsu uztverē, lasīšanas virzienā vai cilvēku un simbolu attēlojumā var mainīt efektu. Rietumu tirgos bieži tiek dota priekšroka skaidram, minimālismam dizainam, savukārt Āzijas valstīs, piemēram, Japānā vai Dienvidkorejā, ekrānuzņēmumos ir ierasts lielāks informācijas blīvums. Arī elementu izkārtojums jāpielāgo lasīšanas virzienam: tirgiem ar rakstību no labās uz kreiso (piemēram, arābu valoda) ekrānuzņēmumi jāatspoguļo, lai skatījums būtu dabisks.

Veidojot lokalizētus ekrānuzņēmumus, ieteicams izmantot modulāru izkārtojumu: fonu, tekstu un vizuālos elementus atdalīt, lai katram tirgum būtu jāmaina tikai teksta līmenis. Izmantojiet vietējos fontus, kas pareizi attēlo attiecīgās rakstzīmes. Pievērsiet uzmanību kultūras kodiem: roka ar īkšķi Tuvajos Austrumos vai Rietumāfrikā nozīmē kaut ko citu. Ekrānuzņēmumos attēlojiet cilvēkus ar tirgum raksturīgu apģērbu vai ādas krāsu – bet izvairieties no stereotipiem. Arī krāsu izvēle var ietekmēt reklāmguvumus: Ķīnā sarkanā krāsa simbolizē veiksmi, bet Dienvidāfrikā to var saistīt ar skumjām. Praksē jums jāidentificē pro-tirgi un jāizveido atsevišķi ekrānuzņēmumu komplekti, kurus validējat A/B testos.

Lietotņu priekšskatījumi (video) ir sarežģītāki, bet īpaši vērtīgi reklāmguvumu uzlabošanai. Lokalizējiet ne tikai runāto tekstu, bet arī attēlos ievietotos grafikus vai animācijas. Pārliecinieties, ka izveidojat vietējās valodas versijas ar atbilstošiem runātājiem. Video garumam jābūt mazākam par 30 sekundēm un jāparāda pamatfunkcijas. Valstīs ar lēnu interneta savienojumu samaziniet faila izmēru – izmantojiet kompresiju, pārāk neietekmējot kvalitāti. Konkrēts rīcības ieteikums: katram mērķa tirgum izveidojiet kontrolsarakstu ar kultūras pielāgojumiem (krāsas, simboli, cilvēki, lasīšanas virziens) un ļaujiet vietējai komandai pārbaudīt aktīvus. Pēc publicēšanas veiciet ikmēneša reklāmguvumu rādītāju analīzi un nepieciešamības gadījumā pielāgojiet ekrānuzņēmumus. Juridiski jābūt drošiem, izmantojot reālu cilvēku vai zīmolu attēlus – nepieciešamības gadījumā iegūstiet piekrišanu.

Tulkošanas vadība un terminoloģijas darbs

Konsekventa tulkošanas pārvaldība ir pamats veiksmīgai lietotņu lokalizācijai iOS un Android platformās. Pirmais solis ir izveidot tulkošanas pārvaldības sistēmu (TMS), kas centralizēti pārvalda visus valodu resursus. Praksē ir pierādījies, ka tekstus ir lietderīgi turēt atsevišķā slānī no koda, piemēram, izmantojot lokalizācijas failus, piemēram, .strings (iOS) vai .xml (Android). Tos var tieši importēt TMS un no turienes nodot tulkotājiem vai mašīntulkošanas sistēmām.

Izšķiroša nozīme ir uzņēmuma mēroga glosārija un stila rokasgrāmatas uzturēšanai. Glosārijs katrai valodai nosaka saistošus tehnisko terminu, produktu nosaukumu un UI elementu tulkojumus. Tādējādi tiek novērsta situācija, ka viens un tas pats angļu termins dažādos kontekstos tiek tulkots atšķirīgi. Stila rokasgrāmata definē toni, formulēšanas noteikumus (piemēram, uzrunas forma „Jūs” vai „tu”) un aplūko platformai specifiskas īpatnības: Android platformā pogas bieži vien ir īsākas, savukārt iOS pieļauj garākus tekstus. Arī veikalu rakstzīmju garuma ierobežojumi (30 rakstzīmes virsrakstam iOS, 30 Google Play) būtu jāiekļauj stila rokasgrāmatā.

Vēl viens svarīgs aspekts ir terminoloģijas darbs. Tas ietver regulāru izmantoto terminu pārbaudi attiecībā uz konsekvenci un aktualitāti. Praksē ir pierādījies, ka reizi ceturksnī glosāriju pārskatīšana, ko veic nozares nodaļas, ir efektīva. Turklāt jāveido tulkošanas atmiņas (Translation Memories), kas atpazīst atkārtotas frāzes un tādējādi paaugstina efektivitāti. Pārliecinieties, ka tulkošanas atmiņas ir izmantojamas starp platformām, jo daudzi teksti (piemēram, iestatījumi, kļūdu ziņojumi) iOS un Android var būt identiski.

Konkrēts rīcības ieteikums: izmantojiet TMS, piemēram, Crowdin vai Phrase, kas nodrošina tiešu integrāciju jūsu CI/CD caurulē. Uzturiet centrālu glosāriju ar vismaz 200 ierakstiem katrā valodā un izveidojiet stila rokasgrāmatu, kas ņem vērā arī platformai specifiskus UI ierobežojumus. Pirms katra lielāka laidiena pārbaudiet visus terminus un dokumentējiet izmaiņas, kontrolējot versijas.

Piezīme: Ja rodas juridiski jautājumi par AGB vai privātuma politikas tulkošanu, lūdzu, konsultējieties ar juridisko padomdevēju.

Darbplūsmas: Lokalizācija agilos izstrādes procesos

Lokalizācijas integrēšana agilos izstrādes procesos prasa ciešu izstrādes, tulkošanas un kvalitātes nodrošināšanas savienojumu. Ievērojamu efektivitāti ir pierādījuši tā sauktie "Lokalizācijas sprinti", kas norit paralēli izstrādes sprintiem. Šajā procesā tulkojamie teksti jau tiek identificēti sprintu plānošanā un reģistrēti kā lietotāju stāsti. Tulkošana notiek ar laika nobīdi, ideālā gadījumā viena sprinta ietvaros, lai lokalizētos tekstus varētu testēt nākamajā sprintā.

Centrālais elements ir automatizācija. Izmantojiet nepārtrauktās integrācijas (CI) caurules, kas pie katra koda revīzijas automātiski izvelk lokalizācijas failus un nosūta tos uz jūsu TMS. Pēc tulkošanas faili tiek atgriezti atpakaļ repozitorijā. iOS platformai šim nolūkam ir piemērots rīks Fastlane ar darbību `lane :refresh_localization`; Android var izmantot Gradle uzdevumus. Praksē ir pierādījies, ka lokalizācijas failus ir lietderīgi versijot atsevišķā atzarā, lai novērstu konfliktus.

Vēl viens izaicinājums ir izmaiņu pārvaldība. Ja sprinta laikā mainās avota teksts, tulkojumi ir jāatjauno. Šeit palīdz “String Freeze” (tulkojumu iesaldēšana): dažas dienas pirms sprinta beigām teksti tiek iesaldēti un mainīti tikai steidzamiem kļūdu labojumiem. Visi jaunie vai mainītie virknes tiek automātiski atzīmēti priekšskatā TMS. Sadarbībai ar tulkotājiem ieteicams izmantot “Continuous Localization” pieeju, kur nelieli teksta apjomi tiek tulkoti nepārtraukti, nevis apkopoti beigās.

Konkrēts rīcības ieteikums: ieviesiet Git bāzētu darbplūsmu ar automātisku lokalizācijas failu eksportu/importu. Definējiet skaidras saskarnes starp izstrādātāju komandām un tulkotājiem, piemēram, izmantojot Slack integrācijas. Ieviesiet divu nedēļu sprintu ritmu, kurā lokalizācija ir neatņemama “Definition of Done” sastāvdaļa. Testējiet lokalizētos būvējumus jau sprinta apskatā.

Piezīme: Izmantojot agility metodes, var būt nepieciešama cieša saskaņošana ar produktu pārvaldību, lai nenovērtētu par zemu valodas izmaiņas. Meklējiet juridisku padomu, ja izmantojat lokalizētu saturu regulētās jomās (veselība, finanses).

Testēšanas stratēģijas lokalizētām lietotnēm abās platformās

Lokalizētu lietotņu testēšanai nepieciešama daudzslāņu stratēģija, kas ietver gan automātiskās, gan manuālās pārbaudes. Sāciet ar automatizētiem testiem teksta līmenī: izmantojiet skriptus, kas pārbauda, vai visas virknes ir pareizi lokalizētas (nav trūkstošu tulkojumu) un vai tiek ievēroti rakstzīmju garuma ierobežojumi. iOS gadījumā var izsaukt UI testu ar XCTest, kas pārbauda, vai vācu lokalizācijā neparādās angļu valoda; Android ir pieejams Espresso ar līdzīgām funkcijām. Šiem testiem jābūt daļai no jūsu CI cauruļvada un jāpalaiž katrā būvējumā.

Turklāt nepieciešami kultūras un konteksta testi. Ļaujiet dzimtās valodas runātājiem pārbaudīt lietotni katrā mērķa tirgū uz reālas ierīces. Tādējādi pārbaudiet ne tikai tulkojuma kvalitāti, bet arī pareizu datuma, valūtas un skaitļu formātu attēlošanu. Pievērsiet uzmanību platformai specifiskām UI komponentēm: iOS izvēlnes un datuma atlasītāji tiek attēloti atšķirīgi nekā Android, kas var izraisīt atšķirīgu teksta garumu. Pārbaudiet arī, vai pogas un etiķetes netiek nogrieztas – īpaši ar gariem vācu vārdiem („Benachrichtigungseinstellungen“).

Vēl viens kritisks punkts ir testēšana valodām, kas rakstītas no labās uz kreiso pusi (arābu, ivritam). Gan iOS, gan Android piedāvā izkārtojuma pielāgojumus, kas lietotnē ir pareizi jāīsteno. Šeit ieteicams izmantot automātisku momentuzņēmumu testu, kas salīdzina ekrānuzņēmumus dažādās valodās. Regresijas pārbaudei varat izmantot tādus rīkus kā Firebase Test Lab vai Xcode Cloud, lai paralēli testētu lokalizētus būvējumus uz daudzām ierīcēm.

Konkrēta rīcības rekomendācija: izveidojiet manuālo testu kontrolsarakstu ar vismaz 20 punktiem katrā valodā, kas aptver kultūras īpatnības (piem., krāsas, simbolus). Veiciet automatizētus “String Completion” testus un UI momentuzņēmumu testus katrai valodai. Atbilstoši apjomam plānojiet no pusdienas līdz divām dienām testēšanas laika katrai valodai un platformai. Dokumentējiet atrastās kļūdas biļešu sistēmā, norādot valodas variantu un ierīces tipu.

Piezīme: lokalizētā satura juridiskā pārbaude, īpaši produktu aprakstos vai medicīnas tekstos, nav ietverta testos. Šajā gadījumā konsultējieties ar specializētu juristu.

Rīki un automatizācija starpplatformu lokalizācijai

Efektīvai iOS un Android lokalizācijai nepieciešami specializēti rīki, kas atbalsta abas platformas un ļauj integrēt esošajos izstrādes procesos. Tulkošanas pārvaldības sistēmas (TMS) veido mugurkaulu: tās pārvalda tulkojumus, piedāvā tulkošanas atmiņu un terminoloģijas datubāzes, kā arī ļauj sadarboties ar tulkotājiem. Izvēloties, pārliecinieties, vai TMS apstrādā abu platformu vietējos virkņu formātus – XML Android, .strings vai .xcstrings iOS – un nodrošina divvirzienu sinhronizāciju ar jūsu koda repozitoriju.

Automatizācija samazina manuālos soļus un kļūdu avotus. Iestatiet automātisku jaunu virkņu izgūšanu no pirmkoda: pēc katra pievienojuma izstrādes atzarā API nosūta jaunos teksta elementus uz TMS. Pēc pabeigšanas tulkojumi tiek automātiski ierakstīti atpakaļ repozitorijā, nodrošinot izstrādātājiem vienmēr aktuālu stāvokli. Standarta ir integrācija ar izplatītām versiju kontroles sistēmām, piemēram, Git. Plānojiet arī tulkošanas atmiņas izmantošanu, lai atkārtoti izmantotu jau tulkotos segmentus – tas ietaupa laiku un nodrošina konsekvenci.

Kvalitātes nodrošināšanai izmantojiet automatizētus testus, kas pārbauda, vai visas virknes ir tulkotas un vai nav bojāti vietturi. Daudzas TMS atbalsta “viltus tulkojuma” režīmus, kuros virknes tiek mākslīgi pagarinātas, lai agri atklātu izkārtojuma problēmas. Turklāt izmantojiet mašīntulkošanas integrāciju kā sākotnējo tulkojumu; tomēr rezultāti vienmēr jāpārbauda dzimtās valodas runātājiem. Praksē ir sevi pierādījis hibrīds darba plūsmas modelis: vispirms mašīntulkojums, tad rediģēšana TMS, pēc tam automātiskā eksportēšana.

Konkrēta rīcības rekomendācija: izvēlieties TMS ar atvērtu API un starpplatformu atbalstu. Definējiet vienotus virkņu nosaukumu un komentēšanas standartus, lai sniegtu kontekstu tulkotājiem. Pirms laidieniem ieviesiet regulāru “virkņu iesaldēšanas” fāzi, lai tulkojumus varētu pabeigt. Vispirms izmēģiniet automatizēto cauruļvadu nelielā tirgū, pirms to izvēršat visos tirgos. Pārliecinieties, ka jūsu rīku ķēde nerada īpašumtiesību atkarības – jums vienmēr jābūt iespējai pāriet uz citu risinājumu.

Juridiskās un kultūras prasības mērķa tirgos

Lietotnes lokalizācija neaprobežojas tikai ar tulkošanu; tai jāņem vērā arī katra mērķa tirgus juridiskās un kultūras īpatnības. Juridiski īpaši svarīgi ir datu aizsardzība, impresuma pienākums un marķēšanas prasības lietotnē veiktajiem pirkumiem. ES jāievēro VDAR – jūsu lietotnei jābūt skaidram datu aizsardzības paziņojumam un jāsaņem lietotāja piekrišana. Kalifornijā piemēro CCPA, Dienvidkorejā – Personas informācijas aizsardzības likumu. Arī vecuma ierobežojumi un bērnu aizsardzības iestatījumi ievērojami atšķiras; iepazīstieties ar lietotņu veikalu sistēmām (piem., App Store vecuma klasifikācija, Google Play satura klasifikācija). Šajā jautājumā konsultējieties ar savu juridisko nodaļu vai specializētu advokātu – šajā ceļvedī sniegtā informācija neaizstāj juridisko konsultāciju.

Kultūras prasības attiecas uz vizuālajiem un saturiskajiem aspektiem. Krāsām dažādās kultūrās var būt pretējas nozīmes: sarkanā Ķīnā simbolizē veiksmi, Rietumvalstīs bieži briesmas. Attēlos un simbolos izvairieties no žestiem, kas lokāli varētu šķist aizskaroši (piem., „Īkšķis uz augšu” dažos Tuvo Austrumu reģionos). Pielāgojiet datuma un laika formātus, valūtas un mērvienības reģionālajiem standartiem. Arī skaitļu attēlojumam – decimāldaļu atdalītājs, tūkstošu atdalītājs – jābūt pareizam. Izmantojiet lokalizāciju apzinošas formatēšanas bibliotēkas, lai šos pielāgojumus veiktu automātiski.

Papildus tīrajam interfeisam maksājumu metodes ir izšķirošs kultūras faktors: Ķīnā piedāvājiet Alipay un WeChat Pay, Vācijā tiešo debetu vai PayPal, ASV kredītkartes. Pārliecinieties, ka jūsu lietotne ņem vērā vietējos svētkus un notikumus – piemēram, īpašu tēmu Jaunajam gadam vai nacionālās piemiņas dienas. Arī pašam lietotnes veikala ierakstam jābūt lokalizētam: virsrakstam, aprakstam un atslēgvārdiem jāietver valstij specifiski termini un jābūt kulturāli atbilstošiem.

Rīcības ieteikums: katram mērķa tirgum izveidojiet kontrolsarakstu ar juridiskajiem dokumentiem (datu aizsardzības paziņojums, noteikumi un nosacījumi, impresums) un kultūras pielāgojumiem (krāsas, attēli, maksājumu metodes). Uzdodiet dzimtās valodas ekspertiem pārbaudīt ekrānuzņēmumus, tekstus un simbolus. Ieviesiet atsevišķu kultūras komponenti, kas atkarībā no tirgus ielādē atbilstošus resursus. Atvēliet pietiekami daudz laika juridiskajām pārbaudēm un iespējamām sertifikācijām – šie procesi var ilgt vairākas nedēļas. Testējiet lokalizēto lietotni ar vietējiem lietotājiem, lai savlaicīgi atklātu negaidītus kultūras pārpratumus.

CI/CD integrācija ar lokalizācijas cauruļvadiem

Lokalizācijas integrēšana jūsu CI/CD cauruļvadā (Continuous Integration / Continuous Delivery) ļauj automātiski un nevainojami iekļaut tulkojumus izstrādes procesā. Mērķis ir, lai katrs būvējums automātiski saturētu jaunākos tulkojumus bez manuālas eksportēšanas vai importēšanas. Lai to panāktu, cauruļvads tiek paplašināts ar lokalizācijas posmu: pēc lietotnes kompilēšanas visi jaunie vai mainītie teksta virknes tiek izvilkti un nosūtīti tulkošanas pārvaldības sistēmai (TMS). Paralēli tiek palaisti automatizēti testi, kas pārbauda, vai visas virknes ir tulkotas un nav formatēšanas kļūdu.

Kad tulkojumi TMS ir pabeigti, tie tiek automātiski ierakstīti atpakaļ repozitorijā (piem., kā izmaiņu pieprasījums). Šis process var notikt asinhroni, lai netiktu bloķēta izstrādes plūsma. Izplatīts modelis ir funkciju atzaru izmantošana: jaunai laidiena atzarai virknes tiek „iesaldētas” noteiktā laikā un nodotas TMS. Tulkojumi tiek piegādāti testēšanas perioda laikā un sapludināti pirms galīgā būvējuma. Agilās vidēs var tulkot arī nepārtraukti – tomēr jāņem vērā, ka vēlīnās virkņu izmaiņas pirms laidiena var nebūt pilnībā tulkotas.

CI/CD integrācijas izaicinājumi ir tulkojumu latentums un to virkņu apstrāde, kas vēl nav lokalizētas. Kā risinājums jums ir vairākas iespējas: (1) izmantojiet aizvietotājus vai rezerves virknes, lai netulkotās vietas interfeisā parādītu angliski vai ar neitrālu tekstu; (2) ieviesiet funkciju karogus, lai paslēptu funkcijas, kuru tulkojumi vēl nav gatavi; (3) plānojiet atsevišķas pirmsizlaišanas atzarus, kuros tiek sapludināti tikai tulkojumi. Praksē ir pierādījusies automatizētas eksportēšanas un manuālas tulkojumu apstiprināšanas kombinācija – īpaši kritiskiem saturiem, piemēram, juridiskajiem tekstiem vai maksājumu plūsmām.

Rīcības ieteikums: savā CI/CD platformā (piem., Jenkins, GitLab CI, GitHub Actions) iestatiet darbu, kas pie katra jauna commit nosūta virknes TMS. Izmantojiet TMS tīmekļa āķus, lai, kad tulkojumi ir gatavi, automātiski izveidotu izmaiņu pieprasījumu. Definējiet skaidrus laika posmus tulkojumiem pirms laidieniem un sazinieties ar savu lokalizācijas komandu. Testējiet cauruļvadu ar automatizētu „lokalitātes pārbaudi”: skripts pārbauda, vai visas atslēgas mērķu valodās ir klāt un vai aizvietotāji ir pareizi iestatīti. Dokumentējiet visu darbplūsmu, lai izstrādātāji un tulkotāji jebkurā laikā varētu redzēt statusu. Ņemiet vērā: plānojiet izņēmumus – ne katram tirgum nepieciešams vienāds tulkošanas dziļums, un dažus saturus (piem., ekrānuzņēmumus) nevar pilnībā automatizēt.

Biežas kļūdas un risinājumi praksē

Tipiska kļūda starpplatformu lokalizācijā ir pieņēmums, ka vienreiz tulkotus tekstus var identiski izmantot abām platformām. Praksē izpaužas atšķirības rakstzīmju garuma ierobežojumos: iOS pogu etiķetes bieži pieļauj mazāk rakstzīmju nekā Android teksta lauki. Rezultātā rodas nogriezti vārdi vai izjaukts izkārtojums. Pārbaudīts risinājums ir platformai specifisku tulkošanas resursu izveide ar atsevišķām virknēm, kas optimizētas attiecīgajam lietotāja interfeisam. Izmantojiet rīkus, kas vizualizē rakstzīmju ierobežojumus katrai platformai, un testējiet agri uz reālām ierīcēm.

Vēl viena problēmjoma ir metadatu nekonsekventa lokalizācija. Bieži vien lietotņu nosaukumi un atslēgvārdi abiem veikaliem tiek tulkoti gandrīz identiski, neņemot vērā Apple un Google atšķirīgos algoritmus. Pieredze rāda, ka Google Play veikals ir jutīgāks pret atslēgvārdu blīvumu nosaukumā, savukārt App Store vairāk vērtē aprakstošus atslēgvārdus. Risinājums: izveidojiet katram tirgum un platformai atsevišķas metadatu virknes, kas ietver vietējos meklēšanas paradumus, un izmantojiet A/B testēšanu kritiskām kombinācijām.

Arī kultūras nianses bieži tiek ignorētas. Krāsu kods, kas Vācijā signalizē profesionalitāti, citā valstī var tikt uztverts negatīvi. Tā vietā, lai vispārīgi mainītu krāsas, katram mērķa tirgum vajadzētu veikt īsu kultūras analīzi. Tas pats attiecas uz simboliem: paceltais īkšķis vai ķeksītis ne visur nozīmē vienu un to pašu. Pragmatiska pieeja ir izveidot stila ceļveža papildinājumu, kas fiksē platformai specifiskas un kulturālas korekcijas ikonām, ekrānuzņēmumiem un lietotāja interfeisa elementiem.

Vēl viena bieži sastopama kļūda ir pareizrakstības un gramatikas pārbaužu neievērošana kontekstā. Mašīntulkošanas rezultāti bieži ir formāli korekti, bet nedabiski formulēti. Praksē pierādījusies divu līmeņu kvalitātes nodrošināšana: vispirms automatizēta pārbaude formatēšanas kļūdām un nekonsekventai terminoloģijai, pēc tam dzimtās valodas runātāja pārskatīšana, ko veic lokalizācijas eksperts. Plānojiet tam pietiekami daudz laika izstrādes sprintā – ideāli kā fiksētu soli pirms izlaišanas.

Kontrolsaraksts un nākotnes tendences lietotņu lokalizācijā

Pragmatisks kontrolsaraksts starpplatformu lokalizācijai palīdz neizlaist nevienu būtisku soli. Pirms sākšanas pārbaudiet internacionalizāciju: vai visas lietotāja interfeisa virknes ir eksternalizētas? Vai platformas atbalsta rakstību no labās uz kreiso pusi? Pievērsiet uzmanību pietiekamai vietai teksta paplašinājumiem – pieredze rāda, ka vācu valodai var būt nepieciešams līdz pat 40% vairāk rakstzīmju nekā angļu valodai. Turklāt izveidojiet platformai specifiskus lokalizācijas testus: testējiet uz reālām ierīcēm ar atbilstošām sistēmas valodām, ne tikai simulatorā.

Metadatu lokalizācijai katram tirgum un platformai vajadzētu izpētīt atsevišķus atslēgvārdus. Izmantojiet vietējos meklēšanas terminus, kurus var saskaņot App Store Connect un Google Play Console. Atjauniniet ekrānuzņēmumus un lietotņu priekšskatījumus ar lokalizētiem tekstiem, taču pievērsiet uzmanību kulturāli atbilstošiem attēlu motīviem. Regulārs visu vietējo ierakstu audits – vismaz reizi trijos mēnešos – palīdz saglabāt aktualitāti un atbilstību.

Darbplūsmu jomā par standartu kļūst AI atbalstītu tulkojumu integrācija ar cilvēka pārbaudi. Tādas tendences kā nepārtrauktā lokalizācija (tulkošana paralēli izstrādei) un automātiska ekrānuzņēmumu ģenerēšana ar lokalizētiem tekstiem kļūst arvien nozīmīgākas. Praksē tulkošanas atmiņu (TM) un neironu mašīntulkošanas kombinācija izrādās efektīva, taču prasa rūpīgu terminoloģijas pārvaldību. Ieguldiet centrālajā glosārijā, ko izmanto visi iesaistītie – izstrādātāji, tulkotāji un produktu īpašnieki.

Vēl viena nākotnes tendence: pieaugošā lietotņu komponentu, piemēram, SwiftUI un Jetpack Compose, izmantošana prasa pielāgotas lokalizācijas stratēģijas. Tā kā šie ietvari ļauj dinamiskus lietotāja interfeisa elementus, plānojiet elastīgus teksta garumus jau dizaina fāzē. Arī pieaugošā iepirkumu lietotnē un abonēšanas modeļu nozīme padara nepieciešamu precīzu cenu, valūtu un juridisko tekstu lokalizāciju. Konsultējieties ar juridisko ekspertu, lai izpildītu vietējās prasības par pakalpojumu sniedzēja norādi un datu aizsardzību.

Visbeidzot: veiksmīga lietotņu lokalizācija nav vienreizējs projekts, bet gan nepārtraukts process. Regulāri pārbaudiet savu lokalizēto lietotņu veiktspēju attiecīgajā veikalā, vāciet lietotāju atsauksmes un pielāgojiet savu stratēģiju. Ar stabilu kontrolsarakstu un skatu uz aktuālajām tendencēm esat labi sagatavoti, lai profesionāli darbotos 24 tirgos.

Budžets, izmaksas un sadarbība ar pakalpojumu sniedzējiem

Lietotnes starpplatformu lokalizācijas izmaksas ir grūti noteikt vienā skaitlī, jo tās ir atkarīgas no apjoma, valodu skaita un kvalitātes prasībām. Kā vispārējs noteikums: tulkošanas izmaksas uz vienu vārdu ir mazākā pozīcija. Ievērojami lielākas ir izmaksas par internacionalizāciju (i18n), saskarnes pielāgojumiem un testēšanu. Vidēja lieluma lietotnei ar 10 000 vārdu un 10 valodām jārēķinās ar budžetu 20 000–50 000 EUR apmērā, ieskaitot tehniskās izmaiņas un kvalitātes nodrošināšanu. Pakalpojumu sniedzēja izvēle būtiski ietekmē izmaksas un kvalitāti.

Sadarbībā ar tulkošanas aģentūrām vai ārštata darbiniekiem ir svarīgi skaidri specifikācijas. Definējiet terminoloģijas glosārijus, stila ceļvežus un atsauces materiālus. Pārliecinieties, ka pakalpojumu sniedzējs saprot gan iOS, gan Android kontekstu – īpaši attiecībā uz virkņu resursiem un formatēšanas vietturiem (piemēram, %@ iOS, %s Android). Pieprasiet testa tulkojumus, lai pārbaudītu kvalitāti. Daudzi pakalpojumu sniedzēji piedāvā tulkošanas atmiņas (TM), kas nodrošina konsekvenci un ilgtermiņā ietaupa izmaksas.

Bieža kļūda ir pieņēmums, ka pietiek ar vienreizēju tulkojumu. Lietotnes tiek regulāri atjauninātas, tāpēc nepieciešams nepārtraukts lokalizācijas process. Plānojiet atkārtotas izmaksas par atjauninājumiem – bieži vien 10–20% no sākotnējās tulkošanas summas par katru laidienu. Arī lokalizēto lietotņu testēšanas darbs bieži tiek novērtēts par zemu: katrai valodai un platformai jāplāno vismaz divas stundas manuālas testēšanas, kritiskām lietotnes daļām ievērojami vairāk. Automatizēti ekrānuzņēmumu testi var palīdzēt samazināt darba apjomu.

Izvēloties pakalpojumu sniedzēju lietotņu lokalizācijai, pievērsiet uzmanību pieredzei ar elastīgiem darbplūsmas modeļiem un CI/CD integrāciju. Jautājiet par atsauces projektiem un testu ziņojumiem. Labs pakalpojumu sniedzējs piedāvā ne tikai tulkošanu, bet arī kultūras konsultācijas un tehnisko atbalstu. Juridiski jāievēro, ka līgumā jānosaka tulkojumu lietošanas tiesības un jāievēro datu aizsardzības noteikumi. Tas neaizstāj juridisko konsultāciju, taču būtu jāiekļauj līgumā.

Lokalizācijas panākumu mērīšana: KPI un analīze

Lai novērtētu lokalizācijas ieguldījumu atdevi, jāizmanto mērāmi rādītāji, kas pārsniedz tulkošanas kvalitāti. Papildus lejupielāžu skaitam mērķa tirgos (App Store Connect un Play Console) īpaši svarīgas ir lietotāju piesaistes izmaksas (CPI) un reklāmguvumu līmenis attiecīgajā veikala lapā lokalizētiem metadatiem. Platformai specifisks KPI ir lietotnē veikto pirkumu daļa, kas pabeigta, izmantojot lokalizētus maksājumu ekrānus – tas tieši parāda kultūras pielāgotu tekstu ietekmi.

Arī atgriešanās rādītājs (retention rate) pēc 7 un 30 dienām sniedz ieskatu: lietotāji, kas lietotni izmanto savā dzimtajā valodā, parasti paliek aktīvāki ilgāk. Izmantojiet abu veikalu analīzes rīkus (iOS: App Analytics; Android: Play Console Insight), lai salīdzinātu veiktspēju pa valstīm un valodām. Vēl viens svarīgs rādītājs ir atbalsta biļešu skaits, kas saistīts ar valodas problēmām. Šādu biļešu samazinājums pēc lokalizācijas kārtas norāda uz uzlabotu lietotāja pieredzi.

Tomēr jāuzmanās no atsevišķu tirgu salīdzināšanas, jo ārējie faktori, piemēram, konkurence vai mārketinga kampaņas, var izkropļot skaitļus. Labāk izmantot A/B testu: vienai lietotāju daļai tirgū rādīt lokalizēto versiju, otrai – nelokalizēto, un mērīt atšķirības lejupielādēs, pirkumos un vērtējumos. Šādus testus var veikt ar Firebase A/B Testing vai veikalu iebūvētajām A/B funkcijām.

Papildus ieteicams regulāri pārskatīt lietotņu vērtējumus un atsauksmes mērķa valodās. Negatīvas atsauksmes, kas norāda uz tulkošanas kļūdām vai kultūras pārpratumiem, ir skaidrs signāls, ka lokalizācija jāuzlabo. Dokumentējiet visus KPI informācijas panelī, lai sekotu progresam vairāku laidienu gaitā. Tā izvairīsieties no tā, ka atsevišķi tirgi sliktas lokalizācijas dēļ nemanāmi atpaliek. Praksē redzams, ka nepārtraukta lietotāju datu uzraudzība ir viens no efektīvākajiem veidiem, kā uzlabot lokalizācijas kvalitāti un ietekmi.