Mikor van a legalkalmasabb időpont a lokalizációs munkák megkezdésére?

„A termék-piaci illeszkedés után fogjuk elvégezni a lokalizációt.” Ez az egyetlen mondat a szoftvercégeknek átlagosan a fejlesztési erőfeszítéseik 23–42%-ába kerül, és 6–18 hónappal késlelteti a globális piacra lépést. A rejtett költség nem a fordítás – hanem az a technikai adósság, amelyet ma minden kódsorba beépítetek.

A kemény számok: most építeni vagy később felújítani?

• 5–7x – Költségszorzó a lokalizáció utólagos beépítése és a beépítés a gyártás során összehasonlításában
• 23–42% – A késleltetett lokalizáció miatt felhalmozódott technikai adósság miatt elpazarolt fejlesztési idő
• 6–18 hónap – A globális piacra lépés átlagos késedelme, ha a lokalizációt a termék bevezetését követően végzik el

A McKinsey és a Localization Industry Standards Association kutatása szerint a szervezetek fejlesztési erőfeszítéseik 23–42%-át pazarolják el a technikai adósság kezelésére. Ha a lokalizációt csak utólag veszik figyelembe, ez az adósság exponenciálisan növekszik.

Ez a gyakorlatban a következőket jelenti: ha a csapatod 3 hónapot tölt egy olyan funkció fejlesztésével, amelyben keménykódolt karakterláncok, elrendezési feltételezések és a nyelvi beállításoktól független formázás szerepel, akkor 15–21 hónapot fogsz tölteni annak kibogozásával, amikor úgy döntesz, hogy globális piacra léptek. Ez még nem is tartalmazza a fordítási időt – ez csupán az a fejlesztői munka, amelynek célja, hogy a kódbázis lokalizálhatóvá váljon.

A sorsodat meghatározó technikai adósságarány

A technikai adósságarány (TDR) azt méri, hogy a kódbázis kijavításának költségei milyen arányban állnak a nulláról történő felépítésének költségeihez képest. Az iparági adatok szerint az 5%-ot meghaladó TDR-érték sürgős intézkedést jelez. Azoknál a vállalatoknál, amelyek elhalasztják a nemzetközi piacra lépést, a lokalizációval kapcsolatos TDR gyakran meghaladja a 40%-ot.

Valós példa: Egy 50 000 sor kóddal rendelkező SaaS-startup, amelyben az angol szövegek merev kódolással szerepeltek, 2 hétre becsülte a „fordítások hozzáadását”. A tényleges munka 6 hónap fejlesztői időt vett igénybe a karakterláncok külsősítésére, a hibás elrendezések kijavítására, a nyelvi beállításokat figyelembe vevő formázás megvalósítására és a szélsőséges esetek megoldására. Költség: körülbelül 180 000 dollár fejlesztői munkaidőben. Ha az első naptól kezdve a nemzetközi használatra tervezték volna a rendszert, a többletköltség körülbelül 25 000 dollár lett volna.

A kezdés tökéletes pillanata: mielőtt leírnád az első sort

A kutatási eredmények egyértelműek. Azok a vállalatok, amelyek már a kezdetektől beépítik a lokalizációt, gyorsabban haladnak előre, kevesebbet költenek, és meghódítják a globális piacokat, miközben versenytársaik még mindig a kódbázisuk átalakításán dolgoznak.

Nemzetköziesítés (i18n): Az alapjaid

A nemzetköziesítés azt jelenti, hogy a szoftvert úgy tervezzük meg, hogy több nyelvhez és régióhoz is alkalmazkodni tudjon anélkül, hogy műszaki módosításokra lenne szükség. Ez nem egy olyan funkció, amit utólag hozzáadunk – hanem egy gondolkodásmód, amelyet már az architektúra kidolgozásának legelejétől kezdve alkalmazunk.

A nemzetközi lokalizáció (i18n) alapelvei (ezeket már az első naptól kezdve be kell építeni):

• Az összes felhasználó számára látható szöveget külső forrásból kell betölteni: Soha ne írj be karakterláncokat közvetlenül a forráskódba. Használj erőforrásfájlokat (JSON, YAML, XLIFF), amelyek elválasztják a tartalmat a logikától.
• Unicode mindenhol: Támogatja a kétbájtos karaktereket, a jobbról balra író írásrendszereket (arab, héber) és a bonyolult írásrendszereket (thai, devanágari).
• Helyi beállításokhoz igazodó formázás: A dátumok, időpontok, számok, pénznemek és mértékegységek dinamikusan alkalmazkodniuk kell a felhasználó helyi beállításaihoz.
• Rugalmas felhasználói felület-elrendezések: A német szöveg az angolhoz képest 30%-kal hosszabb. A japán szöveg rövidebb. A felhasználói felületnek képesnek kell lennie a szöveg hosszabbodásának és rövidülésének kezelésére anélkül, hogy megszakadna.
• Kerülje az összefűzött karakterláncokat: a “You have ” + count + ” messages” kifejezés a különböző nyelvtani szabályokkal rendelkező nyelveken hibásan jelenik meg. Helyette használjon paraméterezett karakterláncokat.
• Kétirányúságra való tervezés: Az elrendezésnek áttervezés nélkül támogatnia kell mind a balról jobbra, mind a jobbról balra történő szövegmegjelenítést.

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

A négy időbeli kiváltó tényező: mikor válik sürgőssé a lokalizáció?

Bár az ideális válasz az, hogy „a kezdetektől fogva”, vannak olyan konkrét pillanatok, amikor a lokalizáció a „jó, ha van” kategóriából átlép a „létfontosságú szükséglet” kategóriába.

1. kiváltó tényező: Váratlan nemzetközi forgalom

Megnézed a Google Analytics adatait, és kiderül, hogy a forgalom 15–30%-a olyan piacokról érkezik, amelyeket nem vettél célba. Ezek a felhasználók maguktól találnak rád, de a konverziós arányod ezeken a piacokon 60–80%-kal alacsonyabb, mint a hazai piacon.

Intézkedés: Ez igazolja, hogy létezik kereslet. Ha halogatod a lokalizációt, az adott piacok versenytársai lokalizált alternatívákat fognak kifejleszteni, és megragadják azt a lehetőséget, amelyet te fedeztél fel.

2. kiváltó tényező: A termék és a piac közötti illeszkedés megvalósult

Megtaláltad a termék-piac illeszkedést a kezdeti piacodon. A felhasználói megtartás erős, az elvándorlás alacsony, és a felhasználók ajánlják a termékedet. Most van itt az ideje a terjeszkedésnek, nem pedig hat hónappal később.

Lépés: Indítsd el most a folyamatos lokalizációs infrastruktúrát. Az olyan cégek, mint a Notion, addig vártak, amíg észrevették, hogy Japánban és Koreában nagy felhasználói közösségek alakultak ki, majd gyorsan elvégezték a lokalizációt. Ma a Notion felhasználóinak 70%-a az Egyesült Államokon kívülről származik.

3. kiváltó tényező: Adománygyűjtési vagy bevételi mérföldkövek

Jelentős tőkebevonást hajtott végre, vagy olyan bevételi mérföldkövet ért el, amely gyorsított növekedést tesz szükségessé. A befektetők nemzetközi terjeszkedést várnak el. A lokalizáció elhalasztása lassítja ezt a növekedést.

Intézkedés: Az értékesítés és a marketing új piacokra történő kiterjesztése előtt a mérnöki erőforrások 15–20%-át fordítsuk az i18n-infrastruktúra kiépítésére.

4. kiváltó tényező: Versenynyomás

Egy versenytársunk a legfontosabb piacokon helyi nyelvű változatokat dobott piacra, és egyre nagyobb népszerűségre tesz szert. A helyi nyelvű termékükkel olyan felhasználókat szereznek meg, akiket egyébként te is megnyerhettél volna.

Művelet: Ez a legdrágább kiváltó ok. Most időnyomás alatt végzed az utólagos beépítést, ami 8–10-szeres költségnövekedést jelent ahhoz képest, mintha az i18n-t a kezdetektől fogva beépítetted volna.

Az agilis lokalizációs keretrendszer: sprintek, nem pedig vízesés-modell

A hagyományos megközelítés – először mindent elkészíteni, majd mindent lefordítani – már a múlté. A modern szoftverfejlesztés agilis sprinteket alkalmaz. A lokalizációs munkafolyamatnak lépést kell tartania ezzel a tempóval, különben szűk keresztmetszetté válik, ami megakadályozza a globális fejlődés ütemét.

Folyamatos helymeghatározás: mit is jelent ez valójában?

A folyamatos lokalizáció a fordítási munkafolyamatokat integrálja az agilis fejlesztési ciklusokba, így a lokalizált verziók a forrásnyelvű kiadásokkal egy időben kerülnek forgalomba. A fordítás nem a kiadás utáni rohanás, hanem minden sprintbe beépített párhuzamos folyamat.

Hogyan működik ez a gyakorlatban:

1. Sprinttervezés (0. hét): A lokalizációs követelményeket előre meghatározzák. A termékmenedzserek és a lokalizációs csapatok egyeztetik, hogy mely tartalmakat kell lefordítani, és mely piacok élveznek elsőbbséget.
2. Fejlesztés (1–2. hét): A fejlesztők külső karakterláncok felhasználásával készítik el a funkciókat. Amint az új tartalom bekerül a kódbázisba, azt automatikusan kivonják, és továbbítják a fordításkezelő rendszerekbe (TMS).
3. Fordítás (párhuzamos folyamat): Miközben a fejlesztők folytatják a kódolást, a fordítók az új karakterláncokon dolgoznak. A kontextust képernyőképek, a felhasználói felület leírásai és a fejlesztői megjegyzések biztosítják.
4. Minőségbiztosítási integráció (2. hét): A lefordított karakterláncokat visszaintegrálják a kódba. A nyelvi minőségbiztosítás a funkcionális minőségbiztosítással párhuzamosan zajlik. A tesztelők ellenőrzik, hogy nincs-e meghibásodás a felhasználói felületen, nem folyik-e túl a szöveg, és helyes-e a kontextus.
5. Közzététel (a 2. hét vége): Minden nyelvi változat egyszerre kerül közzétételre. Az angol, német, japán és spanyol változatok egyszerre kerülnek közzétételre – nem egymás után.

A lokalizáció sprinttervezése: a hiányzó láncszem

A legtöbb fejlesztőcsapat az utolsó pillanatig nem veszi figyelembe a lokalizációt a sprintek tervezésekor. Ez káoszt eredményez. Az alábbiakban bemutatjuk, hogyan építik be a kiemelkedő teljesítményű csapatok a lokalizációt a sprinttervezésbe:

1. Határozzuk meg a lokalizációt a „Késznek minősítés” részeként

Egy funkció addig nem tekinthető teljesnek, amíg nem tesztelték az összes célnyelven. Ez arra kényszeríti a csapatokat, hogy a sprintbecslésekben figyelembe vegyék a lokalizációs időt.

2. Helyi adaptációra vonatkozó felhasználói történetek létrehozása

Kezelje a lokalizációt felhasználói történetként: „Német felhasználóként szükségem van arra, hogy az összes felhasználói felületi elem le legyen fordítva, hogy anyanyelvemen használhassam a terméket.” Rendeljen hozzá történetpontokat, és kövesse nyomon a sebességet.

3. Vonjuk be a lokalizációs csapatokat a sprinttervezési megbeszélésekbe

A lokalizációs vezetők részt vesznek a sprinttervezésen, hogy felmérjék a fordítási mennyiséget, jelöljék meg a bonyolult karakterláncokat, és egyeztessék az ütemtervet. Ezzel elkerülhetők a váratlan események.

4. A tartalom kinyerésének és közzétételének automatizálása

Használjon olyan CI/CD-integrációkat, amelyek automatikusan kinyerik az új karakterláncokat a Git-commitekből, és továbbítják azokat a fordítóknak. Az e-mailen vagy táblázatokon keresztül történő kézi átadások olyan szűk keresztmetszeteket jelentenek, amelyek gátolják az agilis fejlesztés ütemét.

5. Építsünk be fordítási puffereket a sprintekbe

Nem minden sprint igényel jelentős fordítási munkát. Egyes sprintek a háttérmunkára összpontosítanak, és csak minimális felhasználói felület-módosításokat tartalmaznak. Használd ki ezeket a sprinteket a fordítási lemaradás ledolgozására vagy a meglévő fordítások finomítására.

A csapat felépítése: Ki végzi valójában a lokalizációt?

A lokalizáció nem egy ember feladata. Ehhez a fejlesztők, termékmenedzserek, műszaki írók, fordítók és minőségbiztosítási tesztelők közötti, több részlegre kiterjedő együttműködésre van szükség. Íme az ideális csapatszerkezet:

A lokalizációs csapat méretével kapcsolatos kérdés

Valójában hány emberre van szükséged? Ez a fejlesztési ütemedtől és a piaci céljaidtól függ:

• Korai szakasz (PMF előtti): 0–1 lokalizációs szakember. A fejlesztők foglalkoznak az i18n-architektúrával. A fordítási munkákhoz beépített fordítóhálózatokkal rendelkező TMS-platformokat használnak.
• PMF utáni szakasz (2–5 nyelv): 1 lokalizációs menedzser + külső fordítóirodák. A menedzser koordinálja a munkafolyamatokat, kezeli a fordításkezelő rendszert (TMS) és gondoskodik a minőségről.
• Bővítési szakasz (5–15 nyelv): 1–2 lokalizációs menedzser + a legfontosabb piacokra szakosodott nyelvészek + külső szolgáltatók a ritkábban használt nyelvek esetében. Fontolóra vehető helyi lektorok alkalmazása.
• Enterprise (15 vagy több nyelv): Teljes körű lokalizációs csapat regionális vezetőkkel, házon belüli nyelvészekkel, minőségbiztosítási szakemberekkel és lokalizációs mérnökökkel.

A műszaki író szerepe: írás a lokalizáció érdekében

A műszaki írók a hatékony lokalizáció méltatlanul elismert hősei. A forrásnyelven világosan megfogalmazott tartalom gyorsabban, pontosabban és alacsonyabb költségekkel fordítható le.

A lokalizáláshoz igazodó szövegírási irányelvek:

• Használj egyszerű, közvetlen nyelvet: Kerüld az idiómákat, a kulturális utalásokat és a bonyolult mondatszerkezeteket. A „Kattints a gombra” kifejezés jobban fordítható, mint a „Nyomd meg a gombot a folyamat elindításához.”
• Tartsa be a terminológiai egységességet: Ugyanazon fogalomra végig ugyanazt a kifejezést használja. Ne váltogassa a „törlés”, „eltávolítás” és „kukába” kifejezéseket. Válasszon egyet.
• A mondatokat tartsa rövidnek: Egy mondatban csak egy gondolat legyen. A hosszú, több tagmondatból álló összetett mondatok a fordítás szempontjából igazi rémálmok.
• Kerülje a humort és a szójátékokat: A szójátékok, viccek és ravasz szófordulatok ritkán fordíthatók le. Ezek arra kényszerítik a fordítókat, hogy a szó szerinti fordítás (amelyben a vicc elveszik) és a kreatív adaptáció (amely kockázattal jár) között válasszanak.
• Dokumentumkontextus a fordítók számára: Adjon hozzá megjegyzéseket, amelyek elmagyarázzák, hol jelennek meg a karakterláncok, milyen funkciójuk van, valamint milyen korlátozások vonatkoznak rájuk (karakterkorlátok, stílusbeli követelmények).
• Szótárak létrehozása és karbantartása: A kulcsszavakat egyszer kell meghatározni. Gondoskodjon arról, hogy a fordítók a termékre jellemző terminológiát következetesen fordítsák.

Valós sikertörténetek: olyan vállalatok, amelyek jól választották meg az időzítést

Notion: Korai lokalizáció, globális Growth elérése

A Notion váratlanul nagy népszerűségre tett szert Japánban és Koreában – olyan piacokon, amelyekre korábban nem is irányultak. Ahelyett, hogy várakozásba kezdtek volna, a termék és a piac közötti illeszkedés elérése után gyorsan elvégezték a lokalizációt. A tartalomkezeléshez már korábban is a Contentful-t használták, így a Smartlinggel való integráció mindössze egy hetet vett igénybe.

Jelenleg a Notion 19 nyelvet és nyelvjárást támogat, és a felhasználók mintegy 70%-a az Egyesült Államokon kívülről származik. A lokalizációba fektetett korai beruházásnak köszönhetően a termék már a kezdetektől fogva globális termékként pozícionálódott, nem pedig egy terjeszkedni próbáló amerikai termékként.

Airbnb: A lokalizáció mint versenystratégia

Az Airbnb úgy lépett be a kínai piacra, hogy tisztában volt azzal, hogy heves helyi versennyel (Tujia, Xiaozhu) és szigorú szabályozási akadályokkal kell szembenéznie. Lokalizációs stratégiájuk túlmutatott a puszta fordításon:

• Az „Aibiying” (爱彼迎) névre változtatták: A név jelentése: „szeretettel fogadjuk egymást” – kulturális vonatkozásai vannak, nem csupán hangzásában hasonlít a korábbi névre.
• Beépített WeChat és Alipay: A kínai felhasználók nem használnak hitelkártyát az online fizetésekhez. Az Airbnb a helyi szokásokhoz igazította a fizetési rendszerét.
• A kínai felhasználói beállításokhoz igazított, újratervezett felhasználói felület: A „Host” és „Guest” kifejezéseket „Home Partner” és „Short-term Renter” kifejezésekre módosítottuk, hogy azok megfeleljenek a kulturális elvárásoknak.
• Helyi viszonyokhoz igazított hirdetésleírások: A „luxus kényelmi szolgáltatások” helyett a „hangulatos szállás” és az „autentikus helyi élmény” került előtérbe – pontosan azok, amiket a kínai utazók ténylegesen keresnek.

Eredmény: A lokalizációt követő egy év alatt a kínai ügyfélkör 700%-kal nőtt.

Spotify: Kulturális lokalizáció, nem csupán fordítás

A Spotify indiai piacra lépése jól mutatja, hogy a lokalizáció nem csupán a nyelvi fordítást jelenti, hanem a termék hozzáigazítását is:

• Többnyelvű támogatás: A hindi, a tamil, a pandzsábi és más nyelvek közvetlenül az alkalmazásba vannak integrálva – nem egyetlen „indiai” változat formájában, hanem különálló, lokalizált felhasználói élményként.
• Helyi lejátszási listák: Olyan, régió-specifikus zenefelfedező algoritmusokat fejlesztettünk ki, amelyek figyelembe vették a helyi előadókat, műfajokat és zenehallgatási szokásokat.
• Árak kiigazítása: Olyan megfizethető csomagokat vezettünk be, amelyek a helyi vásárlóerőhöz igazodtak, és nem csupán az amerikai dollár indiai rúpiára történő átváltásán alapultak.

A Spotify nem várta meg, amíg „elég” indiai felhasználója lesz ahhoz, hogy indokolt legyen a lokalizáció. Éppen azért lokalizálták a szolgáltatást, hogy megszerezzék ezeket a felhasználókat.

A költségek lebontása: mennyit fogsz valójában költeni

Nézzük a konkrét számokat! Mennyibe kerül valójában a lokalizáció, ha már az elejétől kezdve megfelelően végzik, szemben a későbbi utólagos átalakítással?

Összegzés: Egy tipikus, 100 000 sor kódból és 10 000 fordítható karakterláncból álló SaaS-termék esetében a nemzetközi lokalizáció (i18n) beépítése a fejlesztés első napjától kezdve körülbelül 30 000–50 000 dollár többletfejlesztési költséget jelent. Ugyanezen termék utólagos átalakítása a piacra dobás után 200 000–500 000 dollárba kerül a fejlesztési, fordítási és minőségbiztosítási költségek, valamint az elmaradt bevételi lehetőségek miatt.

Gyakori ellenérvek (és miért tévesek)

„Még azt sem tudjuk, hogy a termékünk sikeres lesz-e a hazai piacon.”

Ez a leggyakoribb ellenérv, és egy téves feltételezésen alapul: miszerint az i18n költséges terhet jelent, amely csak akkor térül meg, ha globális szintre lépünk.

A valóság: Ha az i18n-t már az első naptól kezdve beépítjük a fejlesztésbe, az 10–15%-kal megnöveli a fejlesztési időt. Ez nagyjából egy plusz napot jelent egy kéthetes sprint során. A karakterláncok külsősítése, a nyelvi beállításokat figyelembe vevő formázás és a rugalmas elrendezések tervezése valójában javítja a kód minőségét, még akkor is, ha soha nem lokalizálunk. Elkerülhetjük a kódba beépített feltételezéseket, modulárisabb architektúrát építhetünk, és karbantarthatóbb kódot hozhatunk létre.

A valódi kérdés nem az, hogy „Kiterjesztjük-e tevékenységünket globális szintre?”, hanem az, hogy „Megengedhetjük-e magunknak, hogy ekkor teljesen újjáépítsük a termékünket?”

„A lokalizációval várhatunk addig, amíg fizető ügyfeleink lesznek azokon a piacokon.”

Ez egy „tyúk vagy tojás” problémát vet fel. A nemzetközi piacokon az ügyfelek kevésbé hajlamosak vásárlásra, ha a terméked nincs lokalizálva. Ezen piacokon a konverziós arányod 60–80%-kal alacsonyabb lesz, mint a hazai piacon, ami arra a következtetésre vezet, hogy „nincs elég kereslet”.

De ez az alacsony kereslet a nem megfelelő lokalizáció következménye, nem pedig a piac valódi érdektelensége. Ha a lokalizációt megfelelően végzik el, ezek az „alacsony keresletű” piacok gyakran felülmúlják a kezdeti várakozásokat.

A CSA Research megállapította, hogy az online vásárlók 76%-a inkább olyan termékeket vásárol, amelyek leírása anyanyelvén szerepel. Ha a terméked nincs lokalizálva, akkor nem a valódi keresletet méred, hanem azt, hogy mennyire tolerálják az angol nyelvű termékeket.

„Most csak a Google Fordítót használjuk, majd később átnézzük.”

A gépi fordítás minősége jelentősen javult, de ez nem helyettesítheti a megfelelő lokalizációs stratégiát. Az okok a következők:

• A kontextus fontos: A „bank” szó jelenthet pénzintézetet vagy folyópartot is. A gépi fordítás (MT) képzés nélkül nem ismeri fel a kontextust.
• A kulturális adaptáció nem azonos a fordítással: A fizetési módok lokalizálása, a színsémák módosítása és a felhasználói felület folyamatainak adaptálása nem olyan feladatok, amelyeket a gépi fordítás elvégez.
• A márka hangja elvész: A gépi fordítás funkcionális szöveget eredményez, nem pedig olyan meggyőző szöveget, amely megőrzi a márka egyéniségét.
• A jogi és szabályozási tartalmakat embernek kell ellenőriznie: A felhasználási feltételeknek, az adatvédelmi irányelveknek és a megfelelőségi dokumentumoknak jogilag pontosnak kell lenniük. A gépi fordításból származó hibák jogi felelősséget vonhatnak maguk után.

Ennek ellenére a gépi fordítás hasznos lehet a kezdeti vázlatok, a felhasználók által létrehozott tartalmak fordításához, valamint az alacsony prioritású tartalmak esetében. Ugyanakkor egy olyan munkafolyamat részét kell képeznie, amely magában foglalja az emberi ellenőrzést is, és nem helyettesítheti a professzionális lokalizációt.

Ellenőrzőlista a lokalizációra való felkészültségről

Használd ezt az ellenőrzőlistát annak megállapításához, hogy készen állsz-e a lokalizáció megkezdésére (vagy először ki kell-e építened az i18n-infrastruktúrát):

Az infrastruktúra felkészültsége:

• Minden felhasználó számára látható szövegrészlet erőforrásfájlokban van tárolva (nem kódolva a programba)
• A kód támogatja az Unicode-ot, és helyesen kezeli a többbájtos karaktereket
• A dátum, az idő, a számok és a pénznem formázásához helyi beállításokat figyelembe vevő könyvtárakat használ
• A felhasználói felület elrendezései kezelik a szöveg hosszabbodását és rövidülését (német és japán nyelven tesztelve)
• A jobbról balra író nyelvek támogatása megvalósítva (vagy az architektúrába beépítve)
• A karakterláncok összefűzését elkerüljük (helyette paraméterezett karakterláncokat használunk)
• A fordításkezelő rendszer (TMS) kiválasztásra került, illetve jelenleg értékelés alatt áll

A csapat felkészültsége:

• A fejlesztők ismerik az i18n alapelveit, és képzésben részesültek a bevált gyakorlatokról
• Kijelölik a lokalizációs vezetőt vagy a kapcsolattartót
• A célpiacokhoz megfelelő fordítóirodákat vagy házon belüli nyelvészeket választanak ki
• A műszaki írók lokalizálásra alkalmas tartalmakat készítenek
• A minőségbiztosítási folyamat magában foglalja a lokalizált verziók felhasználói felületén fellépő hibák tesztelését is
• A sprinttervezés keretében a lokalizáció is része a „Definition of Done”-nak

Stratégiai felkészültség:

• A célpiacok rangsorolása a forgalmi adatok, a piac mérete és a verseny alapján történik
• Költségvetést különítettek el fordításra, eszközbeszerzésre és esetleges munkaerő-felvételre
• Meghatározták a siker mutatóit (konverziós arányok, aktiválás, megtartás piaconként)
• A célpiacok jogi és megfelelési követelményeinek feltérképezése
• A termék és a piac közötti illeszkedés legalább egy piacon igazolódott

Az időzítési paradoxon

A lokalizáció megkezdésének legjobb időpontja az volt, amikor megírtad az első kódsorodat. A második legjobb időpont pedig most van – még mielőtt megírnád a következő kódsorodat.

Minden nap, amellyel elhalasztod az i18n-infrastruktúra kiépítését, egy újabb nap, amelyen a technikai adósság tovább halmozódik. Minden keménykódolt karakterlánc egy újabb karakterlánc, amelyet ki kell bogoznod. Minden olyan elrendezés, amely az angol szövegek hosszát veszi alapul, egy újabb elrendezés, amelyet át kell tervezned.

Azok a vállalatok hódítják meg a globális piacokat, amelyeknek nem a legnagyobb a fordítási költségvetésük. Hanem azok, amelyek már az első naptól kezdve a lokalizációt a vállalati DNS-ük részévé teszik, így amikor Tokióban, São Paulóban vagy Berlinben megnyílik egy lehetőség, készen állnak arra, hogy a helyi nyelven reagáljanak rá.

A cselekvési terv: Mit kell tennünk ezen a héten?

Ha ezt olvasod, és rájössz, hogy eddig halogattad a lokalizációt, akkor az alábbiakat kell azonnal tenned:

Ha még nem kezdted el a fejlesztést:

1. Az i18n beépítése már a kezdetektől: Válassz olyan keretrendszereket, amelyek beépített i18n-támogatással rendelkeznek (React Intl, i18next stb.).
2. Az első commit előtt állítsd be a TMS-t: Az olyan platformok, mint a Lokalise, a Crowdin vagy a Phrase, közvetlenül integrálódnak a GitHubbal.
3. Az összes karakterláncot azonnal külső forrásba helyezzük: Minden felhasználói felületi karakterlánc, hibaüzenet és segítő szöveg az erőforrásfájlokba kerül, nem a forráskódba.
4. Foglald írásba a lokalizációs stratégiádat: Még akkor is, ha egyelőre csak egy piacon indulsz, írd le, hogyan tervezed a többi piacra való terjeszkedést.

Ha a fejlesztés közepén tartasz:

1. A kódbázis átvizsgálása: Az összes merev kódolású karakterlánc azonosítása. Elsőbbséget kell biztosítani a felhasználók számára látható funkciókban szereplő karakterláncok külsősítésének.
2. Készítsünk refaktorálási ütemtervet: A következő 3–6 hónapban a sprint sebesség 20%-át szánjuk az i18n-infrastruktúrára.
3. Kezdjük az új funkciókkal: Minden új funkciónak meg kell felelnie az i18n-követelményeknek. Ezzel elkerülhető a további adósság felhalmozódása, miközben a meglévő adósságot törlesztjük.
4. Tesztelés pszeudo-lokalizációval: Hamis fordítások létrehozása karakterkiterjesztéssel, hogy a valódi fordítás előtt felderítsük a felhasználói felületen fellépő hibákat.

Ha már elindítottad:

1. A technikai adósság felmérése: Becsüld meg, mennyi munkára lesz szükség ahhoz, hogy a kódbázisod lokalizálhatóvá váljon. Légy őszinte a költségeket illetően.
2. A piacok rangsorolása a meglévő forgalom alapján: Nézd meg a Google Analytics adatait, és keress olyan piacokat, ahol lokalizáció nélkül is van organikus forgalom.
3. Végezzen kísérleti projektet egy piacon: Válasszon ki egy nagy potenciállal rendelkező piacot, és hajtson végre egy teljes körű lokalizációs kísérleti projektet. Ezzel feltárhatók az összes rejtett kihívás.
4. Tájékoztassa az érdekelt feleket a reális határidőkről: A lokalizáció utólagos bevezetése 6–18 hónapig tart, nem pedig 2 hétig. Korán határozza meg az elvárásokat.

Következtetés: A döntés, amely meghatározza globális jövődet

Most már tisztában van a lokalizálás elhalasztásának valódi költségeivel. A kérdés nem az, hogy lokalizáljon-e, hanem az, hogy már az elejétől kezdve megfelelően építi-e fel a rendszert, vagy később 5–7-szer többet fizet az utólagos átalakításért.

Minden olyan funkció, amelyet az i18n-infrastruktúra nélkül bocsátasz ki, olyan funkció, amelyet később újra kell fejlesztened. Minden olyan piac, amelyre késve lépsz be, olyan piac, amelyet a versenytársak fognak meghódítani.

A legokosabb alapítók nem tekintik a lokalizációt a növekedés gátjának. Úgy látják, hogy ez az alapja a globális növekedésnek.