Wanneer is het perfecte moment om met lokalisatie te beginnen?

"We zullen lokaliseren nadat de product-markt fit is." Deze enkele zin kost softwarebedrijven gemiddeld 23 tot 42% van hun ontwikkelingsinspanningen en vertraagt ​​de wereldwijde lancering met 6 tot 18 maanden. De verborgen kosten zijn niet de vertalingen; het zijn de technische schulden die u vandaag de dag in elke regel code inbouwt.

De brutale wiskunde: nu bouwen versus later aanpassen

• 5-7x - Kostenvermenigvuldiger voor het achteraf aanpassen van lokalisatie versus het inbouwen ervan
• 23-42% - Verspilde ontwikkelingstijd aan technologieschulden door vertraagde lokalisatie
• 6-18 maanden - Gemiddelde vertraging bij het betreden van de wereldmarkt bij lokalisatie na de lancering

Volgens onderzoek van McKinsey en de Localization Industry Standards Association verspillen organisaties tussen de 23% en 42% van hun ontwikkelingsinspanningen door het omgaan met technische schulden. Wanneer lokalisatie als een bijzaak wordt beschouwd, wordt deze schuld exponentieel groter.

Dit betekent in de praktijk het volgende: als uw team drie maanden besteedt aan het bouwen van een functie met hardgecodeerde tekenreeksen, lay-outaannames en locale-ongevoelige opmaak, bent u 15 tot 21 maanden kwijt aan het ontwarren ervan als u besluit om mondiaal te gaan werken. Dat is exclusief de vertaaltijd; dat is alleen het technische werk om uw codebase lokaliseerbaar te maken.

De technische schuldratio die uw lot bepaalt

De Technical Debt Ratio meet de kosten om uw codebase te repareren versus de kosten om deze helemaal opnieuw op te bouwen. Uit gegevens uit de sector blijkt dat een TDR van meer dan 5% aangeeft dat er dringend actie nodig is. Voor bedrijven die internationalisering vertragen, bedraagt ​​de lokalisatiespecifieke TDR vaak meer dan 40%.

Echt voorbeeld: Een SaaS-startup met 50.000 regels code en hardgecodeerde Engelse strings heeft naar schatting twee weken nodig om 'vertalingen toe te voegen'. De daadwerkelijke inspanning kostte de ontwikkelaar zes maanden tijd om tekenreeksen te externaliseren, kapotte lay-outs te repareren, locale-bewuste opmaak te implementeren en edge-cases op te lossen. Kosten: ongeveer $ 180.000 aan engineeringtijd. Als ze vanaf de eerste dag internationalisering hadden doorgevoerd, zouden de extra kosten ongeveer 25.000 dollar zijn geweest.

Het perfecte moment om te beginnen: voordat u regel één schrijft

Het onderzoek is eenduidig. Bedrijven die lokalisatie vanaf het begin integreren, zijn sneller bezig, geven minder uit en veroveren mondiale markten, terwijl de concurrenten hun codebases nog steeds aan het herstructureren zijn.

Internationalisering (i18n): uw fundament

Internationalisering is het ontwerpen van uw software om zich aan te passen aan meerdere talen en regio's zonder dat daarvoor technische wijzigingen nodig zijn. Dit is geen functie die u toevoegt; het is een mentaliteit die u vanaf architectuurdag nul aanneemt.

Kernprincipes van i18n (bouw deze vanaf dag één in):

• Externaliseer alle gebruikersgerichte tekst: Hardcodeer nooit tekenreeksen in uw broncode. Gebruik bronbestanden (JSON, YAML, XLIFF) die inhoud van logica scheiden.
• Unicode overal: Ondersteuning van dubbelbytetekens, van rechts naar links geschreven scripts (Arabisch, Hebreeuws) en complexe scripts (Thais, Devanagari).
• Lokaalbewuste opmaak: Datums, tijden, getallen, valuta's en eenheden moeten dynamisch worden aangepast op basis van de landinstelling van de gebruiker.
• Flexibele UI-indelingen: Duitse tekst wordt 30% groter dan Engelse. Japanse contracten. Uw gebruikersinterface moet het uitzetten/inkrimpen van tekst verwerken zonder te breken.
• Vermijd aaneengeschakelde tekenreeksen: "Je hebt " + aantal + " berichten"-pauzes in talen met verschillende grammaticaregels. Gebruik in plaats daarvan geparametriseerde tekenreeksen.
• Ontwerp voor bidirectionaliteit: Uw lay-out moet zowel tekstweergave van links naar rechts als van rechts naar links ondersteunen zonder opnieuw te ontwerpen.

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

De vier timingtriggers: wanneer lokalisatie dringend wordt

Hoewel het ideale antwoord 'vanaf het begin' is, zijn er specifieke momenten waarop lokalisatie verschuift van 'nice-to-have' naar 'existentiële noodzaak'.

Trigger 1: Onverwacht internationaal verkeer

U controleert Google Analytics en ontdekt dat 15-30% van uw verkeer afkomstig is van markten die u niet heeft getarget. Deze gebruikers vinden u, maar uw conversiepercentage op die markten is 60-80% lager dan op uw thuismarkt.

Actie: Dit is een bevestiging dat er vraag bestaat. Als u wacht met lokaliseren, zullen concurrenten op die markten gelokaliseerde alternatieven bouwen en de door u ontdekte kansen benutten.

Trigger 2: Product-markt fit bereikt

U heeft een product-marktmatch gevonden in uw oorspronkelijke markt. De retentie is groot, het klantverloop is laag en gebruikers pleiten voor uw product. Dit is het moment om uit te breiden, niet zes maanden later.

Actie: Start nu een continue lokalisatie-infrastructuur. Bedrijven als Notion wachtten tot ze grote gebruikersgemeenschappen in Japan en Korea opmerkten, en lokaliseerden zich vervolgens snel. Tegenwoordig bevindt 70% van de gebruikers van Notion zich buiten de VS.

Trigger 3: Mijlpalen voor fondsenwerving of inkomsten

U heeft een belangrijke ronde binnengehaald of een omzetmijlpaal bereikt die een versnelde groei vereist. Beleggers verwachten internationale expansie. Het uitstellen van de lokalisatie vertraagt ​​die groei.

Actie: Wijs 15-20% van de technische middelen toe aan het bouwen van de i18n-infrastructuur voordat u de verkoop en marketing naar nieuwe markten opschaalt.

Trigger 4: Concurrentiedruk

Een concurrent heeft gelokaliseerde versies gelanceerd in belangrijke markten en wint aan populariteit. Hun gelokaliseerde product converteert gebruikers die u had kunnen vastleggen.

Actie: Dit is de duurste trigger. Je bent nu aan het retrofitten onder tijdsdruk, wat de kosten 8-10x verhoogt in vergelijking met het vanaf het begin bouwen van i18n.

Het Agile Localization Framework: sprints, geen watervallen

De traditionele aanpak – alles opbouwen en dan alles vertalen – is dood. Moderne softwareontwikkeling maakt gebruik van agile sprints. Uw lokalisatieworkflow moet dit tempo aanhouden, anders wordt het een knelpunt dat de mondiale snelheid tenietdoet.

Continue lokalisatie: wat het eigenlijk betekent

Continue lokalisatie integreert vertaalworkflows in flexibele ontwikkelingscycli, zodat gelokaliseerde versies gelijktijdig met releases in de brontaal worden verzonden. In plaats van dat vertaling een gevecht na de release is, is het een parallel proces dat in elke sprint is ingebouwd.

Hoe het in de praktijk werkt:

1. Sprintplanning (week 0): Lokalisatievereisten worden vooraf geïdentificeerd. Productmanagers en lokalisatieteams stemmen af ​​welke inhoud vertaald moet worden en welke markten prioriteit krijgen.
2. Ontwikkeling (week 1-2): Ontwikkelaars bouwen functies met externe tekenreeksen. Wanneer nieuwe inhoud wordt vastgelegd in de codebase, wordt deze automatisch geëxtraheerd en verzonden naar vertaalbeheersystemen (TMS).
3. Vertaling (parallel proces): Terwijl ontwikkelaars doorgaan met coderen, werken vertalers aan nieuwe strings. Context wordt geboden via schermafbeeldingen, UI-beschrijvingen en opmerkingen van ontwikkelaars.
4. QA-integratie (week 2): Vertaalde tekenreeksen worden weer samengevoegd in de codebase. Taalkundige QA vindt plaats naast functionele QA. Testers controleren op UI-onderbrekingen, tekstoverloop en contextuele nauwkeurigheid.
5. Implementatie (einde week 2): Alle taalversies worden gelijktijdig geïmplementeerd. De Engelse, Duitse, Japanse en Spaanse versies worden samen weergegeven, niet opeenvolgend.

Sprintplanning voor lokalisatie: het ontbrekende stuk

De meeste ontwikkelingsteams plannen sprints zonder tot het laatste moment rekening te houden met lokalisatie. Dit zorgt voor chaos. Hier ziet u hoe goed presterende teams lokalisatie integreren in de sprintplanning:

1. Definieer lokalisatie als onderdeel van "Definition of Done"

Een functie is pas compleet nadat deze in alle doeltalen is getest. Dit dwingt teams om bij sprintschattingen rekening te houden met de lokalisatietijd.

2. Creëer lokalisatie-gebruikersverhalen

Beschouw lokalisatie als een gebruikersverhaal: "Als Duitse gebruiker moet ik alle UI-elementen vertaald hebben, zodat ik het product in mijn moedertaal kan gebruiken." Wijs verhaalpunten toe en houd de snelheid bij.

3. Betrek lokalisatieteams bij sprintplanningsvergaderingen

Lokalisatiemanagers wonen de sprintplanning bij om het vertaalvolume te identificeren, complexe tekenreeksen te markeren en tijdlijnen af te stemmen. Dit voorkomt verrassingen.

4. Automatiseer de extractie en levering van inhoud

Gebruik CI/CD-integraties die automatisch nieuwe tekenreeksen uit Git-commits extraheren en deze naar vertalers sturen. Handmatige overdracht via e-mail of spreadsheets zijn knelpunten die de agile snelheid ondermijnen.

5. Bouw vertaalbuffers in sprints

Niet elke sprint vereist een zware vertaling. Sommige sprints richten zich op backend-werk met minimale UI-wijzigingen. Gebruik deze sprints om vertaalschulden in te halen of bestaande vertalingen te verfijnen.

Teamstructuur: wie doet de lokalisatie eigenlijk?

Lokalisatie is geen taak voor één persoon. Het vereist een cross-functionele samenwerking tussen ontwikkelaars, productmanagers, technische schrijvers, vertalers en QA-testers. Dit is de ideale teamstructuur:

De vraag over de grootte van het lokalisatieteam

Hoeveel mensen heb je eigenlijk nodig? Het hangt af van uw ontwikkelingssnelheid en marktambities:

• Vroeg stadium (pre-PMF): 0-1 lokalisatiespecialist. Ontwikkelaars hanteren i18n-architectuur. Gebruik TMS-platforms met ingebouwde vertaalnetwerken voor vertaalwerk.
• Post-PMF (2-5 talen): 1 lokalisatiemanager + externe vertaalleveranciers. De manager coördineert de workflows, beheert TMS en waarborgt de kwaliteit.
• Schaalfase (5-15 talen): 1-2 lokalisatiemanagers + toegewijde taalkundigen voor topmarkten + externe leveranciers voor long-tail-talen. Overweeg om reviewers in het land in te huren.
• Enterprise (15+ talen): Volledig lokalisatieteam met regionale managers, interne taalkundigen, QA-specialisten en lokalisatie-ingenieurs.

De rol van de technisch schrijver: schrijven voor lokalisatie

Technische schrijvers zijn de onbezongen helden van efficiënte lokalisatie. Inhoud die duidelijk in de brontaal is geschreven, wordt sneller, nauwkeuriger en tegen lagere kosten vertaald.

Richtlijnen voor lokalisatievriendelijk schrijven:

• Gebruik eenvoudige, directe taal: Vermijd idiomen, culturele verwijzingen en complexe zinsstructuren. 'Klik op de knop' vertaalt zich beter dan 'Druk op de knop om het proces een vliegende start te geven'.
• Wees consistent met de terminologie: Gebruik overal dezelfde term voor hetzelfde concept. Wissel niet af tussen 'verwijderen', 'verwijderen' en 'prullenbak'. Kies er één.
• Houd zinnen kort: Eén idee per zin. Lange, samengestelde zinnen met meerdere clausules zijn vertaalnachtmerries.
• Vermijd humor en woordspelingen: Woordspelingen, grappen en slimme woordspelingen worden zelden vertaald. Ze dwingen vertalers om te kiezen tussen letterlijke vertaling (verliest de grap) of creatieve aanpassing (introduceert risico's).
• Documentcontext voor vertalers: Voeg opmerkingen toe waarin wordt uitgelegd waar tekenreeksen verschijnen, wat ze doen en eventuele beperkingen (tekenlimieten, toonvereisten).
• Woordenlijsten maken en onderhouden: Definieer de belangrijkste termen één keer. Zorg ervoor dat vertalers consistente vertalingen gebruiken voor productspecifieke terminologie.

Succesverhalen uit de praktijk: bedrijven die de juiste timing hebben

Begrip: vroeg gelokaliseerde, vastgelegde mondiale groei

Notion merkte een onverwachte aantrekkingskracht op in Japan en Korea, markten waarop ze zich niet hadden gericht. In plaats van te wachten, lokaliseerden ze zich snel nadat de product-markt fit was. Ze hadden al Contentful voor contentbeheer, dus de integratie met Smartling duurde slechts een week.

Tegenwoordig ondersteunt Notion 19 talen en dialecten, waarbij ongeveer 70% van de gebruikers buiten de VS ligt. De vroege lokalisatie-investeringen positioneerden ze vanaf het begin als een mondiaal product, en niet als een Amerikaans product dat probeerde uit te breiden.

Airbnb: lokalisatie als concurrentiestrategie

Airbnb benaderde China in de wetenschap dat ze te maken hadden met hevige lokale concurrentie (Tujia, Xiaozhu) en strikte regelgevende belemmeringen. Hun lokalisatiestrategie ging verder dan vertaling:

• Omgedoopt tot "Aibiying" (爱彼迎): Dit betekent 'elkaar met liefde verwelkomen' - cultureel resonerend, niet alleen fonetisch vergelijkbaar.
• Geïntegreerde WeChat en Alipay: Chinese gebruikers gebruiken geen creditcards voor online betalingen. Airbnb heeft de betalingsinfrastructuur aangepast aan lokaal gedrag.
• Opnieuw ontworpen gebruikersinterface voor Chinese voorkeuren: Terminologie aangepast van 'Gastheer' en 'Gast' tot 'Thuispartner' en 'Huurder op korte termijn' om aan te sluiten bij de culturele verwachtingen.
• Gelokaliseerde vermeldingsbeschrijvingen: Verschoven van ‘luxe voorzieningen’ naar ‘gezellig verblijf’ en ‘authentieke lokale ervaring’ – waar Chinese reizigers eigenlijk naar zoeken.

Resultaat: 700% groei van het Chinese klantenbestand in één jaar na lokalisatie.

Spotify: culturele lokalisatie, niet alleen vertaling

De lancering van Spotify in India laat zien dat lokalisatie productaanpassing omvat, en niet alleen taalvertaling:

• Meertalige ondersteuning: Hindi, Tamil, Punjabi en andere talen zijn rechtstreeks in de app geïntegreerd, niet als een enkele 'Indiase' versie, maar als afzonderlijke, gelokaliseerde ervaringen.
• Gelokaliseerde afspeellijsten: Bouwde regiospecifieke algoritmen voor het ontdekken van muziek die lokale artiesten, genres en luistergewoonten begrepen.
• Prijsaanpassing: Betaalbare plannen geïntroduceerd die overeenkwamen met de lokale koopkracht, en niet alleen USD naar INR omzetten.

Spotify wachtte niet totdat ze ‘genoeg’ Indiase gebruikers hadden om lokalisatie te rechtvaardigen. Ze hebben zich in de eerste plaats gelokaliseerd om die gebruikers te werven.

De kostenverdeling: wat u daadwerkelijk zult uitgeven

Laten we het over echte cijfers hebben. Wat kost lokalisatie eigenlijk als je het vanaf het begin doet, in plaats van achteraf achteraf aan te passen?

Kortom: Voor een typisch SaaS-product met 100.000 regels code en 10.000 vertaalbare strings kost het bouwen van i18n vanaf de eerste dag ongeveer $30.000-50.000 aan incrementele engineeringtijd. Het achteraf aanpassen van datzelfde product na de lancering kost $ 200.000-500.000 aan engineering, vertaling, kwaliteitscontrole en vertraagde omzetkansen.

Veelvoorkomende bezwaren (en waarom ze verkeerd zijn)

"We weten niet eens of ons product succesvol zal zijn op onze thuismarkt."

Dit is het meest voorkomende bezwaar, en het is gebaseerd op een valse veronderstelling: dat i18n dure overhead is die alleen loont als je mondiaal gaat.

Realiteit: Vanaf dag één bouwen met i18n kost 10-15% extra ontwikkeltijd. Dat is ongeveer één extra dag per sprint van twee weken. De discipline van het externaliseren van tekenreeksen, het gebruik van locale-bewuste opmaak en het ontwerpen van flexibele lay-outs verbetert de kwaliteit van de code zelfs als u nooit lokaliseert. Je vermijdt hardgecodeerde aannames, bouwt een meer modulaire architectuur en creëert onderhoudbare code.

De echte vraag is niet: 'Gaan we mondiaal gaan?' Het is: "Kunnen we het ons veroorloven om ons hele product opnieuw op te bouwen als we dat doen?"

"Lokalisatie kan wachten totdat we betalende klanten op die markten hebben."

Hierdoor ontstaat er een kip-en-ei-probleem. Het is minder waarschijnlijk dat klanten op internationale markten een conversie genereren als uw product niet gelokaliseerd is. Uw conversieratio op die markten zal 60-80% lager zijn dan die op uw thuismarkt, waardoor u tot de conclusie komt dat er 'niet genoeg vraag' is.

Maar die lage vraag is een artefact van slechte lokalisatie, en niet van daadwerkelijke desinteresse van de markt. Als u zich op de juiste manier lokaliseert, presteren deze markten met "weinig vraag" vaak beter dan uw aanvankelijke aannames.

Uit CSA-onderzoek blijkt dat 76% van de online consumenten het liefst producten koopt met informatie in hun moedertaal. Als uw product niet gelokaliseerd is, meet u niet de werkelijke vraag; u meet de tolerantie voor producten die alleen in het Engels beschikbaar zijn.

"We gebruiken gewoon Google Translate en ruimen het later op."

Machinevertaling is dramatisch verbeterd, maar is geen vervanging voor een goede lokalisatiestrategie. Dit is waarom:

• Context is belangrijk: 'Bank' kan een financiële instelling of een rivierrand betekenen. MT begrijpt de context niet zonder training.
• Culturele aanpassing is geen vertaling: Het lokaliseren van betaalmethoden, het aanpassen van kleurenschema's en het aanpassen van UI-stromen zijn geen zaken die MT afhandelt.
• De merkstem gaat verloren: MT produceert functionele tekst, geen overtuigende teksten die de persoonlijkheid van uw merk behouden.
• Wettelijke en regelgevende inhoud vereist menselijke beoordeling: Servicevoorwaarden, privacybeleid en nalevingsdocumenten moeten juridisch accuraat zijn. MT-fouten creëren aansprakelijkheid.

Dat gezegd hebbende, MT is waardevol voor eerste concepten, vertaling van door gebruikers gegenereerde inhoud en inhoud met een lage prioriteit. Maar het moet deel uitmaken van een workflow die menselijke beoordeling omvat, en geen vervanging zijn voor professionele lokalisatie.

Uw checklist voor de gereedheid voor lokalisatie

Gebruik deze checklist om te bepalen of u klaar bent om met lokalisatie te beginnen (of dat u eerst een i18n-infrastructuur moet bouwen):

Gereedheid van de infrastructuur:

• Alle gebruikersgerichte tekenreeksen worden geëxternaliseerd in bronbestanden (niet hardgecodeerd)
• Code ondersteunt Unicode en verwerkt multi-bytetekens correct
• Datum-, tijd-, getal- en valutanotatie maakt gebruik van locale-bewuste bibliotheken
• UI-indelingen kunnen tekstuitbreiding/-inkrimping verwerken (getest met Duits en Japans)
• Ondersteuning van rechts naar links taal is geïmplementeerd (of ontworpen)
• Tekenreeksaaneenschakeling wordt vermeden (in plaats daarvan worden geparametriseerde tekenreeksen gebruikt)
• Translation Management System (TMS) is geselecteerd of in evaluatie

Teambereidheid:

• Ontwikkelaars begrijpen de i18n-principes en zijn getraind in best practices
• Er wordt een lokalisatiemanager of puntpersoon toegewezen
• Voor de doelmarkten worden vertaalbureaus of interne taalkundigen geïdentificeerd
• Technische schrijvers creëren lokalisatievriendelijke inhoud
• Het QA-proces omvat het testen op UI-onderbrekingen in gelokaliseerde versies
• Sprintplanning omvat lokalisatie als onderdeel van "Definition of Done"

Strategiegereedheid:

• Doelmarkten krijgen prioriteit op basis van verkeersgegevens, marktomvang en concurrentie
• Er wordt budget toegewezen voor vertaling, tooling en mogelijke aanwerving
• Er zijn successtatistieken gedefinieerd (conversiepercentages, activering, retentie per markt)
• Voor doelmarkten worden wettelijke en nalevingsvereisten onderzocht
• De product-marktfit is gevalideerd in ten minste één markt

De timingparadox

Het beste moment om met de lokalisatie te beginnen was toen u uw eerste regel code schreef. Het op een na beste moment is nu: voordat u uw volgende regel code schrijft.

Elke dag dat u de bouw van de i18n-infrastructuur uitstelt, is weer een dag waarop de technische schulden zich ophopen. Elke hardgecodeerde string is een nieuwe string die je moet ontwarren. Elke lay-out die uitgaat van de Engelse tekstlengte is een andere lay-out die u opnieuw moet ontwerpen.

De bedrijven die de wereldmarkt veroveren, zijn niet degenen met de beste vertaalbudgetten. Zij zijn degenen die vanaf dag één lokalisatie in hun DNA hebben ingebouwd, dus als de gelegenheid zich voordoet in Tokio, São Paulo of Berlijn, staan ​​ze klaar om te antwoorden in de lokale taal.

Het actieplan: wat u deze week moet doen

Als u dit leest en beseft dat u de lokalisatie heeft uitgesteld, kunt u het volgende onmiddellijk doen:

Als u nog niet met de ontwikkeling bent begonnen:

1. Architect voor i18n vanaf dag één: Kies frameworks met ingebouwde i18n-ondersteuning (React Intl, i18next, etc.).
2. Stel uw TMS in vóór uw eerste commit: Platforms zoals Lokalise, Crowdin of Phrase kunnen rechtstreeks met GitHub worden geïntegreerd.
3. Externaliseer alle strings onmiddellijk: Elke UI-tekenreeks, foutmelding en tooltip wordt in bronbestanden geplaatst, niet in de broncode.
4. Documenteer uw lokalisatiestrategie: Zelfs als u slechts op één markt lanceert, documenteer dan hoe u zich naar andere markten gaat uitbreiden.

Als je midden in de ontwikkeling bent:

1. Controleer uw codebase: Identificeer alle hardgecodeerde tekenreeksen. Geef prioriteit aan externaliserende tekenreeksen in gebruikersgerichte functies.
2. Maak een refactoring-roadmap: Wijs de komende drie tot zes maanden 20% van de sprintsnelheid toe aan de i18n-infrastructuur.
3. Begin met nieuwe functies: Alle nieuwe functies moeten i18n-compatibel zijn. Zo voorkom je dat je extra schulden maakt, terwijl je bestaande schulden afbetaalt.
4. Test met pseudo-lokalisatie: Genereer nepvertalingen met tekenuitbreiding om UI-pauzes te vinden vóór echte vertaling.

Als u al bent gestart:

1. Kwantificeer de technische schuld: Schat de inspanning die nodig is om uw codebase lokaliseerbaar te maken. Wees eerlijk over de kosten.
2. Geef prioriteit aan markten op basis van bestaand verkeer: Kijk eens naar Google Analytics voor markten waar u organisch verkeer krijgt, ondanks dat er geen lokalisatie is.
3. Voer een pilot uit met één markt: Kies een markt met veel potentieel en doe een volledige lokalisatiepilot. Dit zal alle verborgen uitdagingen onthullen.
4. Communiceer realistische tijdlijnen naar belanghebbenden: Het achteraf aanpassen van de lokalisatie duurt 6 tot 18 maanden, niet 2 weken. Schep vroeg verwachtingen.

Conclusie: de beslissing die uw mondiale toekomst definieert

U begrijpt nu de werkelijke kosten van het uitstellen van lokalisatie. De vraag is niet of je het moet lokaliseren, maar of je het vanaf het begin bouwt of vijf tot zeven keer meer betaalt om het later aan te passen.

Elke functie die u levert zonder i18n-infrastructuur is een functie die u opnieuw moet opbouwen. Elke markt die u uitstelt, is een markt die concurrenten zullen veroveren.

De slimste oprichters zien lokalisatie niet als een belasting op de groei. Zij zien het als de basis die mondiale groei mogelijk maakt.