Nemzetköziesítési konzultáció: Javítsa, ami eltörik, tervezze meg, mi jön ezután
Ön már tudja, hogy az i18n nehéz. Láttam a tüneteket: összeomló RTL-elrendezések, a gombokból kifolyó német szöveg, rossz nyelvű API-válaszok, és az indítást követő heteken belül szinkronból kicsúszó fordítások. Nem árulok csodaszereket. Segítek kibogozni azt a konkrét káoszt, amiben a csapata van — és olyan rendszereket építeni, amelyek nem ugyanúgy törnek el kétszer.
„Ezt korábban kellett volna megterveznünk"
Az architektúraadó, amit most fizet
Angolul indított. Működött. Aztán hozzáadta a franciát „csak a nyitóoldalhoz". Most azért van itt, mert…
Az Ön kódbázisában lang= ellenőrzések vannak szétszórva 47 fájlban
A termékmenedzserek megkérdezik: „tudunk A/B tesztelni szöveget?", a mérnökség pedig azt mondja: „nem, átírás nélkül"
Önnek három különböző fordítási munkafolyamata van, és egyik sem működik megbízhatóan
Amit láttam eltörni:
- Csapatok, amelyek több mint 6 hónapot töltenek azzal, hogy utólag beépítsék az i18n-t egy Next.js alkalmazásba, mert a stringek a komponensekben voltak beégetve
- A fordításfájlok kiesnek a szinkronból, mert a fejlesztők nem tudják, melyik fájlt kell frissíteni
- „Lokalizációs befagyasztás" időszakok a kiadások előtt, mert senki sem bízik a fordítási folyamatban
- Ellenállás bármilyen lefordított tartalom megváltoztatásával szemben, mert a munkafolyamat annyira fájdalmas
Amiben segítek:
- Refaktorálási stratégiák, amelyek engedik az i18n bevezetésének inkrementális megvalósítását (nem követelem, hogy „álljon le mindennel, és írja újra")
- Folyamattervezés a fordítások szinkronban tartásához a fejlesztés blokkolása nélkül
- Architektúra-áttekintések annak azonosítására, hogy a jelenlegi megközelítés hol fog eltörni 10+ nyelvnél
Az i18n architektúra, nem funkció. Később hozzáadni olyan, mintha csak azután döntene a pince mellett, hogy már felépítette a házat.
Segítek kiásni a pincét – vagy eldönteni, hogy egyáltalán szükség van-e rá.
RTL mindent eltör
Az Ön felhasználói felülete nem arabra, héberre vagy urdura lett tervezve
Átváltotta a dir=„rtl" beállítást, és nézte, ahogy az elrendezése felrobban:
Amit láttam:
- 200+ komponensből álló dizájnrendszerek, amelyek közül csak 12 kezeli megfelelően az RTL-t.
- Csapatok, amelyek a float: left értéket használják a logikai tulajdonságok helyett, és így minden új funkcióban RTL hibákat hoznak létre
- Felugrók és modális ablakok, amelyek komponensspecifikus RTL felülbírálásokat igényelnek
- „RTL support"-ot állító frameworkök, amelyek csak az elrendezés irányát fordítják meg, de eltörik az elhelyezési logikát
Amiben segítek:
- CSS logikai tulajdonságok migrációja (margin-inline-start a margin-left helyett)
- Dizájnrendszer-auditok az RTL aknák kiszűrésére még élesítés előtt.
- Keretrendszer-specifikus útmutatás (Tailwind, shadcn, MUI) RTL-első stíluskezeléshez.
Az RTL-hibák kézi javítása minden komponensben fenntarthatatlan. Az RTL-támogatást rendszerszintűvé teszem, nem állandó tűzoltássá.
„A német szöveg eltörte a gombunkat"
Fordításra nem épített felhasználói felület
Az angol elfér. A német nem. Az Ön tervezése ezt feltételezte:
Aztán lefordította németre, finnre vagy thaira, és rájött:
Gombok szó közben levágva
Táblázatok soronkénti vízszintes görgetéssel
Az olvashatatlan blokkokba tördelődő szöveg
A nem latin szöveg levágódik, mert a tárolók fix szélességűek.
Amiben segítek:
- Rugalmas UI-minták, amelyek alkalmazkodnak a tartalomhosszhoz
- Karaktermennyiség-tervezés (tudva, hogy a német 30 %-kal bővül, a thai nem használ szóközöket)
- Tipográfiai rendszerek, amelyek törés nélkül kezelik a CJK-t, az arabot és a dévanágarit
Segítek olyan felületet építeni, amely túléli a fordítást – még azelőtt, hogy kifizetne 10 000 szót, ami végül nem fér el.
Nincs szüksége előadásra arról, miért fontos az i18n. Olyan emberre van szüksége, aki hajnali 2-kor hibakereste a RTL felugró ablakait, vitatkozott a termékcsapattal a karakterkeretekről, és olyan fordítási folyamatokat tervezett, amelyek tényleg működnek
A buktatók, amelyekről senki sem figyelmeztette
Háborús történetek azoktól a csapatoktól, akik már átélték
Ezek nem elméletiek. Ezek olyan dolgok, amelyek eltörtek gyártásban:
Többes szám ragozásának pokla
Angol: „1 elem" vs „2 elem"
Lengyel: „1 przedmiot" / "2 przedmioty" / „5 przedmiotów" (3 többes számú alak)
Arab: 6 többes számú alak
Az Ön count === 1 ? 'elem' : 'elemek' logikája már nem működik.
Dátum-/időkáosz
A dátumokat a toLocaleDateString()-val formázta. Aztán a japán felhasználók a CSV-exportokban „2025年2月9日" formátumot láttak, és az Excel lefagyott.
API nyelvi eltérés
Az Ön frontendje franciát kér. Az Ön API-ja angolt ad vissza, mert az auth token nem tartalmaz területi beállítást. Most vegyes nyelvű felhasználói felülete van, és a felhasználók azt gondolják, hogy ez egy hiba.
Pszeudo-lokálé tesztelése
Nem tesztelt a [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] szöveggel, mielőtt gyártásba ment volna. Most a lengyel oldala használhatatlan.
A láthatatlan feltételezés
Azt feltételezte, hogy a stringek az egyetlen dolog, amit fordítani kell. Aztán beleütközött a dátumokba, számokba, pénznemekbe, rendezésbe, keresésbe – mindenbe, aminek területi beállításonként eltérő a viselkedése.
Amiben segítek:
- ICU MessageFormat-megvalósítás (kezeli a többes számot, a nemet, a kontextust)
- API i18n minták (nyelvi egyeztetés, tartalék stratégiák)
- QA-folyamatok, amelyek még azelőtt elkapják ezeket a problémákat, hogy a fordítóügynökségek megtennék
A munkafolyamat a nehéz rész
Hogyan tartja szinkronban a 8 nyelvet, amikor naponta szállít?
Ön rájött a technológiára. Most a folyamatnál elakadt:
A fejlesztők új angol stringekkel egyesítik a kódot. A fordítások 2 hét késésben vannak. A felhasználók félig lefordított felhasználói felületet látnak.
Nem tudja, mely stringeket biztonságos törölni (használják őket? le vannak fordítva? épp egy ügynökségnél vannak folyamatban?)
A termék frissíteni akarja a szöveget. Senki sem tudja, hogy a „Submit" „Send"-re változtatása el fogja-e törni a 12 nyelvet.
A fordítási fájlok hetekig nincsenek szinkronban az éles verzióval
Kérdések, amelyeket a csapatok feltesznek nekem:
Amit láttam eltörni:
- Gitbe becheckelt fordítási fájlok, amelyek eltérnek a gyártásbeli stringektől
- „Ne nyúljon a spanyol fájlhoz" figyelmeztetések, mert senki sem tudja, mit biztonságos megváltoztatni
- A funkciók angolul indulnak, aztán 6 hónappal később lefordítják (ha egyáltalán)
Amiben segítek:
- Fordítási folyamat tervezése (mikor használ i18n-könyvtárakat, mikor használ TMS-t, mikor használ AI-t)
- Git-munkafolyamatok a forrásstringek és a fordítások szinkronban tartásához
- Automatizálás, amely blokkolja a PR-eket, ha az új stringek nincsenek fordításra megjelölve
A technológiai rész megoldható. A munkafolyamat a szűk keresztmetszet. Olyan munkafolyamatokat tervezek, amelyek fenntartásához nincs szükség hőstettekre.
Csapatok, amelyekkel dolgoztam
Globális termékek, regionális szakértelem
LINE (Japán, Tajvan, Thaiföld)
Üzenetküldő platform, amely három fő kelet-ázsiai piacon működik. A CJK karakterkezelés, a platform-ökoszisztéma integrációja és a Japán, Tajvan, valamint Thaiföld közti eltérő felhasználói élményelvárások kapcsán dolgoztam kihívásokon.
KakaoTalk (Dél-Korea)
Korea domináns üzenetküldő platformja. A koreai piacspecifikus termékkövetelményeken dolgoztam, beleértve a felhasználói felületben elvárt nyelvi formalitást és a platformintegrációs igényeket.
Change.org (196 ország, 20+ kiemelt nyelv)
Globális petíciós platform, ahol egyszerre számít a tartalom sebessége és minősége. Segítettem eligazodni a felhasználók által létrehozott politikai és társadalmi tartalmak fordítási munkafolyamatában, különböző piacokon.
Airbnb (220+ ország, 60+ nyelv)
Globális piactér összetett i18n-követelményekkel. Tanácsot adtam a többnyelvű bizalom- és biztonsági kihívások, valamint a platformfogalmak piacok közötti kulturális adaptációja kapcsán.
Intercom (30+ nyelv, globális B2B SaaS)
Ügyfélkommunikációs platform, amely globális vállalati ügyfeleket szolgál ki. A valós idejű ügyféltámogatási eszközök és a tudásbázis lokalizációjának termékinternacionalizációján dolgoztam.
Lilith Games (Kína, Japán, Korea, USA, EU)
Globálisan terjesztett címekkel rendelkező mobiljáték-kiadó. A tartalomlokalizációval és a regionális platformkövetelményekkel kapcsolatos piacspecifikus kihívásokon dolgoztam.
Piacok, ahol indítást végeztem:
Kelet-Ázsia (Japán, Korea, Kína):
CJK tipográfia, platformökoszisztéma-integráció, függőleges szöveg támogatása
Délkelet-Ázsia (Thaiföld, Vietnam, Indonézia):
Több írásrendszer támogatása, mobil-első felhasználói elvárások
MENA (arab nyelvű régiók):
RTL elrendezéskövetelmények, formális vs. köznyelvi nyelvi elvárások, kulturális tartalomadaptáció
Európa:
24 hivatalos nyelv, több országot érintő termékindítások
Amerikák:
Regionális nyelvi változatok (LATAM spanyol vs spanyolországi, brazil portugál), kétnyelvű piacok
Láttam, mi működik és mi nem ezeken a piacokon – nem elméletből, hanem olyan termékek szállításából, amelyekre valódi felhasználók támaszkodnak.
Javítsuk meg, ami eltörik
Nincs szüksége előadásra arról, miért fontos az i18n. Olyan emberre van szüksége, aki hajnali 2-kor hibakereste a RTL felugró ablakait, vitatkozott a termékcsapattal a karakterkeretekről, és olyan fordítási folyamatokat tervezett, amelyek tényleg működnek
Architektúra- és stratégiaáttekintés (1-2 hét):
Megmondom, mi fog elromlani, amikor hozzáadja a következő 3 nyelvet, és mennyibe fog kerülni kijavítani
Piaci indítástámogatás (4-8 hét):
Japánban indít/MENA/EU, és olyan szakértőkre van szüksége, akik már rendelkeznek tapasztalattal.
Folyamatban lévő partnerség:
Beágyazott tanácsadás, ahogy 2 nyelvről 20-re skáláz
Nem elméletelek. Priorizálok, tervezek és leszállítok.