Kada tinkamiausias metas pradėti lokalizavimo darbus?

„Lokalizuosime, kai produktas atitiks rinką.“ Šis vienas sakinys programinės įrangos įmonėms kainuoja vidutiniškai 23–42 % jų kūrimo pastangų ir 6–18 mėnesių atitolina pasaulinį paleidimą. Paslėptos išlaidos yra ne vertimas, o techninė skola, kurią šiandien dedate į kiekvieną kodo eilutę.

Žiauri matematika: statyba dabar ar renovacija vėliau

• 5–7 kartus – lokalizacijos modernizavimo ir įrengimo sąnaudų daugiklis
• 23–42 % – dėl vėluojančio lokalizavimo sugaištas kūrimo laikas dėl technologijų skolos
• 6–18 mėnesių – vidutinis vėlavimas patekti į pasaulinę rinką, kai lokalizuojama po paleidimo

Remiantis „McKinsey“ ir Lokalizacijos pramonės standartų asociacijos tyrimais, organizacijos iššvaisto nuo 23 % iki 42 % savo kūrimo pastangų spręsdamos technines skolas. Kai lokalizacija laikoma antraeiliu dalyku, ši skola didėja eksponentiškai.

Štai ką tai reiškia praktiškai: jei jūsų komanda 3 mėnesius kurs funkciją su užprogramuotomis eilutėmis, išdėstymo prielaidomis ir lokalizacijos nejautriu formatavimu, jums prireiks 15–21 mėnesio, kad ją išnarpliotumėte, kai nuspręsite ją diegti visame pasaulyje. Tai neįskaitant vertimo laiko – tai tik inžinerinis darbas, kad jūsų kodo bazė būtų lokalizuojama.

Techninis skolos santykis, kuris lemia jūsų likimą

Techninis skolos rodiklis (TDR) matuoja kodo bazės taisymo kainą, palyginti su jos sukūrimo nuo nulio kaina. Pramonės duomenys rodo, kad didesnis nei 5 % TDR rodo, jog reikia skubių veiksmų. Įmonėms, kurios atidėlioja internacionalizaciją, su lokalizacija susijęs TDR dažnai viršija 40 %.

Realus pavyzdys: „SaaS“ startuolis, turintis 50 000 kodo eilučių ir užkoduotas angliškas eilutes, apskaičiavo, kad „vertimams pridėti“ prireiks 2 savaičių. Faktinės kūrėjų pastangos užtruko 6 mėnesius, kol buvo išverstos eilutės į išorę, ištaisytos netinkamos maketų konfigūracijos, įdiegtas lokalizaciją atitinkantis formatavimas ir išspręstos kraštutinės problemos. Kaina: maždaug 180 000 USD inžinerijos laiko. Jei jie būtų kūrę atsižvelgdami į internacionalizaciją nuo pirmos dienos, papildomos išlaidos būtų buvusios apie 25 000 USD.

Idealus momentas pradėti: prieš rašant pirmą eilutę

Tyrimas vienareikšmis. Įmonės, kurios nuo pat pradžių integruoja lokalizaciją, juda greičiau, išleidžia mažiau ir užima pasaulines rinkas, o konkurentai vis dar pertvarko savo kodų bazes.

Internacionalizacija (i18n): Jūsų fondas

Internacionalizavimas – tai programinės įrangos kūrimas taip, kad ji būtų pritaikyta kelioms kalboms ir regionams, nereikalaujant inžinerinių pakeitimų. Tai ne jūsų pridėta funkcija – tai mąstysena, kurią perimate nuo pat architektūros pradžios.

Pagrindiniai „i18n“ principai (įsikurkite juos nuo pirmos dienos):

• Viso naudotojui matomo teksto perkėlimas į išorinį formatą: niekada neužkoduokite eilučių šaltinio kode. Naudokite išteklių failus (JSON, YAML, XLIFF), kurie atskiria turinį nuo logikos.
• Unikodas visur: Palaikomi dvibaičiai simboliai, iš dešinės į kairę rašomi raštai (arabų, hebrajų) ir sudėtingi raštai (tajų, devanagari).
• Lokalę atitinkantis formatavimas: datos, laikas, skaičiai, valiutos ir vienetai turi dinamiškai prisitaikyti prie vartotojo lokalės.
• Lankstūs vartotojo sąsajos išdėstymai: vokiečių kalbos tekstas išsiplečia 30 %, palyginti su anglų kalbos tekstu. Japonų kalbos tekstas susitraukia. Jūsų vartotojo sąsaja turi atlaikyti teksto išplėtimą / susitraukimą be jokių trikdžių.
• Venkite sujungtų eilučių: „Jūs turite „ + count + „ messages“ pertraukas kalbose su skirtingomis gramatikos taisyklėmis. Vietoj jų naudokite parametrines eilutes.
• Dvikryptis dizainas: jūsų maketas turėtų palaikyti teksto vaizdavimą tiek iš kairės į dešinę, tiek iš dešinės į kairę be jokio pertvarkymo.

// BAD - Hardcoded, will break in other languages
const greeting = "Hello, " + userName + "!";
const message = "You have " + count + " new messages";

// GOOD - Externalized, parameterized, localizable
const greeting = i18n.t('greeting', { name: userName });
const message = i18n.t('message_count', { count: count });

Keturi laiko veiksniai: kai lokalizacija tampa neatidėliotina

Nors idealus atsakymas yra „nuo pat pradžių“, yra konkrečių momentų, kai lokalizacija pasikeičia iš „malonu turėti“ į „egzistencinę būtinybę“.

1-as veiksnys: netikėtas tarptautinis eismas

Patikrinate „Google Analytics“ ir pastebite, kad 15–30 % jūsų srauto ateina iš rinkų, į kurias nesate orientuoti. Šie vartotojai jus randa, tačiau jūsų konversijų rodiklis tose rinkose yra 60–80 % mažesnis nei jūsų namų rinkoje.

Veiksmas: Tai patvirtinimas, kad paklausa egzistuoja. Jei delsite lokalizuoti, konkurentai tose rinkose sukurs lokalizuotas alternatyvas ir pasinaudos jūsų atrasta galimybe.

2 veiksnys: pasiektas produkto atitikimas rinkai

Radote tinkamą produktą savo pradinėje rinkoje. Išlaikymas yra stiprus, klientų praradimas mažas, o vartotojai domisi jūsų produktu. Dabar tinkamas metas plėstis, o ne po šešių mėnesių.

Veiksmas: pradėti kurti nuolatinio lokalizavimo infrastruktūrą dabar. Tokios įmonės kaip „Notion“ laukė, kol pastebės dideles vartotojų bendruomenes Japonijoje ir Korėjoje, o tada greitai lokalizavo. Šiandien 70 % „Notion“ vartotojų yra už JAV ribų.

3 veiksnys: lėšų rinkimo arba pajamų etapai

Pritraukėte reikšmingą investicijų ratą arba pasiekėte pajamų etapą, kuriam pasiekti reikalingas spartesnis augimas. Investuotojai tikisi tarptautinės plėtros. Lokalizacijos atidėjimas stabdo šį augimą.

Veiksmas: Prieš plečiant pardavimus ir rinkodarą naujose rinkose, 15–20 % inžinerinių išteklių skirti „i18n“ infrastruktūros kūrimui.

4 veiksnys: konkurencinis spaudimas

Konkurentas pagrindinėse rinkose pristatė lokalizuotas versijas ir įgauna pagreitį. Jų lokalizuotas produktas pritraukia naudotojų, kuriuos galėjote pritraukti.

Veiksmas: Tai brangiausias paleidiklis. Dabar modifikuojate spaudžiami laiko, todėl išlaidos padidėja 8–10 kartų, palyginti su „i18n“ kūrimu nuo pat pradžių.

Agile lokalizacijos sistema: sprintas, o ne kriokliai

Tradicinis metodas – viską sukurti, o tada viską išversti – yra pasenęs. Šiuolaikinis programinės įrangos kūrimas naudoja lanksčius sprintus. Jūsų lokalizavimo darbo eiga turi atitikti šį tempą arba tapti kliūtimi, kuri stabdo pasaulinį greitį.

Nuolatinė lokalizacija: ką ji iš tikrųjų reiškia

Nuolatinis lokalizavimas integruoja vertimo darbo eigas į lanksčius kūrimo ciklus, todėl lokalizuotos versijos išleidžiamos vienu metu su šaltinio kalbos leidimais. Užuot vertimas buvęs nuolatiniu poleidimo procesu, tai lygiagretus procesas, integruotas į kiekvieną sprintą.

Kaip tai veikia praktiškai:

1. Sprinto planavimas (0 savaitė): Iš anksto nustatomi lokalizacijos reikalavimai. Produktų vadovai ir lokalizacijos komandos sutaria, kokį turinį reikia versti ir kurioms rinkoms teikiama pirmenybė.
2. Kūrimas (1–2 savaitės): kūrėjai kuria funkcijas naudodami išorines eilutes. Kai naujas turinys įtraukiamas į kodo bazę, jis automatiškai išgaunamas ir siunčiamas į vertimo valdymo sistemas (TMS).
3. Vertimas (lygiagretus procesas): Kol kūrėjai tęsia kodavimą, vertėjai dirba su naujomis eilutėmis. Kontekstas pateikiamas ekrano kopijomis, vartotojo sąsajos aprašymais ir kūrėjų komentarais.
4. QA integracija (2 savaitė): išverstos eilutės sujungiamos atgal į kodo bazę. Lingvistinis QA atliekamas kartu su funkciniu QA. Testuotojai tikrina vartotojo sąsajos pertraukas, teksto perpildymą ir kontekstinį tikslumą.
5. Diegimas (2 savaitės pabaiga): Visų kalbų versijos diegiamos vienu metu. Anglų, vokiečių, japonų ir ispanų kalbų versijos pradedamos naudoti kartu, o ne paeiliui.

Sprinto planavimas lokalizacijai: trūkstama dalis

Dauguma kūrimo komandų planuoja sprintus neatsižvelgdamos į lokalizaciją iki paskutinės minutės. Tai sukelia chaosą. Štai kaip našiai dirbančios komandos integruoja lokalizaciją į sprinto planavimą:

1. Apibrėžkite lokalizaciją kaip „Atlikto apibrėžimo“ dalį.

Funkcija nelaikoma užbaigta, kol ji neišbandoma visomis tikslinėmis kalbomis. Dėl to komandos, apskaičiuodamos sprinto rezultatus, turi atsižvelgti į lokalizavimo laiką.

2. Kurkite lokalizacijos naudotojų istorijas

Lokalizaciją traktuokite kaip vartotojo istoriją: „Kaip vokiečių kalbos vartotojas, man reikia, kad visi vartotojo sąsajos elementai būtų išversti, kad galėčiau naudoti produktą savo gimtąja kalba.“ Priskirkite istorijos taškus ir sekite greitį.

3. Įtraukite lokalizacijos komandas į sprinto planavimo susitikimus

Lokalizacijos vadovai dalyvauja sprinto planavimo procese, kad nustatytų vertimo apimtį, pažymėtų sudėtingas eilutes ir suderintų terminus. Tai padeda išvengti netikėtumų.

4. Automatizuokite turinio išgavimą ir pateikimą

Naudokite CI/CD integracijas, kurios automatiškai išgauna naujas eilutes iš „Git“ pakeitimų ir nukreipia jas vertėjams. Rankinis perdavimas el. paštu arba skaičiuoklėmis yra kliūtys, stabdančios Agile greitį.

5. Vertimo buferių kūrimas sprinto metu

Ne kiekvienas sprintas reikalauja daug vertimo darbų. Kai kurie sprintai sutelkia dėmesį į darbą su serverio sąsaja ir minimalius vartotojo sąsajos pakeitimus. Naudokite šiuos sprintus, kad padengtumėte vertimo skolas arba patobulintumėte esamus vertimus.

Komandos struktūra: kas iš tikrųjų atlieka lokalizaciją?

Lokalizavimas nėra vieno žmogaus darbas. Jam reikalingas tarpfunkcinis bendradarbiavimas tarp kūrėjų, produktų vadovų, techninių rašytojų, vertėjų ir kokybės užtikrinimo testuotojų. Štai ideali komandos struktūra:

Lokalizacijos komandos dydžio klausimas

Kiek žmonių jums iš tikrųjų reikia? Tai priklauso nuo jūsų plėtros greičio ir rinkos ambicijų:

• Ankstyvasis etapas (prieš PMF): 0-1 lokalizacijos specialistas. Kūrėjai dirba su i18n architektūra. Vertimo darbams naudoja TMS platformas su integruotais vertėjų tinklais.
• Po PMF (2–5 kalbos): 1 lokalizacijos vadovas + išoriniai vertimo paslaugų teikėjai. Vadovas koordinuoja darbo eigą, valdo TMS ir užtikrina kokybę.
• Skalės etapas (5–15 kalbų): 1–2 lokalizacijos vadovai + specializuoti lingvistai pagrindinėms rinkoms + išoriniai tiekėjai ilgo vertimo kalboms. Apsvarstykite galimybę samdyti recenzentus iš šalies.
• Įmonės (daugiau nei 15 kalbų): Visapusiška lokalizavimo komanda su regiono vadovais, įmonės lingvistais, kokybės užtikrinimo specialistais ir lokalizavimo inžinieriais.

Techninio rašytojo vaidmuo: rašymas lokalizacijai

Techniniai rašytojai yra negirdėti efektyvaus lokalizavimo herojai. Aiškiai originalo kalba parašytas turinys verčiamas greičiau, tiksliau ir pigiau.

Lokalizacijai pritaikyto rašymo gairės:

• Naudokite paprastą, tiesmukišką kalbą: venkite idiomų, kultūrinių nuorodų ir sudėtingų sakinių struktūrų. „Spustelėkite mygtuką“ verčia geriau nei „Paspauskite mygtuką, kad pradėtumėte procesą“.
• Nuosekliai vartokite terminologiją: visur vartokite tą patį terminą tai pačiai sąvokai. Nekaitaliokite žodžių „ištrinti“, „pašalinti“ ir „išmesti į šiukšliadėžę“. Pasirinkite vieną.
• Sakiniai turi būti trumpi: po vieną mintį kiekviename sakinyje. Ilgi, sudėtiniai sakiniai su keliomis šalutinėmis dalimis yra vertimo košmarai.
• Venkite humoro ir žodžių žaismo: kalambūrai, pokštai ir išradingi žodžių žaismai retai kada išverčiami. Jie verčia vertėjus rinktis tarp pažodinio vertimo (prarandamas pokštas) ir kūrybiško pritaikymo (kelia riziką).
• Dokumento kontekstas vertėjams: pridėkite komentarus, paaiškinančius, kur rodomos eilutės, ką jos daro ir kokie yra apribojimai (simbolių apribojimai, tono reikalavimai).
• Kurkite ir tvarkykite žodynėlius: vieną kartą apibrėžkite pagrindinius terminus. Užtikrinkite, kad vertėjai naudotų nuoseklius konkretaus produkto terminijos vertimus.

Realios sėkmės istorijos: įmonės, kurios tinkamai pasirinko laiką

Sąvoka: lokalizuotas ankstyvas, užfiksuotas pasaulinis augimas

„Notion“ pastebėjo netikėtą augimą Japonijoje ir Korėjoje – rinkose, į kurias jie nebuvo orientuoti. Užuot laukę, jie greitai lokalizavo savo produktus, kai tik jie atitiko rinką. Jie jau turėjo „Contentful“ turinio valdymui, todėl integracija su „Smartling“ truko vos savaitę.

Šiandien „Notion“ palaiko 19 kalbų ir dialektų, o maždaug 70 % vartotojų yra už JAV ribų. Ankstyvosios lokalizacijos investicijos nuo pat pradžių leido jai tapti pasauliniu produktu, o ne plėstis JAV produktu.

Airbnb: lokalizacija kaip konkurencinė strategija

„Airbnb“ kreipėsi į Kiniją žinodama, kad susiduria su aršia vietine konkurencija (Tujia, Xiaozhu) ir griežtomis reguliavimo kliūtimis. Jų lokalizacijos strategija apėmė daugiau nei vertimą:

• Pervadintas į „Aibiying“ (爱彼迎): reiškia „pasveikinti vienas kitą su meile“ – kultūriškai skambus, ne tik fonetiškai panašus.
• Integruoti „WeChat“ ir „Alipay“: Kinijos vartotojai nenaudoja kreditinių kortelių mokėjimams internetu. „Airbnb“ pritaikė mokėjimo infrastruktūrą prie vietos gyventojų elgesio.
• Pertvarkyta vartotojo sąsaja pagal kinų pageidavimus: pakeista terminologija iš „šeimininko“ ir „svečio“ į „namų partneris“ ir „trumpalaikis nuomininkas“, kad atitiktų kultūrinius lūkesčius.
• Lokalizuoti skelbimų aprašymai: pakeista nuo „prabangių patogumų“ prie „jaukaus apgyvendinimo“ ir „autentiškos vietinės patirties“ – to, ko iš tikrųjų ieško Kinijos keliautojai.

Rezultatas: 700 % Kinijos klientų bazės augimas per metus po lokalizacijos.

„Spotify“: kultūrinė lokalizacija, ne tik vertimas

„Spotify“ pristatymas Indijoje rodo, kad lokalizacija apima produkto pritaikymą, o ne tik kalbos vertimą:

• Kelių kalbų palaikymas: hindi, tamilų, pandžabų ir kitos kalbos integruotos tiesiai į programėlę – ne kaip viena „indiška“ versija, o kaip atskiros lokalizuotos patirtys.
• Lokalizuoti grojaraščiai: sukurti regionui būdingi muzikos atradimo algoritmai, kurie suprato vietinius atlikėjus, žanrus ir klausymosi įpročius.
• Kainodaros pritaikymas: pristatyti įperkami planai, atitinkantys vietos perkamąją galią, o ne tik USD konvertavimas į INR.

„Spotify“ nelaukė, kol turės „pakankamai“ Indijos vartotojų, kad pateisintų lokalizaciją. Jie lokalizavo pirmiausia tam, kad pritrauktų šiuos vartotojus.

Išlaidų suskirstymas: kiek iš tikrųjų išleisite

Pakalbėkime apie realius skaičius. Kiek iš tikrųjų kainuoja lokalizavimas, kai jį atliekate teisingai nuo pat pradžių, palyginti su vėlesniu modifikavimu?

Išvada: Tipinio SaaS produkto, turinčio 100 000 kodo eilučių ir 10 000 verčiamų tekstų, sukūrimas nuo pirmos dienos kainuoja maždaug 30 000–50 000 USD papildomo inžinerijos laiko. To paties produkto modernizavimas po paleidimo kainuoja 200 000–500 000 USD inžinerijos, vertimo, kokybės užtikrinimo ir vėluojančių pajamų galimybių.

Dažni prieštaravimai (ir kodėl jie neteisingi)

“Mes net nežinome, ar mūsų produktas bus sėkmingas mūsų vidaus rinkoje.”

Tai yra dažniausias prieštaravimas, pagrįstas klaidinga prielaida: kad „i18n“ yra brangios išlaidos, kurios atsiperka tik tuo atveju, jei veikiate pasauliniu mastu.

Realybė: Kūrimas naudojant „i18n“ nuo pirmos dienos kainuoja 10–15 % papildomo kūrimo laiko. Tai maždaug viena papildoma diena per dviejų savaičių sprinto projektą. Eilučių išskyrimo disciplina, lokalizaciją atitinkančio formatavimo naudojimas ir lanksčių išdėstymų kūrimas iš tikrųjų pagerina kodo kokybę, net jei niekada nelokalizuojate. Taip išvengiama kietojo kodo prielaidų, sukuriama modulinė architektūra ir sukuriamas lengvai prižiūrimas kodas.

Tikrasis klausimas yra ne „Ar mes tapsime pasauliniu?“, o „Ar galėsime sau leisti atnaujinti visą savo produktą, kai tai padarysime?“

„Lokalizacija gali palaukti, kol šiose rinkose turėsime mokančių klientų.“

Tai sukuria vištos ir kiaušinio problemą. Tarptautinėse rinkose klientai yra mažiau linkę konvertuoti, jei jūsų produktas nėra lokalizuotas. Jūsų konversijų rodiklis šiose rinkose bus 60–80 % mažesnis nei jūsų vietinėje rinkoje, todėl galite daryti išvadą, kad „paklausa nepakanka“.

Tačiau ta maža paklausa yra prastos lokalizacijos, o ne tikro rinkos abejingumo, artefaktas. Tinkamai lokalizavus, tos „mažos paklausos“ rinkos dažnai pranoksta jūsų pradines prielaidas.

„CSA Research“ nustatė, kad 76 % internetinių vartotojų renkasi pirkti produktus su informacija jų gimtąja kalba. Jei jūsų produktas nėra lokalizuotas, jūs nematuojate tikros paklausos – jūs vertinate toleranciją produktams, pateikiamiems tik anglų kalba.

„Mes tiesiog naudosime „Google“ vertėją ir vėliau viską sutvarkysime.“

Mašininis vertimas labai patobulėjo, tačiau jis nepakeičia tinkamos lokalizavimo strategijos. Štai kodėl:

• Kontekstas svarbus: „Bankas“ gali reikšti finansų įstaigą arba „River Edge“. MT nesupranta konteksto be mokymų.
• Kultūrinis pritaikymas nėra vertimas: mokėjimo būdų lokalizavimas, spalvų schemų koregavimas ir vartotojo sąsajos srautų pritaikymas nėra tai, ką atlieka mašininis apdorojimas.
• Prekės ženklo balsas pasimeta: mašininė programinė įranga kuria funkcionalų tekstą, o ne patrauklų tekstą, kuris išlaikytų jūsų prekės ženklo asmenybę.
• Teisinį ir norminį turinį turi peržiūrėti žmogus: paslaugų teikimo sąlygos, privatumo politika ir atitikties dokumentai turi būti teisiškai tikslūs. MT klaidos užtraukia atsakomybę.

Nepaisant to, mašininis vertimas (MT) yra vertingas pradiniams juodraščiams, vartotojų sukurto turinio vertimui ir žemo prioriteto turiniui. Tačiau jis turėtų būti darbo eigos, apimančios žmogaus peržiūrą, dalis, o ne profesionalios lokalizacijos pakaitalas.

Jūsų lokalizacijos pasirengimo kontrolinis sąrašas

Naudodami šį kontrolinį sąrašą nustatykite, ar esate pasiruošę pradėti lokalizaciją (arba ar pirmiausia reikia sukurti i18n infrastruktūrą):

Infrastruktūros parengtis:

• Visos naudotojui skirtos eilutės yra išoriškai įtrauktos į išteklių failus (neįprogramuotos)
• Kodas palaiko Unicode ir teisingai apdoroja kelių baitų simbolius
• Datos, laiko, skaičių ir valiutos formatavimas naudoja lokalizaciją atitinkančias bibliotekas
• UI išdėstymai tvarko teksto išplėtimą / susitraukimą (išbandyta su vokiečių ir japonų kalbomis)
• Įdiegtas (arba suprojektuotas) kalbų, rašomų iš dešinės į kairę, palaikymas.
• Vengiama eilučių sujungimo (vietoj to naudojamos parametrizuotos eilutės)
• Vertimo valdymo sistema (TVS) pasirinkta arba vertinama

Komandos pasirengimas:

• Kūrėjai supranta i18n principus ir yra apmokyti geriausios praktikos
• Paskirtas lokalizacijos vadovas arba atsakingas asmuo
• Vertimo paslaugų teikėjai arba įmonės lingvistai yra atrenkami tikslinėms rinkoms.
• Techniniai rašytojai kuria lokalizacijai pritaikytą turinį
• Kokybės užtikrinimo procesas apima vartotojo sąsajos trikdžių testavimą lokalizuotose versijose
• Sprinto planavimas apima lokalizaciją kaip „Atlikimo apibrėžimo“ dalį.

Strategijos parengtis:

• Tikslinės rinkos prioritetizuojamos pagal srauto duomenis, rinkos dydį ir konkurenciją.
• Biudžetas skirtas vertimui, įrankiams ir galimam įdarbinimui
• Apibrėžti sėkmės rodikliai (konversijų rodikliai, aktyvavimas, išlaikymas pagal rinką)
• Tikslinėms rinkoms tiriami teisiniai ir atitikties reikalavimai
• Produkto atitikimas rinkai patvirtintas bent vienoje rinkoje

Laiko paradoksas

Geriausias laikas pradėti lokalizavimą buvo tada, kai parašėte pirmąją kodo eilutę. Antras geriausias laikas yra dabar – prieš rašant kitą kodo eilutę.

Kiekviena diena, kai atidėliojate „i18n“ infrastruktūros kūrimą, yra dar viena techninės skolos kaupimo diena. Kiekviena užkoduota eilutė yra dar viena eilutė, kurią reikės išnarplioti. Kiekvienas maketas, kuriame numatytas angliško teksto ilgis, yra dar vienas maketas, kurį reikės perkurti.

Įmonės, kurios laimi pasaulines rinkas, nėra tos, kurios turi geriausius vertimo biudžetus. Jos yra tos, kurios lokalizaciją įtraukia į savo DNR nuo pirmos dienos, todėl, kai Tokijuje, San Paule ar Berlyne pasitaiko galimybė, jos yra pasirengusios atsakyti vietine kalba.

Veiksmų planas: ką daryti šią savaitę

Jei skaitote tai ir suprantate, kad atidėliojote lokalizaciją, štai ką reikia daryti nedelsiant:

Jei dar nepradėjote kūrimo:

1. i18n architektas nuo pirmos dienos: rinkitės sistemas su integruotu i18n palaikymu („React Intl“, „i18next“ ir kt.).
2. Prieš pirmąjį pakeitimų projektą nustatykite TMS: tokios platformos kaip „Lokalise“, „Crowdin“ ar „Phrase“ tiesiogiai integruojasi su „GitHub“.
3. Nedelsiant išorinti visas eilutes: kiekviena vartotojo sąsajos eilutė, klaidos pranešimas ir patarimas patenka į išteklių failus, o ne į šaltinio kodą.
4. Dokumentuokite savo lokalizacijos strategiją: net jei pradedate veiklą tik vienoje rinkoje, dokumentuokite, kaip plėsitės į kitas.

Jei esate vidutinio vystymosi etape:

1. Patikrinkite savo kodo bazę: nustatykite visas užkoduotas eilutes. Teikite pirmenybę išorinėms eilutėms vartotojams skirtose funkcijose.
2. Sukurkite refaktoringo veiksmų planą: per ateinančius 3–6 mėnesius 20 % sprinto greičio skirkite i18n infrastruktūrai.
3. Pradėkite nuo naujų funkcijų: visos naujos funkcijos turi atitikti i18n standartą. Tai padės išvengti papildomų skolų, kol grąžinsite esamas skolas.
4. Testas su pseudolokalizacija: generuokite netikrus vertimus su simbolių išplėtimu, kad rastumėte vartotojo sąsajos pertraukas prieš tikrąjį vertimą.

Jei jau paleidote:

1. Kiekybiškai įvertinkite techninę skolą: įvertinkite pastangas, reikalingas norint lokalizuoti savo kodo bazę. Būkite sąžiningi dėl kainos.
2. Prioritetuokite rinkas pagal esamą srautą: „Google Analytics“ sistemoje ieškokite rinkų, kuriose sulaukiate organinio srauto, net jei nėra lokalizacijos.
3. Vykdykite bandomąjį projektą su viena rinka: pasirinkite didelį potencialą turinčią rinką ir atlikite visišką lokalizacijos bandomąjį projektą. Tai atskleis visus paslėptus iššūkius.
4. Suinteresuotosioms šalims nurodykite realius terminus: lokalizacijos atnaujinimas trunka 6–18 mėnesių, o ne 2 savaites. Lūkesčius nustatykite anksti.

Išvada: sprendimas, apibrėžiantis jūsų ateitį pasaulyje

Dabar suprantate tikrąją lokalizavimo atidėliojimo kainą. Klausimas ne tas, ar lokalizuoti, o tas, ar viską sukursite teisingai nuo pat pradžių, ar vėliau mokėsite 5–7 kartus daugiau už modernizavimą.

Kiekvieną funkciją, kurią pristatote be „i18n“ infrastruktūros, turėsite atkurti. Kiekvieną rinką, į kurią atidedate įėjimą, užims konkurentai.

Protingiausi įkūrėjai lokalizacijos nelaiko augimo mokesčiu. Jie ją mato kaip pagrindą, leidžiantį pasaulinį augimą.