Consulenza sull'internazionalizzazione: Risolviamo i problemi attuali, Pianifichiamo il futuro
Sai già che l'i18n è difficile. Ho visto i sintomi: layout RTL che si rompono, testo tedesco che trabocca dai pulsanti, risposte API nella lingua sbagliata e traduzioni che vanno fuori sincronia nel giro di poche settimane dal lancio. Non vendo soluzioni miracolose. Ti aiuto a districare il pasticcio specifico in cui si trova il tuo team e a costruire sistemi che non si rompano nello stesso modo due volte.
«Avremmo dovuto pianificarlo prima»
Il debito architetturale che stai pagando adesso
Hai lanciato in inglese. Ha funzionato. Poi hai aggiunto il francese «solo per la landing page». Ora sei qui perché:
La tua codebase ha controlli lang= sparsi in 47 file
I product manager chiedono «possiamo fare A/B test sul copy?» e l'engineering risponde «non senza riscrivere tutto»
Hai tre diversi flussi di lavoro per la traduzione e nessuno funziona in modo affidabile
Cosa ho visto non funzionare:
- Team che impiegano più di 6 mesi per integrare a posteriori l'i18n in un'app Next.js perché le stringhe erano inserite direttamente nei componenti
- File di traduzione non più sincronizzati perché gli sviluppatori non sanno quale file aggiornare.
- Periodi di «blocco della localizzazione» prima delle release perché nessuno si fida della pipeline di traduzione.
- Resistenza a modificare qualsiasi contenuto tradotto perché il processo è così macchinoso
Come posso aiutarti:
- Strategie di refactoring che permettono di adottare l'i18n in modo incrementale (non pretendo «fermate tutto e riscrivete»)
- Progettazione di processi per mantenere le traduzioni sincronizzate senza bloccare lo sviluppo.
- Revisioni dell'architettura per individuare dove il tuo approccio attuale andrà in crisi con più di 10 lingue
i18n è architettura, non una funzionalità. Cercare di aggiungerla dopo è come decidere che la tua casa ha bisogno di un seminterrato quando l'hai già costruita.
Ti aiuto a scavare quel seminterrato — o a decidere se ne hai davvero bisogno.
RTL Manda tutto in tilt
La tua UI non è stata pensata per arabo, ebraico o urdu
Hai cambiato dir=«rtl» e il layout è andato in frantumi:
Quello che ho riscontrato:
- Sistemi di design con oltre 200 componenti in cui solo 12 gestiscono correttamente RTL
- Team che usano float: left invece delle proprietà logiche, creando bug RTL a ogni nuova funzionalità
- Popover e modali che richiedono override RTL specifici per ogni componente
- Framework che dichiarano di supportare «RTL» ma si limitano a invertire la direzione del layout compromettendo la logica di posizionamento
Come posso aiutarti:
- Migrazione alle proprietà logiche CSS (margin-inline-start al posto di margin-left)
- Audit dei sistemi di design per individuare le mine RTL prima del rilascio
- Guida specifica per framework (Tailwind, shadcn, MUI) per lo styling RTL-first
Correggere manualmente i bug RTL in ogni componente non è sostenibile. Rendo il supporto RTL sistematico, non una battaglia continua.
«Il testo tedesco ha rotto il nostro pulsante»
UI non pensata per la traduzione.
L'inglese ci sta. Il tedesco no. Il tuo design dava per scontato:
Poi hai tradotto in tedesco, finlandese o thailandese e hai scoperto:
I pulsanti vengono tagliati a metà parola
Tabelle con scorrimento orizzontale su ogni riga
Testo che va a capo in blocchi illeggibili
Il testo non latino viene troncato perché i contenitori hanno larghezze fisse
Come posso aiutarti:
- Pattern di UI elastici che si adattano alla lunghezza del contenuto
- Pianificazione del character budget (sapendo che il tedesco si espande del 30 % e il thai non usa gli spazi)
- Sistemi tipografici che gestiscono CJK, l'arabo e il devanagari senza problemi
Ti aiuto a costruire UI che resiste alla traduzione—prima che tu abbia pagato per 10.000 parole che non ci stanno.
Non hai bisogno di una lezione sul perché l'i18n è importante. Hai bisogno di qualcuno che abbia fatto il debug dei popover RTL alle 2 di notte, che abbia litigato con il product sui budget di caratteri e che abbia progettato pipeline di traduzione che funzionano davvero.
Le insidie di cui nessuno ti ha avvertito
Storie dal fronte di team che ci sono passati
Non sono teorie. Sono cose che si sono rotte in produzione:
L'inferno della pluralizzazione
Inglese: «1 item» vs «2 items»
Polacco: «1 przedmiot» / «2 przedmioty» / «5 przedmiotów» (3 forme plurali)
Arabo: 6 forme plurali
La tua logica count === 1 ? 'item' : 'items' non funziona più.
Caos di date e orari
Hai formattato le date con toLocaleDateString(). Poi gli utenti in Giappone hanno visto «2025年2月9日» nelle esportazioni CSV ed Excel è andato in tilt.
Discrepanza linguistica dell'API
Il tuo frontend richiede il francese. La tua API restituisce l'inglese perché il token di autenticazione non include il locale. Risultato: un'interfaccia multilingue involontaria e utenti convinti che si tratti di un bug.
Test con pseudo-locale
Non hai testato con [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] prima di andare in produzione. Ora il tuo sito polacco è inutilizzabile.
Il presupposto invisibile
Pensavi che solo le stringhe avessero bisogno di traduzione. Poi ti sei imbattuto in date, numeri, valute, ordinamento, ricerca—tutto ha un comportamento specifico per ogni locale.
Come posso aiutarti:
- Implementazione di ICU MessageFormat (gestisce plurali, genere e contesto)
- Pattern i18n per le API (negoziazione della lingua, strategie di fallback)
- Processi di QA che individuano questi problemi prima delle agenzie di traduzione.
Il flusso di lavoro è la vera sfida
Come si mantengono 8 lingue sincronizzate quando si rilascia ogni giorno?
La parte tecnica l'hai risolta. Ora sei bloccato sul processo:
Gli sviluppatori integrano codice con nuove stringhe in inglese. Le traduzioni sono in ritardo di 2 settimane. Gli utenti vedono un'UI tradotta a metà.
Non sai quali stringhe si possono eliminare in sicurezza (sono utilizzate? tradotte? in lavorazione presso un'agenzia?)
Il team di prodotto vuole aggiornare un testo. Nessuno sa se cambiare «Invia» in «Spedisci» comprometterà 12 lingue.
I file di traduzione rimangono non sincronizzati con la produzione per settimane
Domande che i team mi fanno:
Cosa ho visto non funzionare:
- File di traduzione in git che divergono dalle stringhe in produzione
- Avvisi del tipo «non toccare il file in spagnolo» perché nessuno sa cosa si possa modificare senza rischi
- Funzionalità lanciate in inglese, poi tradotte 6 mesi dopo (se mai)
In cosa posso aiutare:
- Progettazione della pipeline di traduzione (quando usare librerie i18n, quando usare TMS, quando usare l'IA)
- Flussi di lavoro Git per mantenere sincronizzate le stringhe sorgente e le traduzioni
- Automazione che blocca le PR se le nuove stringhe non sono contrassegnate per la traduzione
La tecnologia è un problema risolvibile. Il flusso di lavoro è il vero ostacolo. Progetto flussi di lavoro che non richiedono eroismi per essere mantenuti.
Team con cui ho lavorato
Prodotti globali, competenza regionale
LINE (Giappone, Taiwan, Thailandia)
Piattaforma di messaggistica attiva in 3 mercati principali dell'Asia orientale. Ho affrontato sfide specifiche legate alla gestione dei caratteri CJK, all'integrazione nell'ecosistema della piattaforma e alle diverse aspettative sull'esperienza utente tra Giappone, Taiwan e Thailandia.
KakaoTalk (Corea del Sud)
La piattaforma di messaggistica dominante in Corea. Ho affrontato i requisiti di prodotto specifici del mercato coreano, tra cui le aspettative di formalità linguistica nell'UI e le esigenze di integrazione della piattaforma.
Change.org (196 paesi, oltre 20 lingue prioritarie)
Piattaforma globale per petizioni, dove velocità e qualità dei contenuti sono entrambe fondamentali. Ho contribuito a gestire il flusso di lavoro di traduzione per contenuti politici e sociali generati dagli utenti in mercati diversi.
Airbnb (oltre 220 paesi, oltre 60 lingue)
Marketplace globale con requisiti i18n complessi. Consulenza sulle sfide legate a fiducia e sicurezza in più lingue e sull'adattamento culturale dei concetti della piattaforma nei vari mercati.
Intercom (oltre 30 lingue, SaaS B2B globale)
Piattaforma di comunicazione con i clienti al servizio di aziende globali. Ho lavorato sull'internazionalizzazione del prodotto per strumenti di supporto in tempo reale e sulla localizzazione della knowledge base.
Lilith Games (Cina, Giappone, Corea, USA, UE)
Editore di giochi per dispositivi mobili con titoli distribuiti a livello globale. Ho affrontato le sfide specifiche di ciascun mercato relative alla localizzazione dei contenuti e ai requisiti regionali della piattaforma.
Mercati in cui ho lanciato prodotti:
Asia orientale (Giappone, Corea, Cina):
Tipografia CJK, integrazione nell'ecosistema della piattaforma, supporto per il testo verticale
Sud-est asiatico (Thailandia, Vietnam, Indonesia):
Supporto multi-script, esperienza utente mobile-first
MENA (regioni arabofone):
Requisiti di layout RTL, aspettative linguistiche formali e colloquiali, adattamento culturale dei contenuti
Europa:
24 lingue ufficiali, lanci di prodotto in più paesi
Americhe:
Varianti linguistiche regionali (spagnolo latinoamericano vs spagnolo europeo, portoghese brasiliano), mercati bilingui
Ho visto con i miei occhi cosa funziona e cosa no in questi mercati — non in teoria, ma lanciando prodotti su cui gli utenti fanno davvero affidamento.
Risolviamo ciò che non funziona
Non hai bisogno di una lezione sul perché l'i18n è importante. Hai bisogno di qualcuno che abbia fatto il debug dei popover RTL alle 2 di notte, che abbia litigato con il product sui budget di caratteri e che abbia progettato pipeline di traduzione che funzionano davvero.
Revisione di architettura e strategia (1-2 settimane):
Ti indico cosa si romperà quando aggiungerai le tue prossime 3 lingue e quanto costerà risolvere il problema
Supporto al lancio sul mercato (4-8 settimane):
Stai per lanciare in Giappone/MENA/UE e hai bisogno di esperti che l'hanno già fatto
Partnership continuativa:
Consulenza integrata nella crescita da 2 a 20 lingue
Niente teoria. Faccio triage, roadmap e messa in produzione.