Millal on ideaalne hetk lokaliseerimistööde alustamiseks?

“Lokaliseerime pärast toote turu sobivust.” See üksainus lause maksab tarkvaraettevõtetele keskmiselt 23–42% nende arendustegevusest ja lükkab ülemaailmsed turuletoomist 6–18 kuud edasi. Varjatud kulu ei ole tõlkimine – see on tehniline võlg, mille te täna igasse koodireale lisate.

Jõhker matemaatika: kohe ehitamine vs hiljem ümberehitamine

• 5-7x – lokaliseerimise tagantjärele paigaldamise ja sisseehitamise kulukordaja
• 23–42% – arendusaeg, mis raisatakse viivitatud lokaliseerimise tõttu tehnoloogilisele võlale
• 6–18 kuud – keskmine viivitus globaalsele turule sisenemisel lokaliseerimisel pärast käivitamist

McKinsey ja lokaliseerimistööstuse standardite assotsiatsiooni uuringute kohaselt raiskavad organisatsioonid 23–42% oma arendustegevusest tehniliste võlgade lahendamisele. Kui lokaliseerimist käsitletakse tagantjärele, suureneb see võlg eksponentsiaalselt.

See tähendab, mida see tegelikkuses tähendab: kui teie meeskond kulutab 3 kuud kõvakodeeritud stringide, paigutuse eelduste ja lokaadi suhtes mittetundliku vormingu funktsiooni loomisele, kulub teil selle lahtiharutamiseks 15–21 kuud, kui otsustate globaalseks muutuda. See ei sisalda tõlkeaega – see on lihtsalt inseneritöö, mis muudab teie koodibaasi lokaliseeritavaks.

Tehniline võlgade suhe, mis määrab teie saatuse

Tehnilise võla suhe mõõdab koodibaasi parandamise kulusid võrreldes selle nullist loomise kuludega. Tööstusharu andmed näitavad, et üle 5% TDR näitab kiireloomuliste meetmete võtmist. Ettevõtete puhul, kes viivitavad rahvusvahelistumist, ületab lokalisatsioonipõhine TDR sageli 40%.

Reaalne näide: SaaS-i käivitamine 50 000 koodirea ja kõvakoodiga ingliskeelsete stringidega, mille “tõlgete lisamiseks” kulub hinnanguliselt kaks nädalat. Tegelik pingutus võttis arendajal 6 kuud aega stringide välistamiseks, katkiste paigutuste parandamiseks, lokaaditeadliku vormingu rakendamiseks ja servajuhtumite lahendamiseks. Maksumus: umbes 180 000 dollarit inseneriajal. Kui nad oleksid esimesest päevast peale rahvusvahelistumist ehitanud, oleks lisakulu olnud umbes 25 000 dollarit.

Ideaalne hetk alustamiseks: enne esimese rea kirjutamist

Uuring on ühemõtteline. Ettevõtted, mis integreerivad lokaliseerimist algusest peale, liiguvad kiiremini, kulutavad vähem ja vallutavad globaalseid turge, samal ajal kui konkurendid oma koodibaase veel ümber kujundavad.

Rahvusvahelistumine (i18n): teie sihtasutus

Rahvusvahelistumine on teie tarkvara kujundamine nii, et see kohaneks mitme keele ja piirkonnaga, ilma et oleks vaja tehnilisi muudatusi. See ei ole funktsioon, mille lisate – see on mõtteviis, mille võtate kasutusele arhitektuuri nullpäevast.

Core i18n põhimõtted (ehitage need esimesest päevast peale):

• Eksternaliseerige kogu kasutajale suunatud tekst: Ärge kunagi kasutage lähtekoodis kõvakoodi stringe. Kasutage ressursifaile (JSON, YAML, XLIFF), mis eraldavad sisu loogikast.
• Unicode kõikjal: Toetage kahebaidiseid märke, paremalt vasakule kirjutamissüsteeme (araabia, heebrea) ja keerulisi kirjutamissüsteeme (tai, devanagari).
• Lokaaditeadlik vorming: kuupäevad, kellaajad, numbrid, valuutad ja ühikud peavad kasutaja lokaadi alusel dünaamiliselt kohanduma.
• Paindlikud kasutajaliidese paigutused: saksakeelne tekst laieneb ingliskeelsega võrreldes 30%. Jaapani tekst muutub lühemaks. Teie kasutajaliides peab käsitlema teksti laiendamist/kokkutõmbumist ilma katkestusteta.
• Vältige aheldatud stringe: “Teil on ” + loendus + ” sõnumite katkestused keeltes, kus kehtivad erinevad grammatikareeglid. Kasutage selle asemel parameetritega stringe.
• Kahesuunalisuse kujundus: teie paigutus peaks toetama nii vasakult paremale kui ka paremalt vasakule suunatud teksti renderdamist ilma ümberkujundamata.

// 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 });

Neli ajastuspäästikut: kui lokaliseerimine muutub kiireloomuliseks

Kuigi ideaalne vastus on “algusest peale”, on konkreetseid hetki, mil lokaliseerimine nihkub “tore, et-olla” asemel “eksistentsiaalne vajalikkus”.

Päästik 1: Ootamatu rahvusvaheline liiklus

Kontrollite Google Analyticsit ja avastate, et 15–30% teie liiklusest tuleb turgudelt, mida te pole sihinud. Need kasutajad leiavad teid, kuid teie konversioonimäär neil turgudel on 60–80% madalam kui teie koduturul.

Toiming: See kinnitab nõudluse olemasolu. Kui ootate lokaliseerimist, loovad konkurendid nendel turgudel lokaliseeritud alternatiive ja haaravad teie avastatud võimaluse.

Päästik 2: toote turu sobivus saavutatud

Olete leidnud, et tooteturg sobib teie esialgsele turule. Säilitamine on tugev, müügist loobumine madal ja kasutajad toetavad teie toodet. Praegu on aeg laieneda, mitte kuus kuud hiljem.

Toiming: alustage kohe pideva lokaliseerimise infrastruktuuri. Sellised ettevõtted nagu Notion ootasid, kuni nad märkasid Jaapanis ja Koreas suuri kasutajakogukondi, ning lokaliseerisid seejärel kiiresti. Praegu on 70% Notioni kasutajatest väljaspool USA-d.

Päästik 3: raha kogumine või tulude verstapostid

Olete saavutanud märkimisväärse vooru või saavutanud tulu verstaposti, mis nõuab kiirendatud kasvu. Investorid ootavad rahvusvahelist laienemist. Lokaliseerimise edasilükkamine lükkab selle kasvu edasi.

Toiming: eraldage 15–20% insenertehnilistest ressurssidest i18n infrastruktuuri ehitamiseks, enne kui suunate müügi ja turunduse uutele turgudele.

Päästik 4: konkurentsisurve

Konkurent on peamistel turgudel lansseerinud lokaliseeritud versioonid ja kogub haardejõudu. Nende lokaliseeritud toode konverteerib kasutajaid, keda oleksite võinud püüda.

Toiming: see on kõige kallim päästik. Nüüd paigaldate ajasurve all, mis suurendab kulusid 8–10 korda võrreldes i18n algusest peale ehitamisega.

Agiilne lokaliseerimise raamistik: sprindid, mitte kosed

Traditsiooniline lähenemine – ehita kõik, siis tõlgi kõik – on surnud. Kaasaegne tarkvaraarendus kasutab agiilseid sprinte. Teie lokaliseerimise töövoog peab vastama sellele tempole või muutuma kitsaskohaks, mis tapab globaalse kiiruse.

Pidev lokaliseerimine: mida see tegelikult tähendab

Pidev lokaliseerimine integreerib tõlke töövood paindlikesse arendustsüklitesse, nii et lokaliseeritud versioonid tarnitakse samaaegselt lähtekeelsete väljaannetega. Selle asemel, et tõlkimine oleks väljalaskejärgne rüselus, on see paralleelprotsess, mis on igasse sprindi sisse ehitatud.

Kuidas see praktikas töötab:

1. Sprindi planeerimine (nädal 0): Lokaliseerimisnõuded on eelnevalt kindlaks määratud. Tootejuhid ja lokaliseerimismeeskonnad lähtuvad sellest, milline sisu vajab tõlkimist ja millised turud on prioriteetsed.
2. Arendus (1.–2. nädal): Arendajad loovad funktsioone väliste stringidega. Kui koodibaasi lisatakse uus sisu, ekstraheeritakse see automaatselt ja saadetakse tõlkehaldussüsteemidesse (TMS).
3. Tõlge (paralleelprotsess): Samal ajal kui arendajad jätkavad kodeerimist, töötavad tõlkijad uute stringide kallal. Kontekst antakse ekraanipiltide, kasutajaliidese kirjelduste ja arendaja kommentaaride kaudu.
4. QA integreerimine (2. nädal): tõlgitud stringid liidetakse tagasi koodibaasi. Keeleline QA toimub funktsionaalse kvaliteedi tagamise kõrval. Testijad kontrollivad kasutajaliidese katkestusi, teksti ületäitumist ja konteksti täpsust.
5. Juurutus (2. nädala lõpp): Kõik keeleversioonid juurutatakse samaaegselt. Inglis-, saksa-, jaapani- ja hispaaniakeelsed versioonid avaldatakse koos, mitte järjestikku.

Sprindi planeerimine lokaliseerimiseks: puuduv tükk

Enamik arendusmeeskondi kavandab sprinte, arvestamata lokaliseerimist kuni viimase hetkeni. See tekitab kaose. Siin on, kuidas tõhusad meeskonnad integreerivad lokaliseerimise sprindi planeerimisse.

1. Määratlege lokaliseerimine jaotise “Valmis definitsioon” osana

Funktsioon ei ole valmis enne, kui seda testitakse kõigis sihtkeeltes. See sunnib meeskondi sprindihinnangutes arvestama lokaliseerimisaega.

2. Loo lokaliseerimise kasutajalugusid

Käsitlege lokaliseerimist kasutajaloona: “Saksamaa kasutajana pean kõik kasutajaliidese elemendid tõlkima, et saaksin toodet kasutada oma emakeeles.” Määrake loo punktid ja jälgige kiirust.

3. Kaasake lokaliseerimismeeskonnad sprindi planeerimise koosolekutele

Lokaliseerimishaldurid osalevad sprindi planeerimises, et tuvastada tõlkemaht, märgistada keerulised stringid ja joondada ajaskaala. See hoiab ära üllatused.

4. Automatiseerige sisu väljavõte ja kohaletoimetamine

Kasutage CI/CD integratsioone, mis eraldavad automaatselt uued stringid Giti kohustustest ja suunavad need tõlkijatele. Käsitsi ülekanded e-posti või arvutustabelite kaudu on kitsaskohad, mis tapavad väledat kiirust.

5. Ehitage tõlkepuhvrid sprintideks

Mitte iga sprint ei vaja rasket tõlget. Mõned sprintid keskenduvad taustatööle minimaalsete kasutajaliidese muudatustega. Kasutage neid spurte, et tõlkevõlgadele järele jõuda või olemasolevaid tõlkeid täiustada.

Meeskonna struktuur: kes tegelikult lokaliseerib?

Lokaliseerimine ei ole ühe inimese töö. See nõuab ristfunktsionaalset koostööd arendajate, tootejuhtide, tehniliste kirjutajate, tõlkijate ja kvaliteedikontrolli testijate vahel. Siin on ideaalne meeskonna struktuur:

Lokaliseerimismeeskonna suuruse küsimus

Kui palju inimesi sa tegelikult vajad? See sõltub teie arengukiirusest ja turu ambitsioonidest:

• Varajane staadium (pre-PMF): 0-1 lokaliseerimisspetsialist. Arendajad tegelevad i18n arhitektuuriga. Kasutage tõlketööks sisseehitatud tõlkijavõrkudega TMS-platvorme.
• Post-PMF (2–5 keelt): 1 lokaliseerimishaldur + välised tõlkemüüjad. Juht koordineerib töövooge, haldab TMS-i ja tagab kvaliteedi.
• Skaalatapp (5–15 keelt): 1–2 lokaliseerimishaldurit + spetsiaalne keeleteadlane tippturgude jaoks + välised tarnijad pikkade keelte jaoks. Kaaluge riigisiseste arvustajate palkamist.
• Ettevõte (15+ keelt): täielik lokaliseerimismeeskond koos piirkondlike juhtide, ettevõttesiseste keeleteadlaste, kvaliteedikontrolli spetsialistide ja lokaliseerimisinseneridega.

Tehnilise kirjaniku roll: lokaliseerimiseks kirjutamine

Tehnilised kirjanikud on tõhusa lokaliseerimise laulmatud kangelased. Selgelt lähtekeeles kirjutatud sisu tõlgitakse kiiremini, täpsemalt ja väiksemate kuludega.

Lokaliseerimissõbralikud kirjutamise juhised:

• Kasutage lihtsat ja otsest keelt: Vältige idioome, kultuurilisi viiteid ja keerulisi lausestruktuure. “Klõpsa nupule” tähendab paremini kui “Protsessi käivitamiseks vajutage nuppu”.
• Olge terminoloogiaga kooskõlas: Kasutage läbivalt sama mõiste jaoks sama terminit. Ärge kasutage vaheldumisi “kustuta”, “eemalda” ja “prügikast”. Valige üks.
• Hoidke laused lühikesed: Üks idee lause kohta. Pikad liitlaused, milles on mitu lauset, on tõlke õudusunenäod.
• Vältige huumorit ja sõnamängu: Sõnamängud, naljad ja nutikad sõnamängud tõlgivad harva. Need sunnivad tõlkijaid valima sõnasõnalise tõlke (kaob nalja) või loomingulise kohandamise (toob kaasa riski) vahel.
• Dokumendi kontekst tõlkijatele: Lisage kommentaare, mis selgitavad, kus stringid ilmuvad, mida nad teevad ja mis tahes piiranguid (tähemärgipiirangud, tooninõuded).
• Looge ja haldage sõnastikke: Määratlege võtmeterminid üks kord. Veenduge, et tõlkijad kasutaksid tootepõhise terminoloogia jaoks ühtseid tõlkeid.

Reaalse maailma edulood: ettevõtted, kellel on õige ajastus

Mõiste: lokaliseeritud varakult, jäädvustatud globaalselt Growth

Notion märkas ootamatut tõmbejõudu Jaapanis ja Koreas – turgudel, mida nad polnud sihtinud. Ootamise asemel lokaliseerisid nad kiiresti pärast tooteturule sobivust. Neil oli sisuhalduse jaoks sisuhaldus juba olemas, nii et Smartlingiga integreerimine võttis aega vaid ühe nädala.

Tänapäeval toetab Notion 19 keelt ja dialekti, millest ligikaudu 70% kasutajatest on väljaspool USA-d. Varajane lokaliseerimisinvesteering asetas need algusest peale ülemaailmse tootena, mitte USA tootena, mis üritas laieneda.

Airbnb: lokaliseerimine kui konkurentsistrateegia

Airbnb pöördus Hiina poole, teades, et neil on karm kohalik konkurents (Tujia, Xiaozhu) ja ranged regulatiivsed tõkked. Nende lokaliseerimisstrateegia ületas tõlkimise:

• Ümber kaubamärgiga “Aibiying” (爱彼迎): Tähendus “tervitage üksteist armastusega” – kultuuriliselt kõlav, mitte ainult foneetiliselt sarnane.
• Integreeritud WeChat ja Alipay: Hiina kasutajad ei kasuta veebimaksete tegemiseks krediitkaarte. Airbnb kohandas maksete infrastruktuuri kohaliku käitumisega.
• Uuesti kujundatud kasutajaliides Hiina eelistuste jaoks: Kohandatud terminoloogiat “Võõrustaja” ja “Külaline” terminiteks “Kodupartner” ja “Lühiajaline rentija”, et see vastaks kultuurilistele ootustele.
• Lokaliseeritud kirje kirjeldused: „luksuslikest mugavustest” on nihkunud „hubane peatumine” ja „autentne kohalik kogemus” – see, mida Hiina reisijad tegelikult otsivad.

Tulemus: Hiina kliendibaasi kasv 700% ühe aasta jooksul pärast lokaliseerimist.

Spotify: kultuuriline lokaliseerimine, mitte ainult tõlge

Spotify India turuletoomine näitab, et lokaliseerimine hõlmab toote kohandamist, mitte ainult keele tõlget:

• Mitme keele tugi: Integreeritud hindi, tamili, pandžabi ja muud keeled otse rakendusse – mitte ühe “india” versioonina, vaid eraldiseisvate lokaliseeritud kogemustena.
• Lokaliseeritud esitusloendid: loodud piirkonnaspetsiifilised muusikatuvastusalgoritmid, mis mõistsid kohalikke artiste, žanre ja kuulamisharjumusi.
• Hinnakujunduse kohandamine: tutvustasime taskukohaseid plaane, mis vastasid kohalikule ostujõule, mitte ainult ei konverteerinud USD INR-ideks.

Spotify ei oodanud, kuni neil on “piisavalt” India kasutajaid, et lokaliseerimist õigustada. Nad lokaliseerisid, et hankida neid kasutajaid.

Kulude jaotus: kui palju te tegelikult kulutate

Räägime reaalsetest numbritest. Kui palju lokaliseerimine tegelikult maksab, kui teete seda algusest peale, võrreldes hilisema moderniseerimisega?

Alumine rida: Tüüpilise SaaS-i toote puhul, millel on 100 000 koodirida ja 10 000 tõlgitavat stringi, maksab i18n loomine esimesest päevast alates ligikaudu 30 000–50 000 dollarit. Sama toote ümberehitamine pärast turuletoomist maksab 200 000–500 000 dollarit inseneri-, tõlkimis-, kvaliteedikontrolli ja hilinenud tulude osas.

Levinud vastuväited (ja miks need valed)

“Me isegi ei tea, kas meie toode meie koduturul läbi lööb.”

See on kõige levinum vastuväide ja see põhineb valel oletusel: i18n on kallis üldkulu, mis tasub end ära ainult siis, kui lähete globaalseks.

Tegelikkus: i18n-iga ehitamine alates esimesest päevast maksab 10-15% täiendavat arendusaega. See on ligikaudu üks lisapäev kahenädalase sprindi kohta. Stringide välistamise, lokaaditeadliku vormingu kasutamise ja paindlike paigutuste kujundamise distsipliin parandab tegelikult koodi kvaliteeti isegi siis, kui te kunagi ei lokaliseeri. Väldite kõvasti kodeeritud eeldusi, loote rohkem modulaarset arhitektuuri ja loote hooldatavat koodi.

Tegelik küsimus ei ole “Kas me läheme globaalseks?” See on “Kas me saame endale lubada kogu oma toote ümberehitamist, kui seda teeme?”

“Lokaliseerimine võib oodata, kuni meil on neil turgudel maksvaid kliente.”

See tekitab kana ja muna probleemi. Rahvusvahelistel turgudel asuvad kliendid toovad väiksema tõenäosusega konversiooni, kui teie toode pole lokaliseeritud. Teie konversioonimäär nendel turgudel on 60–80% madalam kui teie koduturul, mis paneb teid järeldama, et nõudlust pole piisavalt.

Kuid see madal nõudlus on halva lokaliseerimise artefakt, mitte tegelik turu huvimatus. Kui te õigesti lokaliseerite, ületavad need “madala nõudlusega” turud sageli teie esialgseid eeldusi.

CSA uuring leidis, et 76% veebitarbijatest eelistavad osta tooteid, mille teave on nende emakeeles. Kui teie toode pole lokaliseeritud, ei mõõda te tegelikku nõudlust – mõõdate ainult ingliskeelsete toodete tolerantsi.

“Kasutame lihtsalt Google’i tõlget ja puhastame selle hiljem.”

Masintõlge on dramaatiliselt paranenud, kuid see ei asenda õiget lokaliseerimisstrateegiat. Siin on põhjus:

• Kontekst on oluline: “pank” võib tähendada finantsasutust või jõeäärt. MT ei mõista konteksti ilma koolituseta.
• Kultuuriline kohanemine ei ole tõlkimine: Makseviiside lokaliseerimine, värviskeemide kohandamine ja kasutajaliidese voogude kohandamine pole asjad, millega MT tegeleb.
• Brändi hääl läheb kaduma: MT toodab funktsionaalset teksti, mitte mõjuvat koopiat, mis säilitab teie brändi isikupära.
• Juriidiline ja regulatiivne sisu nõuab inimese ülevaatust: Teenusetingimused, privaatsuspoliitika ja vastavusdokumendid peavad olema juriidiliselt täpsed. MT vead tekitavad vastutuse.

Sellegipoolest on MT väärtuslik esialgsete mustandite, kasutajate loodud sisu tõlkimise ja madala prioriteediga sisu jaoks. Kuid see peaks olema osa töövoost, mis hõlmab inimeste ülevaatust, mitte asendama professionaalset lokaliseerimist.

Teie lokaliseerimise valmisoleku kontrollnimekiri

Kasutage seda kontroll-loendit, et teha kindlaks, kas olete valmis lokaliseerimist alustama (või peate esmalt looma i18n infrastruktuuri):

Infrastruktuuri valmisolek:

• Kõik kasutajale suunatud stringid välistatakse ressursifailides (mitte kõvakoodiga)
• Kood toetab Unicode’i ja käsitleb mitmebaidiseid märke õigesti
• Kuupäeva, kellaaja, numbri ja valuuta vormindamine kasutab lokaaditeadlikke teeke
• Kasutajaliidese paigutused käsitlevad teksti laiendamist/kokkutõmbumist (testitud saksa ja jaapani keelega)
• Paremalt vasakule keele tugi on rakendatud (või arhitektuurne)
• Stringide ühendamist välditakse (kasutades selle asemel parameetritega stringe)
• Tõlkehaldussüsteem (TMS) on valitud või hindamisel

Meeskonna valmisolek:

• Arendajad mõistavad i18n põhimõtteid ja on koolitatud parimate tavade kohta
• Määratakse lokaliseerimishaldur või punktiisik
• Sihtturgude jaoks määratakse tõlkemüüjad või ettevõttesisesed lingvistid
• Tehnilised kirjanikud loovad lokaliseerimissõbralikku sisu
• QA protsess hõlmab kasutajaliidese katkestuste testimist lokaliseeritud versioonides
• Sprindi planeerimine hõlmab lokaliseerimist osana “Definition of Done”

Strateegia valmisolek:

• Sihtturud seatakse prioriteediks liiklusandmete, turu suuruse ja konkurentsi alusel
• Eelarve on eraldatud tõlkimiseks, tööriistadeks ja võimalikuks palkamiseks
• Edumõõdikud on määratletud (konversioonimäärad, aktiveerimine, säilitamine turu järgi)
• Sihtturgude jaoks uuritakse juriidilisi ja vastavusnõudeid
• Toote turu sobivus on kinnitatud vähemalt ühel turul

Ajastuse paradoks

Parim aeg lokaliseerimise alustamiseks oli siis, kui kirjutasite oma esimese koodirea. Parim aeg on praegu – enne järgmise koodirea kirjutamist.

Iga päev, mil viivitate i18n infrastruktuuri ehitamisega, on järjekordne tehniliste võlgade kogunemise päev. Iga kõvakoodiga string on veel üks string, mille peate lahti harutama. Iga paigutus, mis eeldab ingliskeelse teksti pikkust, on teine paigutus, mille peate ümber kujundama.

Ülemaailmseid turge võitvad ettevõtted ei ole parimate tõlkeeelarvetega. Just nemad loovad oma DNA-sse lokaliseerimise esimesest päevast peale, nii et kui Tokyos, São Paulos või Berliinis avaneb võimalus, on nad valmis vastama kohalikus keeles.

Tegevuskava: mida sel nädalal teha

Kui loete seda ja mõistate, et olete lokaliseerimisega viivitanud, tehke kohe järgmist.

Kui te pole arendust alustanud:

1. Arhitekt i18n jaoks esimesest päevast: Valige sisseehitatud i18n-toega raamistikud (React Intl, i18next jne).
2. Seadistage oma TMS-i enne esimest sidumist: Platvormid, nagu Lokalise, Crowdin või Phrase, integreeruvad otse GitHubiga.
3. Kõik stringid välistatakse kohe: Iga kasutajaliidese string, veateade ja tööriistavihje suunatakse ressursifailidesse, mitte lähtekoodi.
4. Dokumenteerige oma lokaliseerimisstrateegia: Isegi kui turule tulite ainult ühel turul, dokumenteerige, kuidas laienete teistele.

Kui olete keskmises arengujärgus:

1. Koodibaasi auditeerimine: tuvastage kõik kõvakoodiga stringid. Eelistage stringide välistamist kasutajale suunatud funktsioonides.
2. Koostage ümberkujundamise tegevuskava: eraldage järgmise 3–6 kuu jooksul i18n infrastruktuurile 20% sprindikiirusest.
3. Alustage uute funktsioonidega: Kõik uued funktsioonid peavad olema i18n-ühilduvad. See hoiab ära täiendava võla tekkimise, kui maksate olemasoleva võla tagasi.
4. Testi pseudolokaliseerimisega: looge tähemärgilaienduse abil võltsitud tõlkeid, et leida kasutajaliidese katkestused enne tegelikku tõlkimist.

Kui olete juba käivitanud:

1. Kvantifitseerige tehniline võlg: Hinnake oma koodibaasi lokaliseeritavaks muutmiseks vajalikke jõupingutusi. Olge kulude osas aus.
2. Turgede tähtsuse järjekorda seadmine olemasoleva liikluse põhjal: Vaadake Google Analyticsist turge, kus saate orgaanilist liiklust vaatamata lokaliseerimise puudumisele.
3. Käitage piloot ühe turuga: Valige suure potentsiaaliga turg ja viige läbi täielik lokaliseerimise piloot. See paljastab kõik varjatud väljakutsed.
4. Teavitage sidusrühmadele realistlikke ajakavasid: Lokaliseerimise tagantjärele paigaldamine võtab aega 6–18 kuud, mitte 2 nädalat. Seadke ootused varakult.

Järeldus: otsus, mis määrab teie globaalse tuleviku

Nüüd mõistate lokaliseerimise viivitamise tegelikku maksumust. Küsimus ei ole selles, kas lokaliseerida, vaid selles, kas ehitate selle algusest peale või maksate hiljem 5–7 korda rohkem.

Iga funktsioon, mille tarnite ilma i18n infrastruktuurita, on funktsioon, mille peate uuesti üles ehitama. Iga turg, mille sisenemisega viivitate, on turu, mille konkurendid hõivavad.

Nutikamad asutajad ei näe lokaliseerimist kasvumaksuna. Nad näevad seda kui vundamenti, mis teeb ülemaailmse kasvu võimalikuks.