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

Platformu pārrobežu lokalizācijas pamati

Platformu pārrobežu lokalizācija iOS un Android lietotnēm prasa agrīnu stratēģisku plānošanu, lai izvairītos no tehniskām un valodas barjerām. Atšķirībā no vienas platformas, jums ir ne tikai jānodrošina tekstu tulkošana, bet arī jāveic kultūras pielāgojumi, skaitļu formātu un datumu attēlojumu vienādošana vai atsevišķa optimizēšana abām operētājsistēmām. Centrālā pieeja ir izmantot kopīgu lokalizācijas formātu, piemēram, XLIFF vai gettext, ko atbalsta abu platformu izstrādes rīki. Tādējādi var izveidot vienotu tulkošanas darbplūsmu, neprasot, lai katrai platformai būtu savi faili.

Ideālā gadījumā jūs eksportējat visu lokalizējamo saturu no sava koda uz centrālu avotu – piemēram, virkņu katalogu – un importējat tulkojumus atpakaļ. Tomēr jāņem vērā, ka iOS lietotnes bieži izmanto .strings vai .stringdict failus, savukārt Android strādā ar XML resursu failiem. Lokalizācijas pārvaldnieks vai CI/CD process var automātiski veikt šo konvertāciju un nodrošināt pareizu daudzskaitļa apstrādi (piemēram, izmantojot ICU Plural Rules) un RTL saderību.

Vēl viens būtisks aspekts ir agrīna koda un teksta nošķiršana. Izvairieties no cieti kodētām virknēm neatkarīgi no tā, vai izmantojat Swift, Kotlin vai Flutter. Tā vietā izmantojiet attiecīgajai platformai atbilstošu internacionalizācijas mehānismu. Pašam tulkošanas procesam ieteicams piesaistīt profesionālus tulkotājus, kuri pārzina katra tirgus valodas un kultūras īpatnības. Ņemiet vērā, ka daži termini, piemēram, „Vārds” vai „Pasta indekss”, citās valstīs var tikt interpretēti atšķirīgi.

Rīcības ieteikums: Izveidojiet darbplūsmu, kas automātiski izplata tulkojumus no centrāla avota uz abām platformām. Izmantojiet tādus rīkus kā Lokalise vai Crowdin, kas atbalsta gan iOS, gan Android, un pārliecinieties, ka jūsu izstrādes komanda jau koda izveides laikā pievērš uzmanību lokalizācijai. Regulāri pārbaudiet tulkojumu konsekvenci starp platformām, lai novērstu atšķirības.

Atšķirības UI dizainā: iOS Human Interface Guidelines pret Android Material Design

iOS un Android ievēro atšķirīgas dizaina filozofijas, kas tieši ietekmē jūsu lietotnes lokalizāciju un lietojamību. iOS Human Interface Guidelines uzsver skaidrību, dziļumu un cieņu. Elementi, piemēram, navigācijas joslas, cilņu joslas un modālie logi, ir standartizēti. Turpretī Android balstās uz Material Design koncepciju, kas akcentē plakanus slāņus, konsekventas ēnas un pielāgojamu krāsu paleti. Šīs atšķirības ietekmē ne tikai vizuālo izskatu, bet arī tekstu elementu izvietojumu, kas lokalizācijas laikā var mainīties.

Praktisks piemērs: Kamēr iOS pēc noklusējuma izmanto centrētu virsraksta joslu, Android mēdz novietot virsrakstu pa kreisi. Ja jūsu lietotne abām platformām izmanto vienu un to pašu lietotāja interfeisu, jums jānodrošina, ka garie tulkojumi – piemēram, vācu vai franču valodā – netiek nogriezti. iOS navigācijas josla īpaši gariem virsrakstiem var automātiski samazināt burtu izmēru, savukārt Android bieži atļauj vairāku rindiņu tekstu. Šeit teksts būtu jātestē atsevišķi abām platformām.

Arī veidlapās un ievades laukos ir atšķirības: iOS bieži izmanto atsevišķu izvēles skatu (Picker) datumu vai sarakstu atlasēm, savukārt Android izmanto nolaižamās izvēlnes vai dialogus. Šādu mijiedarbību lokalizācijai nepieciešams ne tikai tulkot etiķetes, bet arī pielāgot vietturžus (Placeholder) un formātam atkarīgus tekstus, piemēram, „Izvēlieties datumu”. Turklāt abām platformām ir savas konvencijas pogām: iOS izmanto noapaļotus taisnstūrus ar izteiktu polsterējumu, Android – plakanas pogas ar krāsu vai apmali.

Rīcības ieteikums: Pārbaudiet savas lietotnes UI komponentus katrai platformai atsevišķi attiecībā uz iespējamām izkārtojuma problēmām dažādos teksta garumos. Izmantojiet Auto Layout iOS un Android specifiskos izkārtojuma pārvaldniekus, piemēram, ConstraintLayout, kas reaģē uz teksta paplašināšanu. Izveidojiet sarakstu ar visiem tekstiem, kas ievietoti fiksētos konteineros, piemēram, pogās vai etiķetēs, un pārbaudiet, vai šie konteineri ir pietiekami garākajam sagaidāmajam tulkojumam. Pirms izlaišanas testējiet lietotni abās platformās ar faktiskajiem tulkojumiem.

Layoutu un vietturu pielāgošana abām platformām

Viena no lielākajām problēmām starpplatformu lokalizācijā ir pareiza layoutu un vietturu pielāgošana, jo teksti dažādās valodās var būt dažāda garuma. Vārds „Anmelden” vācu valodā ir salīdzinoši īss, savukārt „Registration” angļu valodā jau ir garāks. Vēl ekstrēmāk tas ir krievu vai somu valodā, kur atsevišķi vārdi vai frāzes prasa ievērojami vairāk rakstzīmju. Bez elastīgiem layoutiem tas noved pie nogrieztiem tekstiem vai pārklājošiem UI elementiem.

Operētājsistēmā iOS jāizmanto Auto Layout ar dinamiskiem ierobežojumiem, kas pielāgojas teksta garumam. Izvairieties no fiksēta platuma etiķetēm un pogām. Tā vietā izmantojiet iekšējos satura izmērus un prioritizējiet horizontālo izplešanos. Android ieteicams izmantot ConstraintLayout vai LinearLayout ar Match-Parent, ierobežojot maksimālo platumu ar maxWidth, lai novērstu pārplūšanu. Daudzrindu tekstiem abās platformās izmantojiet rindu pielāgošanas opciju (piem., numberOfLines = 0 iOS, lines = unlimited XML).

Vietturi (Placeholder) ievades laukos un teksta skatos arī jālokalizē. Tie bieži satur paraugtekstus vai formatēšanas norādes, piemēram, „MM/DD/YYYY”. Pārliecinieties, ka šie vietturi tiek pielāgoti atbilstoši reģionam: Vācijā formāts būtu „TT.MM.JJJJ”, Japānā „YYYY/MM/DD”. Ņemiet vērā, ka vietturi nedrīkst būt iestrādāti tulkojuma virknēs, bet jāapstrādā atsevišķi, lai nodrošinātu pareizu lokalizāciju. Vēl viens punkts ir salikti teksti, kuros dinamiskas vērtības tiek ievietotas statiskos teikumos. Šeit izmantojiet Format-Strings ar vietturiem, piemēram, %@ vai %d, kurus tulkojumā var novietot pareizajā gramatiskajā pozīcijā.

Rīcības ieteikums: Katram UI elementam nosakiet, vai tas var izplesties horizontāli vai vertikāli. Pārbaudiet savus layoutus ar garākajiem sagaidāmajiem tulkojumiem, izmantojot tā sauktās pseidolokalizācijas (piem., teksts ar pievienotām rakstzīmēm, kas paplašina layoutu). Pārbaudiet visus Format-Strings un vietturus, lai tie būtu pareizā sintaksē abām platformām. Izmantojiet tādus rīkus kā UI Testing ar ekrānuzņēmumu salīdzināšanu, lai automātiski atklātu vizuālās atšķirības. Dokumentējiet maksimālos teksta garumus, kādiem jāiztur jūsu UI komponentes, un paziņojiet tos tulkotājiem.

App Store Optimization iOS un Google Play: kopīgais un atšķirības

App Store Optimization (ASO) ir būtiska abām platformām, bet atšķiras niansēs. Kopīgais ir mērķis palielināt redzamību attiecīgajos veikalos un veicināt lejupielādes. Gan Apple App Store, gan Google Play svarīga loma ir nosaukumam, apakšvirsrakstam (iOS) jeb īsajam aprakstam (Android), aprakstam, atslēgvārdiem un ekrānuzņēmumiem. Ranking faktori ir līdzīgi: metadatu atbilstība, lejupielāžu skaits un vērtējumi, kā arī lietotāju mijiedarbība. Lokalizētai lietotnei praksē ir lielākas iespējas tikt atrastai ne-angļu valodu tirgos.

Būtiskākās atšķirības ir atslēgvārdu optimizācijā. App Store ir 100 rakstzīmju lauks atslēgvārdiem, kam nav jābūt nosaukumā vai apakšvirsrakstā. Google Play savukārt indeksē visu īsā apraksta un apraksta tekstu. Turklāt Google Play nosaukums un īsais apraksts ir ierobežoti līdz 30 un 80 rakstzīmēm, savukārt iOS atļauj nosaukumu (30 rakstzīmes), apakšvirsrakstu (30 rakstzīmes) un reklāmas priekšskatījumu (App Store Preview). Atšķiras arī lietotņu vērtējumu un atsauksmju svars: App Store atsauksmes par valsti tieši ietekmē rangu; Google Play vairāk tiek ņemts vērā kopējais vērtējums.

Veiksmīgai ASO vairākos tirgos iesakām: veiciet tirgum specifisku atslēgvārdu izpēti, izmantojiet lokalizācijas rīkus un pielāgojiet metadatus katrai valstij. Pievērsiet uzmanību kultūras atšķirībām – atslēgvārds, kas darbojas Vācijā, var būt nebūtisks Francijā. Testējiet dažādus nosaukumus un aprakstus A/B testos, ciktāl platforma to atļauj. Izvairieties no atslēgvārdu blīvēšanas, jo abi veikali izmanto algoritmus, kas vairākkārtējus atkārtojumus novērtē zemāk.

Praktisks padoms: Lokalizējiet ne tikai tekstu, bet arī ekrānuzņēmumus. Nomainiet iegultos attēlus ar tekstu pret lokalizētām versijām. Regulāri pārbaudiet garuma ierobežojumus katrai platformai, jo tie var mainīties. Juridiskajos aspektos, piemēram, vecuma ierobežojumos vai privātuma politikās, konsultējieties ar juristu.

Metadatu lokalizācija: nosaukums, apraksts, atslēgvārdi un ekrānuzņēmumi

Metadatu lokalizācija ir pirmais solis, lai kļūtu redzami ārvalstu tirgos. Nosaukums un apraksts ir ne tikai jātulko, bet arī kultūras ziņā jāpielāgo. Tiešs tulkošanas kļūda var pasliktināt atrodamību vai pat maldināt. App Store ievērojiet ierobežojumus: nosaukums maksimāli 30 rakstzīmes, apakšvirsraksts arī 30 rakstzīmes. Google Play nosaukums ir 30 rakstzīmes, īss apraksts 80 rakstzīmes un pilns apraksts 4000 rakstzīmes. Izmantojiet šo vietu mērķtiecīgi, lai iekļautu atbilstošus atslēgvārdus, nezaudējot lasāmību.

Atslēgvārdi jāpēta katram tirgum atsevišķi. Vārds, kas vācu valodā ir ļoti bieži lietots, spāņu valodā var būt pilnīgi nezināms. Tādi rīki kā Google Keyword Planner vai ASO platformas palīdz identificēt vietējos meklēšanas vārdus. App Store atslēgvārdus ievietojiet atsevišķā laukā (maks. 100 rakstzīmes) – šeit varat izmantot arī salikteņus bez atstarpēm. Google Play tiek indeksēti visi vārdi no nosaukuma un apraksta. Tāpēc izvairieties no atslēgvārdu blīvējuma un izmantojiet dabisku valodu.

Ekrānuzņēmumi un priekšskatījuma attēli ir bieži novērtēts faktors. Jums ir ne tikai jālokalizē teksti (piem., pogu marķējumi), bet arī jāpielāgo kultūras simboli un krāsas. Krāsa, kas Rietumeiropā rada pozitīvu iespaidu, Āzijā var radīt negatīvas asociācijas. Rādiet ekrānuzņēmumus ar vietējām valūtām, datuma formātiem un fontiem. App Store atļauj līdz desmit ekrānuzņēmumiem, Google Play līdz astoņiem – izmantojiet maksimālo skaitu un pārbaudiet dažādus izkārtojumus.

Rīcības ieteikums: Izveidojiet metadatu matricu visiem mērķa tirgiem. Katram tirgum izveidojiet atsevišķu atslēgvārdu kopumu un iteratīvi pielāgojiet nosaukumus un aprakstus. Lieciet pārbaudīt tulkojumus dzimtās valodas runātājiem, kas pārzina arī kultūras nianses. Ekrānuzņēmumiem izmantojiet veidni, kas ļauj viegli apmainīt tekstus un grafikus. Plānojiet regulārus metadatu atjauninājumus, jo tendences un meklēšanas paradumi mainās. Ņemiet vērā, ka izmaiņas metadatos neietekmē uzreiz, bet nepieciešams laiks, lai veikali tos pārmeklētu no jauna.

Rīkošanās ar lietotnē iegādātiem pirkumiem un abonēšanas modeļiem dažādos tirgos

Lietotnē iegādāti pirkumi (IAK) un abonēšana prasa rūpīgu lokalizāciju, jo tie ir tieši saistīti ar ieņēmumiem. Abās platformās produkti ir jākonfigurē attiecīgajos veikalos – pārvaldības saskarnes atšķiras, bet princips ir līdzīgs. Jūs nosakāt produktu ID, definējat cenas un pievienojat lokalizētus aprakstus. Īpaši svarīga ir cenu pielāgošana vietējai pirktspējai. Cena 2,99 € Vācijā var tikt uztverta pavisam citādi Indijā vai Brazīlijā. Tāpēc pielāgojiet cenu līmeņus katram tirgum, izmantojot Apple un Google noteiktās cenu kategoriju sistēmas.

Produktu aprakstu lokalizācijai (piem., „Iknedēļas abonements” pret „Gada abonements”) jābūt valodiski un kultūras ziņā pareizai. Dažās valstīs abonēšana ir mazāk izplatīta vai sastopas ar neuzticēšanos. Apsveriet iespēju piedāvāt alternatīvus pirkšanas modeļus, piemēram, vienreizējus pirkumus, ja abonēšana netiek pieņemta. Ievērojiet arī tiesību aktu prasības par atteikuma tiesībām un uzteikuma termiņiem. ES patērētājiem ir 14 dienu atteikuma tiesības digitālajam saturam – tas skaidri jānorāda vispārējos noteikumos. Lai nodrošinātu juridiski pareizus formulējumus, piesaistiet juridisko konsultantu.

Maksājumu apstrāde atšķiras atkarībā no valsts. Kamēr kredītkartes daudzos tirgos ir standarts, Āzijā lietotāji bieži dod priekšroku mobilajiem maksājumiem, piemēram, Alipay vai WeChat Pay. Apple un Google piedāvā savas maksājumu sistēmas, bet dažos tirgos varat integrēt arī alternatīvus maksājumu pakalpojumu sniedzējus – pārbaudiet veikala noteikumus. Nodokļu atšķirības (piem., PVN ES, PVN Šveicē) ir pareizi jāatspoguļo. ASV nodokļu likmes atšķiras pat starp štatiem.

Praktiska pieeja: Izveidojiet cenu matricu visiem mērķa tirgiem, pamatojoties uz vietējiem tirgus datiem un konkurences analīzēm. Katram tirgum pārbaudiet dažādus cenu līmeņus un abonēšanas modeļus (piem., iknedēļas, ikmēneša, gada). Pievērsiet uzmanību valūtas simbolu un decimālo atdalītāju attēlojumam. Lokalizējiet arī apstiprinājuma ziņojumus un e-pastus, kas tiek nosūtīti pēc pirkuma. Vienota pieredze stiprina uzticību. Plānojiet pietiekami daudz laika konfigurācijai un testēšanai, jo kļūdas IAK var radīt klientu neapmierinātību un ieņēmumu zaudējumus. Ņemiet vērā, ka veikali ierobežo izmaiņas produktu ID – tāpēc nosakiet tos stratēģiski jau sākumā.

Testēšanas stratēģijas iOS un Android: simulatori, ierīces un beta testi

Strukturēts testēšanas process ir būtisks, lai atklātu lokalizācijas kļūdas starp platformām. iOS gadījumā izmantojiet Xcode simulatorus ar dažādām ierīcēm un iOS versijām – īpašu uzmanību pievērsiet valodas virziena efektiem (piem., arābu, ivritam) un bloķēšanas ekrāna pārklājumiem. Lietojiet `xcrun simctl` rīku, lai iestatītu valodu un reģionu katram simulatoram. Android gadījumā noder Android emulatori ar AVD pārvaldnieku, testējot vairākus API līmeņus un ekrāna izmērus. Izmantojiet `adb shell setprop persist.sys.locale` ātrai pārslēgšanai. Simulatori palīdz veikt pamata pārbaudes, bet neaizstāj reālas ierīces testēšanu. Ieteicams testēt vismaz uz piecām fiziskām ierīcēm katrā platformā, ieskaitot zema un augsta līmeņa modeļus, kā arī planšetdatorus. Pievērsiet uzmanību attēlojuma kļūdām, piemēram, nogrieztiem tekstiem, nepareizām pogu pozīcijām vai nelasāmiem simboliem.

Beta fāzē iesaistiet dzimtās valodas runātājus. iOS izmantojiet TestFlight ar ārējiem testētājiem un sniedziet skaidrus norādījumus par izkārtojuma vai teksta problēmu ziņošanu. Android izmantojiet Google Play Console ar slēgtiem testa kanāliem un pārvaldiet testētāju grupas ar Google Groups. Abām platformām definējiet kontrolsarakstu, kas aptver datuma formātu, skaitļu formātu, valūtas pielāgošanu, pareizrakstību un kultūras atbilstību. Praktisks padoms: izveidojiet automatizētus ekrānuzņēmumu salīdzinājumus, izmantojot XCTest un Espresso, lai atklātu vizuālās atšķirības starp valodām. Tādējādi jūs samazināsiet manuālo pārbaužu skaitu tikai kritiskajiem gadījumiem.

Turklāt veiciet valodai specifiskus funkcionālos testus: pārbaudiet, vai URL ar speciālajām rakstzīmēm darbojas pareizi, vai ievades laukā parādās tastatūras noteiktām valodām (piem., japāņu, ķīniešu), un vai valūtas un numuru formatējumi tiek pareizi lietoti. Dokumentējiet visus testu rezultātus centrālajā informācijas panelī (piem., Jira vai TestRail) un klasificējiet kļūdas pēc platformas un valodu pāra. Ieplānojiet laiku regresijas testiem pēc katras lokalizācijas atjauninājuma. Ņemiet vērā: sekmīgs tests iOS nenozīmē automātisku Android versijas bez kļūdām – abas sistēmas interpretē resursus un izkārtojumus atšķirīgi. Tāpēc ieteicams veikt paralēlus testus katrai platformai ar atsevišķiem testa datiem.

String pārvaldība un resursu faili abām platformām

Efektīva string pārvaldība ir jebkuras daudzvalodu lietotnes mugurkauls. iOS izmanto `Localizable.strings` failus katrai valodai, kas satur atslēgas-vērtības pārus. Izmantojiet string katalogus (.xcstrings) no Xcode 15 vienkāršotai pārvaldībai. Android balstās uz XML resursu failiem `res/values-*` mapēs, ar `strings.xml` standarta tekstiem. Pārliecinieties, ka atslēgas ir konsekventas abās platformās – ideālā gadījumā nosakiet globālu konvenciju, piem., `onboarding_welcome_message`. Izvairieties no ieprogrammētām virknēm pirmkodā; izmantojiet ekstrakcijas rīkus, piemēram, genstrings (iOS) vai Android Studio’s Refactor > Extract String Resource. Failover mehānismi ir svarīgi: Android nosakiet bāzes `values/strings.xml` (piem., angļu) un specifiskas versijas; iOS norādiet izstrādes valodu Build Settings. Trūkstošu tulkojumu gadījumā iOS parāda atslēgu, Android izraisa ResourceNotFoundException – tāpēc testējiet visas valodas, ieskaitot fallback.

Izmantojiet tulkošanas pārvaldības sistēmas (TMS), piemēram, Lokalise vai POEditor, kas nodrošina abpusēju sinhronizāciju ar Git repozitorijiem. Uzturiet metadatus, piemēram, konteksta aprakstus katram stringam – piemēram, “Izmantots pieteikšanās ekrānā, maks. 20 rakstzīmes”. Lietojiet formatēšanas vietturus konsekventi: `%@` iOS (String), `%1$s` Android (String). Pievērsiet uzmanību dzimtes un daudzskaitļa formām: iOS izmanto `stringsdict` daudzskaitlim, Android izmanto `quantity strings` (`plurals.xml`). Bieža kļūda: Android plurāliem nepieciešama birka `</item>`; ja tās trūkst, lietotne avarē. Testējiet daudzskaitļa formas visām valodām ar vienkāršu vienības testu (piem., 0, 1, 2, 5).

Uzturiet string resursus neatkarīgus no platformas, kur iespējams – izmantojiet koplietotus repozitorijus un CI/CD cauruļvadus, kas automātiski nosūta tulkojumus uz abām projektu struktūrām. Ieviesiet linting noteikumus: bez netulkotiem stringiem, bez marķējumu tekstiem bez izbēgšanas rakstzīmēm. Regulāri pārbaudiet string skaitu: iOS varat izmantot `ibtool`, lai atrastu neizmantotus stringus; Android palīdz “Unused resources” lint. Strukturēta string pārvaldība samazina lokalizācijas kļūdas par aptuveni 30% un ievērojami paātrina izlaišanas.

Kultūras pielāgojumi: datumu formāti, valūtas, krāsas un simboli

Kultūras pielāgojumi pārsniedz tikai tulkošanu. Datumu formāti stipri atšķiras: iOS izmanto `NSDateFormatter` ar iepriekš definētiem stiliem, Android – `DateFormat` no `java.text`. Pārliecinieties, ka, piemēram, „12/05/2024“ ASV tiek interpretēts kā 12. maijs, bet Eiropā – kā 5. decembris. Vienmēr izmantojiet ierīces lokalizāciju (iOS: `Locale.current`, Android: `Locale.getDefault()`), nevis fiksētu reģionu. Attiecībā uz valūtām: formatējiet summas ar `NumberFormatter` (iOS) un `NumberFormat.getCurrencyInstance()` (Android). Pievērsiet uzmanību valūtas simboliem un to novietojumam: „€ 5,99“ pret „$5.99“. Lietotnēs ar fiksētām cenām vadošajā valūtā (piem., eiro) norādiet vietējo ekvivalentu, bet brīdiniet par iespējamām atšķirībām valūtas kursu dēļ. Procentiem un skaitļiem izmantojiet to pašu formatējumu – Indonēzijā, piemēram, decimāldaļas atdala ar komatu, tūkstošus ar punktu.

Krāsas un simboli pārnes kultūras vēstījumus. Sarkanā krāsa Ķīnā nozīmē laimi, Rietumu tirgos – briesmas vai kļūdu. Zaļi simboli islāma valstīs var būt pozitīvi, bet dažos kontekstos tiek uztverti kā ekskluzīvi. Pārbaudiet, vai ikonas, piemēram, pacelts īkšķis vai ķeksītis, dažādās kultūrās asociējas – Grieķijā pacelts īkšķis ir aizvainojošs. Izmantojiet dzimumneitrālus simbolus (piem., tualetes zīmes kā universālas ikonas) un izvairieties no reliģiskiem vai politiskiem simboliem. Krāsu izvēlē palīdz kultūras ceļvedis: grāmatas, piemēram, „The Culture Map“ vai pakalpojumi, piemēram, Day Translations. Apsveriet iespēju piedāvāt konkrētiem tirgiem pielāgotas tēmas.

Praktisks piemērs: e-komercijas veikals ar pasūtījuma datumu un piegādes laiku Japānas tirgū rāda datumu kā gads-mēnesis-diena (2024年5月12日) un valūtu atbilstoši valstij. UI elementiem, piemēram, CTA pogām, izmantojiet kontrastējošas krāsas, kas darbojas dažādās platformās. Pirms palaišanas testējiet kultūras pielāgojumus fokusa grupās – īpaši ikonas un attēlus. Iekļaujiet šīs pārbaudes kvalitātes nodrošināšanas procesā: katram tirgum definējiet kultūras indikatoru sarakstu (krāsa, simboli, datums, valūta, uzrunas formas) un ļaujiet tos validēt dzimtās valodas runātājiem ar vietējām kultūras zināšanām. Tādējādi nodrošināsiet, ka jūsu lietotne visos 24 tirgos šķiet ne tikai valodiski, bet arī kulturāli pareiza.

Darbplūsmas optimizācija: vienlaicīga lokalizācija abiem veikaliem

Paralēla lokalizācija iOS un Google Play prasa pārdomātu darbplūsmu, kas novērš dublēšanos un nodrošina konsekvenci. Galvenā atslēga ir avota tekstu sinhronizācija: izmantojiet kopīgu satura pārvaldības sistēmu (CMS) vai lokalizācijas platformu, kas apkalpo abas platformas. Glabājiet visus oriģināltekstus neitrālā formātā, piemēram, InDesign Markup vai XLIFF, no kura tiek ģenerēti specifiskie virkņu faili (Localizable.strings iOS, strings.xml Android). Izvairieties manuāli pārnest vienus un tos pašus tulkojumus uz divām sistēmām – tas rada ne tikai dubultu darbu, bet arī neatbilstības.

Efektīva darbplūsma sākas ar kopīgu izlaišanas ciklu. Plānojiet lokalizācijas sprintus paralēli izstrādes cikliem: tiklīdz teksti jaunai versijai ir pabeigti atzarā (feature branch), tie vienlaikus tiek nodoti tulkotājam. Izmantojiet biržas vai versiju numurus, lai saglabātu pārskatu. Praksē ir pierādījies, ka katru nedēļu jāveic virkņu momentuzņēmums un jānosūta lokalizētājiem. Tādējādi jums vienmēr ir aktuāli teksti, neizpildot visu procesu pēc katra commit.

Ņemiet vērā atšķirīgās metadatu prasības veikaliem: kamēr Apple ierobežo nosaukumu un aprakstu līdz 30, 100 un 4000 rakstzīmēm (lietotnes nosaukumam, apakšvirsrakstam, aprakstam), Google Play atļauj 50, 80 un 4000 rakstzīmes. Tāpēc jau laikus nosakiet, kuri teksti ir jāoptimizē platformas specifikai. Praktiska pieeja ir tulkot kopīgu pamattekstu un pēc tam veikt manuālas korekcijas katrai platformai – piemēram, saīsinot vai pārformulējot iOS versijai. Saglabājiet šīs korekcijas atsevišķā kolonnā savā lokalizācijas tabulā.

Visbeidzot, mēs iesakām izveidot kvalitātes nodrošināšanas pārskatu pirms tulkojumu ievietošanas. Uzdodiet dzimtās valodas runātājam pārbaudīt abu platformu ekrānuzņēmumus, lai savlaicīgi atklātu apgriešanu vai lietotāja saskarnes kļūmes. Automātiska salīdzināšana starp iOS un Android versijām (piemēram, ar skriptu salīdzinot virkņu atslēgas) atklāj trūkstošus vai liekus ierakstus. Tādējādi nodrošināsiet, ka jūsu lietotne 24 tirgos ir konsekventa un precīza – bez nepieciešamības veikt divus atsevišķus procesus.

Rīki un automatizācija starpplatformu lokalizācijai

Pareiza rīku izvēle būtiski ietekmē starpplatformu lokalizācijas efektivitāti un kvalitāti. Ieteicams izmantot specializētas lokalizācijas platformas, piemēram, Crowdin, Lokalise vai POEditor, kas apstrādā gan .strings, gan .xml formātus un ar API palīdzību savienojamas ar jūsu CMS. Šie rīki piedāvā tādas funkcijas kā tulkošanas atmiņas (TM), kas atkārtoti izmanto jau tulkotus segmentus – atkārtotiem UI tekstiem, piemēram, „Saglabāt” vai „Atcelt”, tādējādi ietaupot laiku. Praksē TM atjauninājumu laikā bieži vien sedz 30–50% tulkošanas apjoma (atkarībā no teksta stabilitātes).

Darbplūsmas automatizācijai būtiskas ir nepārtrauktā lokalizācija (CL) un nepārtrauktā integrācija (CI). Izveidojiet CI cauruļvada darbu, kas pie katra push uz galveno zaru izvelk avota virknes, nosūta tās tulkošanas platformai un pēc pabeigšanas atjaunina lokālās resursu datnes. Tādējādi tulkojumi vienmēr ir sinhroni bez manuālas iejaukšanās. Izmantojiet tādus rīkus kā Fastlane vai Bitrise, lai automatizētu lokalizēto virkņu izplatīšanu abos veikalos. Fastlane šim nolūkam piedāvā iepriekš konfigurētas darbības (piem., deliver iOS un supply Android), ko var integrēt jūsu cauruļvadā.

Vēl viens elements ir kvalitātes nodrošināšana, izmantojot automatizētus testus. Izmantojiet UI testu ietvarus (XCTests iOS, Espresso Android), kas darbojas ar lokalizētiem testa datiem. Tā pārbaudāt, vai visas virknes ir pareizi iekļautas un pogās vai etiķetēs nav pārāk garu tekstu. Rīki, piemēram, Spoon ekrānuzņēmumu salīdzināšanai vairākās valodās, vizualizē atšķirības un atvieglo izkārtojuma problēmu atrašanu. Turklāt ar skriptiem var pārbaudīt, vai atslēgas ir abās platformās – trūkstošs tulkojums vienā pusē rada robus lietotāja pieredzē.

Izmaksas un licenču modeļi jāaprēķina iepriekš. Minētās platformas parasti piedāvā abonementus, pamatojoties uz avota vārdu skaitu vai izstrādātāju vietām. Mazām komandām ir bezmaksas līmeņi, lielākiem apjomiem parasti ir gada līgumi ar atlaidēm. Ieguldiet platformā, kas atbalsta nativos formātus un piedāvā API CI savienojumam – tas atmaksājas jau pēc dažiem laidieniem, samazinot manuālo darbu un kļūdu risku.

Juridiskie aspekti: datu aizsardzība, impressums un VNN 24 ES valodās

Lai nodrošinātu lietotnes pieejamību 24 ES tirgos, jāievēro dažādas juridiskās prasības – ne tikai ES Vispārīgā datu aizsardzības regula (VDAR), bet arī nacionālie papildinājumi. Katra valsts var izvirzīt savas prasības datu aizsardzības paziņojumam, piemēram, attiecībā uz datu glabāšanas termiņu vai konkrētiem piekrišanas mehānismiem. Turklāt impressums (sniedzēja identifikācija) un Vispārīgie noteikumi un nosacījumi (VNN) jāsniedz attiecīgajā oficiālajā valodā. Jāņem vērā, ka dažās valstīs (piemēram, Beļģijā ar trim oficiālajām valodām) var būt nepieciešamas vairākas valodu versijas.

Juridisko tekstu tulkojumam jābūt ne tikai valodiski precīzam, bet arī juridiski atbilstošam. Lieciet juridiskos dokumentus pārbaudīt specializētam tulkojumam vai juristam, kas pārzina nacionālās tiesības. Neizmantojiet mašīntulkošanu bez galīgas cilvēka kontroles – pat nelielas kļūdas formulējumā strīda gadījumā var padarīt klauzulu spēkā neesošu. Praksē ir ieteicams izveidot juridisko tekstu pamatsetumu (piem., vācu valodā) un likt to pārbaudīt juristiem mērķa tirgos, pirms tiek veikts tulkojums pārējās valodās.

Bieža kļūda praksē ir sīkfailu baneru un piekrišanas dialogu nelokalizēšana. Daudzas lietotnes tos rāda tikai angļu vai sistēmas valodā. ES valstīs lietotāji jāinformē viņu dzimtajā valodā – vismaz par būtiskajiem apstrādes mērķiem. Tāpēc papildiniet savus lokalizācijas failus ar piekrišanas pārvaldības platformu (CMP) tekstiem. Tas pats attiecas uz lietotnē veikto pirkumu norēķiniem: PVN un rēķinu informācija jāpielāgo katrai valstij. Piemēram, Dānijā ir citi mazo uzņēmumu noteikumi nekā Vācijā.

Mēs iesakām pirms palaišanas likt visus juridiskos tekstus pārbaudīt juridiskajam konsultantam attiecīgajās valstīs. Šis ieteikums neaizstāj neatkarīgu juridisku konsultāciju. Plānojiet pietiekami daudz laika šim posmam – saskaņošana ar vairākiem juristiem var aizņemt vairākas nedēļas. Turklāt centralizēti glabājiet savu juridisko tekstu versijas, lai, mainoties tiesību aktiem (piemēram, gaidāmajai ePrivātuma regulai), varētu ātri reaģēt. Regulāra pārskatīšana (piem., reizi gadā vai pēc būtiskiem lietotnes atjauninājumiem) nodrošina pastāvīgu atbilstību un aizsargā pret brīdinājumiem dažādos ES tirgos.

Kontrolsaraksts darbības uzsākšanai vairākos tirgos

Pirms publicējat savu lietotni 24 ES tirgos, jāizstrādā strukturēts kontrolsaraksts, lai izvairītos no tipiskām kļūdām un efektīvi veiktu ieviešanu. Sāciet ar stratēģisko plānošanu: katram mērķa tirgum definējiet attiecīgās valodas, kultūras īpatnības un juridiskās prasības. Izveidojiet prioritāšu sarakstu – ne visiem tirgiem jābūt pieejamiem vienlaikus. Sāciet ar lielākajām mērķauditorijām vai tām, kurām ir visaugstākās ieņēmumu prognozes.

Nākamajā solī seko tehniskā sagatavošana. Pārliecinieties, ka jūsu koda bāze ir pielāgota lokalizācijai: izmantojiet string resursus (Localizable.strings iOS, strings.xml Android) un vietturus dinamiskiem saturiem. Pārbaudiet, vai visi UI elementi atbalsta elastīgus izkārtojumus, īpaši garajiem vācu vai somu tekstiem. Abām platformām jāizveido atsevišķi metadati App Store un Google Play – iekļaujot nosaukumu, īsu aprakstu, pilnu aprakstu un atslēgvārdus. Ņemiet vērā atšķirīgās rakstzīmju robežas (piem., 30 rakstzīmes iOS nosaukumam, 50 Android).

Paralēli tam rūpējieties par juridiskajiem aspektiem. Katram tirgum nepieciešams lokalizēts privātuma paziņojums, kas atbilst VDAR, kā arī lietošanas noteikumi pirkumiem un abonēšanai lietotnē. Likumi šos dokumentus pārbaudīt juridiskajam ekspertam, kas pārzina nacionālos noteikumus. Arī vecuma ierobežojumu marķējums (piem., USK Vācijā, PEGI citās valstīs) jāveic katrā valstī. Neaizmirstiet izpildīt juridiskās informācijas prasību D-A-CH tirgiem.

Kad saturs ir iztulkots un juridiski pārbaudīts, veiciet vairāku posmu testēšanas procesu. Veiciet funkcionālos testus simulatoros un reālās ierīcēs – abās platformās. Pievērsiet uzmanību tekstiem, kas tiek apgriezti, nepareizai rakstzīmju kodēšanai vai netulkotām virknēm. Testējiet arī maksājumu apstrādi: dažās valstīs noteiktas maksājumu metodes (piem., tiešā debeta norakstīšana Vācijā) ir vēlamas. Visbeidzot sagatavojiet veikalu ierakstus: lokalizēti ekrānuzņēmumi ar atbilstošiem tekstiem, lietotnes priekšskatījumi (iOS) un reklāmas grafiki. Pēc tam publicējiet pakāpeniski, lai problēmu gadījumā varētu ātri reaģēt. Pēc palaišanas uzraugiet pirmos lietotāju vērtējumus un pielāgojiet ASO stratēģiju, pamatojoties uz atslēgvārdiem un konversiju rādītājiem.

Nākotnes perspektīva: tendences un nepārtraukta lokalizācija

Lietotņu lokalizācija 24 ES tirgiem nav vienreizējs projekts, bet gan nepārtraukts process. Galvenā tendence ir pieaugošā mākslīgā intelekta izmantošana tulkošanā un kvalitātes nodrošināšanā. Runa nav par cilvēku pārbaudītāju aizstāšanu, bet gan par to atslogošanu: MI atbalstīti rīki var nodrošināt pirmo tulkojumu un pārbaudīt neatbilstības. Praksē ir pierādījies, ka tos ir lietderīgi kombinēt ar dzimtās valodas runātāju korektūru. Arī automatizācija darba plūsmā kļūst arvien svarīgāka: nepārtraukta lokalizācija – tulkojumu iekļaušana CI/CD caurulē – ļauj vienlaikus izlaist atjauninājumus visās valodās.

Vēl viena tendence ir hiperpersonalizēta lokalizācija. Lietotāji sagaida ne tikai valodiski pareizu saturu, bet arī kultūras ziņā pielāgotas funkcijas. Tajā ietilpst vietējie maksājumu veidi (piem., iDEAL Nīderlandē), bezmaksas maksājumu iespējas vai specifiski svētki, kas integrēti lietotnē. Arī veikalu ierakstu dizains tiek arvien vairāk lokalizēts: A/B testi ar dažādiem ekrānuzņēmumiem un aprakstiem atkarībā no tirgus ir izplatīti. Lietotāju atsauksmju analīze attiecīgajās valodās palīdz identificēt vājās vietas.

Nepārtrauktai lokalizācijai ieteicams izmantot tulkošanas pārvaldības sistēmu (TMS), kas ir saistīta ar jūsu izstrādes procesu. Nosakiet regulāru ritmu tulkojumu atjauninājumiem – piemēram, ar katru sprintu vai versiju. Uzturiet glosāriju ar tirgum raksturīgiem terminiem, lai nodrošinātu konsekvenci. Plānojiet arī regulārus esošās lokalizācijas auditus. Jo pat tad, ja lietotne darbojas stabili, juridiskās prasības var mainīties (piem., jauni sīkdatņu likumi) vai mainīties kultūras normas.

Visbeidzot, jums vajadzētu izmērīt lokalizētās lietotnes veiktspēju katrā tirgū. Rādītāji, piemēram, konversijas piltuve, lejupielāžu rādītāji un pirkumi lietotnē pēc valodas, sniedz ieskatu jūsu lokalizācijas efektivitātē. Izmantojiet šos datus, lai pielāgotu savu stratēģiju. Praktisks piemērs: daži tirgi ir jutīgi pret pārāk daudz angļu valodas terminoloģijas lietotāja saskarnē – šeit konsekvents tulkojums var palielināt lietotāju noturību. Nepārtraukta lokalizācija galu galā ir konkurences priekšrocība, kas atmaksājas ar augstāku lietotāju apmierinātību un labākiem veikalu rādītājiem. Tāpēc jau no sākuma plānojiet budžetu un resursus pastāvīgai lokalizācijai.

Biežākās kļūdas un kā tās novērst

Veicot starpplatformu lokalizāciju iOS un Android, pastāv tipiskas kļūdas, kas patērē laiku un budžetu. Bieži sastopama problēma ir atšķirīgi rakstzīmju ierobežojumi: iOS nosaukumi App Store Connect atļauj 30 rakstzīmes lietotnes nosaukumam, savukārt Google Play – 50 rakstzīmes. Ja vispirms tulkojat vienai platformai, otra versija vēlāk var izskatīties nogriezta. To risiniet, jau sākumā ņemot vērā abus ierobežojumus un izstrādājot īsus, zīmola atbilstošus saīsinājumus. Arī UI garumā platformas atšķiras: iOS pogas bieži ir kompaktākas, Android etiķetes – garākas. Izmantojiet elastīgus izkārtojumus ar automātisku teksta pielāgošanu (Auto-Layout iOS, ConstraintLayout Android) un testējiet ar vietturiem, piemēram, „Ļoti garš parauga teksts“.

Vēl viens klupšanas akmens ir virziena atkarības (RTL). Kamēr Android atbalsta RTL caur Manifest, iOS prasa īpašu kontroli. Neaizmirstiet pārbaudīt ikonu atspoguļošanas efektus – piemēram, bultiņa uz labo pusi angļu valodā rāda pareizajā virzienā, arābu valodā tai jārāda pa kreisi. Plānojiet atsevišķus aktīvus vai izmantojiet mērogojamus vektorgrafikas, ko var automātiski atspoguļot.

Juridiskās lamatas izriet no ES valstu prasībām: pienākums norādīt informāciju par izdevēju, privātuma politikas saskaņā ar VDAR un lietošanas noteikumi atšķiras detaļās (piem., minimālās prasības Austrijā pret Vāciju). Lieciet pārbaudīt visus juridiskos tekstus attiecīgajā valstī specializētam juristam. Arī App Store vadlīnijas atšķiras: Apple noraida lietotnes ar nepierādītiem veselības solījumiem, Google dažkārt tās pieļauj ilgāk. Saskaņojiet savu lokalizācijas stratēģiju ar aktuālajām Store vadlīnijām.

Praktisks piemērs: iepirkšanās lietotnē komanda pēc palaišanas 12 tirgos atklāja, ka izmēru norādes (ES, UK, ASV) produktu detaļās nebija vienādi tulkotas. Risinājums bija centrāla konfigurācijas datne ar ISO kodiem un pārrēķinu tabulām. Vēl viena kļūda ir trūkstoši vietturi saliktiem stringiem („%1$s hat %2$d Freunde”) – vācu valodā mainās teikuma struktūra, tāpēc vietturim jābūt elastīgam. Vienmēr testējiet visas valodu versijas īstās ierīcēs, nevis tikai simulatorā.

Šis ceļvedis neaizstāj juridisko konsultāciju; šaubu gadījumā konsultējieties ar speciālistu.

Budžeta plānošana un izmaksas lokalizācijai 24 tirgos

Izmaksu novērtējums starpplatformu lokalizācijai 24 ES valodās ir stipri atkarīgs no apjoma, rīkiem un kvalitātes prasībām. Aprēķiniet trīs galvenos blokus: tulkošana un lokalizācija, tehniskā pielāgošana un testēšana. Vienai valodai tīra teksta tulkošanas izmaksas (ap 5 000–10 000 vārdu) ir aptuveni 0,10–0,25 € par vārdu atkarībā no valodu kombinācijas un specializācijas. Pieskaitiet piemaksu par UI pielāgošanu (ap 20–30 %) un kultūras optimizāciju (valūtas, formāti). 24 valodām ir jēgpilni rīkoties pakāpeniski: sāciet ar 5–8 pamatvalodām (piem., vācu, franču, spāņu, itāļu, nīderlandiešu, poļu) un pakāpeniski izvērsiet, lai saudzētu naudas plūsmu.

Tehniskās izmaksas rodas, izveidojot attīstības zarus lokalizētiem aktīviem, pielāgojot virkņu datnes un vietturus. Atvēliet 10–20 % izstrādātāju budžeta internacionalizācijai (i18n), pirms sākas pirmais tulkojums. Pēc tam seko tulkoto virkņu integrācija, kas pieredzējušam izstrādātājam parasti prasa 1–2 dienas vienai valodai – atkarībā no sarežģītības (RTL, daudzskaitļa noteikumi).

Testēšana ir nepietiekami novērtēts izmaksu virzītājs: katra valodas versija jātestē vismaz vienā fiziskā ierīcē katrai platformai. Viens testa cikls vienai valodai testētājam maksā ap 50–100 €. Apkopojiet bieži sastopamos ekrānus (pieslēgšanās, maksājumi) un lieciet dzimtās valodas runātājiem pārbaudīt arī metadatus (App Store apraksts, atslēgvārdi). Ar automatizāciju (piem., lokalizētas būves ar Bitrise vai GitHub Actions) samaziniet testēšanas izmaksas, bet nekad neaizstājiet izlases testus ar reāliem lietotājiem.

Bieži iebildumi: „Vai ir vērts ieguldīt pūles maziem tirgiem, piemēram, igauņu vai maltiešu valodā?“ Aprēķiniet potenciālos ieņēmumus: Maltā dzīvo ap 500 000 cilvēku, bet daudzi runā angliski. Izvērtējiet, vai lokalizācija šajā valodā sniedz vairāk lejupielāžu nekā izmaksas. Pieņemiet lēmumu, pamatojoties uz datiem: izmantojiet valstu datus no esošajiem lietotnes analītikas datiem. Praksē lokalizācija atmaksājas, sākot no 10 000 potenciāliem jauniem lietotājiem katrā tirgū, ja jūsu lietotne sniedz skaidru pievienoto vērtību.

Paturiet prātā arī pastāvīgās izmaksas: atjauninājumi prasa atkārtotus tulkojumus (ap 10–15 % no sākotnējiem tekstiem vienā laidienā). Paturiet rezervi 20 % apmērā no gada budžeta negaidītām izmaiņām (piem., jaunas VDAR prasības). Lieciet pieredzējušam pakalpojumu sniedzējam izstrādāt individuālu piedāvājumu, pamatojoties uz jūsu konkrēto lietotni un tirgus prioritātēm.