La maggior parte delle aziende considera Wikipedia come una cosa sola: "vogliamo una pagina su Wikipedia." Ma Wikipedia non è un'unica enciclopedia — sono circa 340 enciclopedie separate, ognuna nella propria lingua, ognuna con la propria comunità di volontari, le proprie regole e la propria opinione su se la vostra azienda meriti un articolo. L'edizione inglese riceve la maggior parte dell'attenzione nelle sale riunioni occidentali. È anche quella che i vostri clienti a San Paolo, Riyadh, Giacarta e Kiev hanno meno probabilità di leggere.
Questa è la parte della conversazione sulla visibilità AI (intelligenza artificiale) che viene saltata. Le persone sono ossessionate dall'ottenere il Knowledge Panel (il pannello informativo) in inglese e dimenticano che un assistente AI che risponde a una domanda in portoghese, arabo, indonesiano o ucraino cerca prima fonti in quella lingua — e nella maggior parte dei casi, significa Wikipedia in portoghese, arabo, indonesiano o ucraino, nessuna delle quali ha mai sentito parlare di voi.
Questo articolo riguarda come fare bene il multilinguismo: non "tradurre la pagina inglese in quaranta lingue," che fallisce, ma una strategia deliberata costruita su un'unica entità Wikidata unificata, una lettura lucida delle regole indipendenti di ogni edizione e un elenco di priorità linguistiche guidato da dove si trova realmente il vostro mercato. È onesto riguardo ai costi e diretto sui modi in cui si può fallire, perché la versione multilingue di questo lavoro è quella in cui si spreca più denaro.
Perché la lingua conta più di quanto la maggior parte dei team immagini
Iniziate da come un large language model (modello linguistico di grandi dimensioni) risponde a una domanda. Quando un utente scrive in spagnolo, il modello non sta silenziosamente traducendo in inglese, recuperando fatti in inglese e ritraducendo. Sta attingendo agli schemi che ha appreso dal testo in lingua spagnola — e la fonte in lingua spagnola con il peso maggiore in quasi qualsiasi corpus di addestramento è la Wikipedia in spagnolo. Lo stesso vale per il tedesco, il giapponese, l'arabo, l'hindi e ogni altra edizione principale. Ogni Wikipedia in una data lingua è la fonte di riferimento per la fetta di quel modello in quella lingua.
Quindi un'azienda con un solido articolo su Wikipedia in inglese e niente altro è ben rappresentata quando qualcuno chiede a ChatGPT (il popolare assistente AI di OpenAI) di lei in inglese — ed è effettivamente invisibile, o peggio, erroneamente rappresentata, quando qualcuno fa la stessa domanda in turco. Il modello non ha un punto di riferimento in lingua turca per quell'entità. Declinerà, allucinando, o confonderà l'azienda con un'altra con un nome simile che ha una presenza in turco.
Google si comporta allo stesso modo a livello di entità. Un Knowledge Panel (pannello della scheda informativa) mostrato a un utente in Francia si basa su segnali in lingua francese; la riga della descrizione spesso proviene dall'incipit della Wikipedia francese, non da quella inglese. Se la Wikipedia francese non ha un articolo, quel campo torna a qualunque cosa Google riesca a recuperare — spesso niente di pulito, a volte un concorrente.
La conseguenza pratica: la visibilità su AI e nei motori di ricerca è locale, anche quando il vostro marchio è globale. Una singola pagina in inglese è una testa di ponte, non una campagna. Se i vostri ricavi provengono da dodici paesi, la vostra infrastruttura reputazionale esiste in circa uno di essi. Il divario tra "abbiamo una pagina su Wikipedia" e "siamo descritti correttamente in ogni mercato in cui vendiamo" è enorme, ed è esattamente il divario che costa accordi quando l'assistente AI di un potenziale cliente risponde: "Non ho trovato informazioni affidabili su quella società."
Come i sitelink e un'unica entità Wikidata unificano un marchio
Ecco il meccanismo che rende il multilinguismo coerente piuttosto che caotico. Ogni Wikipedia in una data lingua ha il proprio articolo sulla vostra azienda — prosa diversa, redattori diversi, elenchi di riferimenti diversi. Lasciati soli, questi sono quaranta pagine disconnesse che le macchine potrebbero o meno capire descrivere la stessa entità. La cosa che le collega è Wikidata (il database strutturato libero di Wikimedia).
Un singolo elemento Wikidata — un QID (identificatore univoco), l'indirizzo permanente e indipendente dalla lingua dell'entità — si trova al centro. Abbiamo scritto ampiamente su come funziona quel livello strutturato nel nostro articolo su Wikidata e il Knowledge Graph, ma l'aspetto multilingue è la parte che vale la pena sottolineare qui: il QID è lo stesso sia che l'interfaccia sia in inglese, giapponese o arabo. Q42 è Douglas Adams ovunque. Il QID della vostra azienda è la vostra azienda ovunque.
Collegati a quell'unico elemento ci sono i sitelink (collegamenti interwiki) — uno per ogni articolo di Wikipedia in una data lingua. Un sitelink è il collegamento formale che dice "questo elemento Wikidata corrisponde a questo articolo in questa edizione linguistica." Quando i vostri articoli in tedesco, spagnolo e giapponese si collegano tutti allo stesso QID, accadono tre cose:
- Le macchine sanno che sono la stessa entità. Google e i LLM che leggono uno qualsiasi di questi articoli possono risolvere in una singola identità con un singolo insieme di fatti strutturati. Nessuna confusione, nessuna duplicazione.
- La barra delle lingue interwiki si popola. I lettori e i crawler vedono che l'articolo esiste in N lingue — un segnale visibile di un'entità affermata e presente in più mercati piuttosto che una pagina occasionale.
- I fatti strutturati rimangono coerenti tra le edizioni. Data di fondazione, sede, sito web ufficiale, persone chiave, simbolo azionario — questi dati risiedono una volta nell'elemento Wikidata e alimentano ogni lingua. Correggete un fatto in un posto; è corretto ovunque.
Questa è l'architettura. Molti articoli in molte lingue, un'unica entità condivisa. Gli articoli portano la prosa e il caso di notabilità specifico per la lingua; l'elemento Wikidata porta l'identità e i fatti leggibili dalle macchine. Saltate il livello Wikidata e ottenete un mucchio di pagine che non si conoscono tra loro. Costruitelo correttamente e ottenete un'entità globale coerente che i motori di ricerca e i modelli AI possono descrivere accuratamente in qualsiasi lingua in cui vengono interrogati.
La trappola dell'indipendenza: ogni edizione fa le sue regole
Ora la parte che sorprende quasi ogni cliente, e il malinteso più costoso nel lavoro multilingue su Wikipedia: le edizioni linguistiche sono comunità indipendenti con regole indipendenti. Non esiste un'autorità centrale di Wikipedia che approva un articolo una volta e lo propaga. La Wikimedia Foundation gestisce i server; non gestisce le decisioni editoriali.
Ciò significa che un soggetto può avere un articolo fiorente in un'edizione ed essere cancellato a vista in un'altra. Concretamente:
- La Wikipedia inglese ha le linee guida sulla notabilità più sviluppate e probabilmente più rigide, con un apparato di cancellazione ampio, veloce e ben organizzato. Superare la soglia dell'inglese è un obiettivo alto.
- La Wikipedia tedesca è famosa per essere più rigida dell'inglese sugli articoli aziendali — la sua comunità ha una tolleranza particolarmente bassa per qualsiasi cosa che sembri promozionale, e i "Relevanzkriterien" (criteri di rilevanza) vengono applicati rigorosamente. Molte aziende che sopravvivono in inglese vengono rifiutate o cancellate in tedesco.
- Le edizioni di medie dimensioni variano enormemente. Alcune sono accoglienti e scarsamente presidiate; altre hanno una manciata di redattori dedicati con forti opinioni e memoria lunga.
- Le edizioni più piccole possono essere più permissive sulla notabilità ma più sensibili alla qualità della traduzione e agli articoli che chiaramente hanno origine altrove.
La trappola è assumere che un articolo approvato in inglese sia un passaporto. Non lo è. Ogni edizione valuta il soggetto rispetto al proprio standard di notabilità (Wikipedia:Notability, ovvero i criteri che determinano se un soggetto merita un articolo), usando le proprie norme sulle fonti affidabili — e ciò che conta come fonte affidabile varia per lingua e paese. Una fonte che è di riferimento nel mondo anglofono può essere sconosciuta, o di cui non ci si fida, da parte dei redattori di un'altra edizione, che ponderano diversamente i propri media nazionali.
L'implicazione per la strategia è diretta: ogni lingua è una questione di notabilità separata. Non potete citare un lancio multilingue come "la pagina inglese per N." Ogni edizione necessita della propria valutazione — questo soggetto supera la soglia di questa comunità, con fonti che questa comunità rispetta? Qualsiasi agenzia che promette una pubblicazione uniforme su tutte le edizioni senza una valutazione per edizione è inesperta o sta per distribuire pagine che verranno cancellate. (Trattiamo ogni edizione come un impegno separato esattamente per questo motivo; il pacchetto di fonti si trasferisce, il giudizio di notabilità no.)
Prioritizzare le lingue per valore di mercato, non per vanità
Una volta accettato che ogni edizione ha un costo e un rischio reali, la domanda diventa: quali? La risposta sbagliata è "quante più possibile" o "quelle che suonano impressionanti." La risposta giusta è guidata da dove opera realmente la vostra azienda — dove vendete, assumete, raccogliete capitali e affrontate esposizione reputazionale.
Un modo utile per pensarci è per livelli, mappando ogni lingua a una logica aziendale piuttosto che a un conteggio di bandiere:
| Livello | Edizioni (esempi) | Quando vale la pena |
|---|---|---|
| Ancora | Inglese | Quasi sempre prima. Edizione più citata, peso LLM maggiore, il punto di riferimento su cui Google fa affidamento globalmente. La pagina da cui ogni altra edizione prende le fonti. |
| Mercati principali | Tedesco, francese, spagnolo, giapponese, portoghese | Le lingue dei vostri maggiori ricavi, investitori o mercati di assunzione. Ognuna è un'importante ancora LLM a sé stante. Il tedesco è particolarmente importante se operate nell'area DACH — e mettete in budget la sua soglia più rigida. |
| Regionale strategico | Arabo, hindi, russo, coreano, italiano, olandese, turco, ucraino, polacco | Regioni ad alta popolazione o alto valore in cui avete una presenza reale. Ne vale la pena quando c'è un'attività commerciale genuina, non solo "vorremmo sembrare internazionali." |
| Coda lunga | Tutto il resto (indonesiano, tailandese, vietnamita, swahili, catalano, ecc.) | Solo con una ragione concreta: un'entrata in un mercato specifico, una partnership locale, un problema reputazionale regionale. La copertura per vanità qui è puro costo. |
Due principi stanno dietro alla tabella. Primo, seguite i ricavi e il rischio. Un'azienda B2B i cui clienti sono produttori tedeschi ha bisogno dell'edizione tedesca molto più di una dozzina di piccole edizioni che stanno bene in una presentazione. Un marchio consumer che si espande nel Sud-Est asiatico ha le priorità opposte. L'elenco giusto delle lingue è un documento aziendale prima di essere un documento di Wikipedia — ecco perché definiamo il lavoro multilingue come parte dei più ampi servizi Wikipedia B2B, partendo dai vostri mercati piuttosto che da un pacchetto generico.
Secondo, ogni edizione che aggiungete è un'edizione che dovete mantenere. Questo è il costo che la maggior parte dei team dimentica in fase di pianificazione e scopre in seguito. Quaranta articoli in quaranta lingue sono quaranta superfici per vandalismi, modifiche casuali, candidature alla cancellazione e lento deriva fattuale — in lingue che il vostro team potrebbe non leggere. Aggiungere una lingua non è un acquisto una tantum; è una responsabilità continuativa. Questo da solo è un motivo per essere spietati nell'elenco delle priorità. Meno edizioni, ben mantenute, battono molte edizioni lasciate a deteriorarsi.
La traduzione non è creazione
Ecco il modo in cui si fallisce che veniamo chiamati a risolvere più spesso: un'azienda (o un fornitore a basso costo) prende l'articolo in inglese, lo passa attraverso la traduzione automatica o un traduttore inesperto, e incolla il risultato nelle Wikipedia in tedesco, francese e spagnolo. In pochi giorni, a volte ore, le pagine vengono contrassegnate, messe in bozza o nominate per la cancellazione. Il denaro è andato e il marchio ora ha una traccia visibile di articoli rifiutati, il che rende il prossimo tentativo più difficile.
Questo fallisce per ragioni strutturali, non cosmetiche:
- Le fonti non si traducono. Un articolo in inglese è costruito su fonti affidabili in lingua inglese. La comunità tedesca vuole fonti in lingua tedesca (o almeno riconosciute in tedesco), ponderate secondo le proprie norme sulle fonti affidabili. Un articolo tradotto spesso cita un elenco di riferimenti che la comunità di destinazione semplicemente non accetta, lasciando il caso di notabilità non provato in quell'edizione. Tradurre la prosa non fa nulla per tradurre le prove sottostanti.
- Il tono e la struttura differiscono per edizione. Ogni comunità ha convenzioni sulla struttura dell'articolo, cosa appartiene all'incipit, come vengono descritte le aziende, cosa conta come promozionale. Una traduzione letterale di un articolo inglese spesso risulta promozionale o stranamente strutturata ai redattori di un'altra edizione, anche quando l'originale inglese era corretto.
- La prosa tradotta automaticamente è rilevabile e sfiduciata. I redattori riconoscono immediatamente gli artefatti della traduzione automatica. Un articolo che sembra essere stato passato attraverso un traduttore segnala "contenuto promozionale importato" — esattamente il segnale che innesca il controllo e la cancellazione.
- L'argomento di notabilità deve essere presentato a quella comunità. Sopravvivere alla revisione significa che l'articolo supera dimostrabilmente la soglia di quella edizione con fonti che quell'edizione rispetta. Questo è un giudizio editoriale e un esercizio di ricerca delle fonti, non un compito di conversione linguistica.
Il quadro onesto: ogni versione linguistica è un nuovo articolo scritto nativamente per quella comunità, che condivide la ricerca di base e il pacchetto di fonti con gli altri ma ricostruito per soddisfare la notabilità locale, le fonti, il tono e la struttura. La pagina inglese funge da ancora per l'elenco delle fonti e i fatti; la pagina tedesca è scritta come un articolo tedesco da qualcuno che conosce gli standard della comunità tedesca. Ecco perché un vero lancio multilingue è quotato per edizione con l'integrazione delle fonti per edizione, non come un lavoro di traduzione collettiva. Chiunque vi venda "tradurremo la vostra pagina in 30 lingue" vi sta vendendo 30 cancellazioni.
Wikidata come spina dorsale multilingue per i Knowledge Panel in tutto il mondo
Tornate al livello strutturato, perché Wikidata sta svolgendo un lavoro silenzioso e pesante in ogni mercato simultaneamente — ed è la parte con la leva maggiore e il costo minore di una strategia multilingue.
Un singolo elemento Wikidata ben costruito porta etichette e descrizioni multilingue: il nome dell'entità e una breve descrizione in ogni lingua che popolate. Quando Google assembla un Knowledge Panel (pannello informativo di Google) per un utente in Corea, il nome dell'entità e il tipo che legge possono provenire direttamente dalle etichette coreane nel vostro elemento Wikidata. Lo stesso elemento serve il pannello arabo, quello spagnolo, quello hindi. Un unico record strutturato, molte rappresentazioni localizzate.
Questo conta di più nella situazione molto comune in cui non avete un articolo su Wikipedia in una data lingua. Ricordate dal nostro lavoro sul livello delle entità che Wikidata ha una soglia molto più bassa di Wikipedia — esistenza verificabile e identificabilità, non il rigoroso standard di notabilità che richiede un articolo. Quindi anche nei mercati in cui un articolo completo su Wikipedia non è ancora realistico, un elemento Wikidata multilingue ben curato può comunque alimentare:
- Il nome e il tipo dell'entità, localizzato, nel Knowledge Panel di quel mercato.
- Fatti strutturati coerenti — data di fondazione, sede, sito ufficiale, identificatori — che non dipendono dall'esistenza di nessun articolo in una singola lingua.
- Il
sameAs(collegamento di identità) che lega la vostra entità ai record di autorità (VIAF, ISNI, LEI, ORCID dove applicabile) che sono essi stessi indipendenti dalla lingua.
Quindi la sequenza per un nuovo mercato è spesso: localizzare prima il livello Wikidata — etichette, descrizioni, fatti strutturati nella lingua di destinazione — il che è economico, veloce e utile indipendentemente da tutto; poi perseguire un articolo completo su Wikipedia in quell'edizione solo dove il caso di notabilità e il valore di mercato lo giustificano. La spina dorsale Wikidata vi dà una base di identità leggibile dalle macchine accurata in ogni lingua a una frazione del costo di un articolo, e non danneggia mai un futuro articolo. È la mossa più sottoutilizzata nel lavoro internazionale sulle entità.
Governance: mantenere N versioni senza esposizione a guerre di modifica
Il giorno in cui viene pubblicato l'ultimo articolo non è la fine del progetto — è l'inizio della fase di manutenzione, e la manutenzione multilingue è genuinamente più difficile di quella in una singola lingua. Ora avete N superfici in N lingue, alcune delle quali il vostro team interno non può leggere, tutte modificabili da chiunque sulla terra.
I rischi si moltiplicano con ogni edizione:
- Vandalismi e promozioni casuali in una lingua che nessuno internamente monitora possono stare attivi per settimane.
- Lenta deriva fattuale — un redattore ben intenzionato "corregge" la vostra data di fondazione o sede in un'edizione, e ora la vostra storia strutturata è incoerente tra i mercati.
- Candidature alla cancellazione localizzate possono iniziare in qualsiasi edizione in qualsiasi momento, spesso molto dopo la pubblicazione, e devono essere affrontate in quella lingua, a quella comunità, nei termini di quella comunità.
- Le guerre di modifica sono la trappola che porta i marchi sulle notizie. Un marketer interno troppo zelante che accede per "correggere" le critiche nell'articolo francese, annullando le modifiche di un redattore volontario, venendo annullato a sua volta, escalando — questo è esattamente come un tranquillo bene reputazionale diventa un imbarazzo pubblico. L'esposizione al conflitto d'interessi (WP:COI, la politica di Wikipedia che regola i conflitti d'interesse) si moltiplica con ogni edizione in cui qualcuno potrebbe essere tentato di intervenire.
Una governance multilingue sensata assomiglia a:
- Monitoraggio centralizzato su tutte le edizioni, con watchlist e avvisi che non dipendono dal fatto che qualcuno legga fluentemente ogni lingua ogni giorno.
- Fatti mantenuti su Wikidata, in modo che una correzione si propaghi piuttosto che essere modificata manualmente in N articoli in modo incoerente.
- Nessuna modifica diretta interna di nessuna edizione da parte di persone con un evidente conflitto d'interessi. Le modifiche vengono proposte in modo trasparente, nelle pagine di discussione, con una divulgazione corretta — la stessa disciplina di WP:PAID (la politica di Wikipedia sulle modifiche retribuite) che mantiene sicura una pagina in una sola lingua, applicata a tutte.
- La difesa gestita da persone che conoscono ogni comunità. Una discussione di cancellazione nella Wikipedia polacca viene vinta da qualcuno che comprende le norme di notabilità polacche e può argomentare in polacco, non da un copia-incolla tradotto dalla difesa in inglese.
Questa è la metà non glamour e ricorrente del lavoro multilingue, ed è il motivo per cui la copertura continuativa — vedere il supporto annuale per Wikipedia — non è un upsell tanto quanto l'unico modo responsabile di mantenere insieme un'impronta multi-edizione. Un portfolio non mantenuto di quaranta articoli non rimane un bene. Si deteriora in quaranta passività, alcune delle quali silenziosamente errate, in lingue che scoprirete essere rotte solo quando l'assistente AI di un potenziale cliente vi ripete l'errore.
Un lancio multilingue a fasi
Mettendo tutto insieme, la sequenza sensata è deliberata, non una corsa all'accaparramento. Gestiamo i programmi multilingue in fasi in modo che ogni passo riduca il rischio del successivo e il budget segua le prove.
Fase 0 — Strategia e mappa linguistica. Prima di qualsiasi bozza, decidete quali edizioni e perché, guidati dai vostri mercati reali, ricavi e rischio — l'esercizio per livelli sopra, trasformato in un elenco prioritario concreto. Output: un piano linguistico classificato con una logica aziendale per ogni edizione e una nota onesta su quali (il tedesco in particolare) presentano una soglia più alta.
Fase 1 — La spina dorsale Wikidata. Prima costruite o ripulite il singolo elemento Wikidata: un QID, fatti strutturati, collegamenti ai record di autorità ed etichette e descrizioni multilingue per ogni mercato di destinazione — inclusi quelli in cui non è previsto nessun articolo ancora. È economico, veloce e migliora immediatamente il riconoscimento delle entità localizzate ovunque. È anche l'impalcatura in cui ogni articolo successivo si collegherà con sitelink.
Fase 2 — L'articolo ancora. Create l'articolo in inglese (o, occasionalmente, l'edizione singola più rilevante per la vostra attività) attraverso la corretta creazione di pagine Wikipedia — valutazione della notabilità, redazione nativa, revisione della comunità, monitoraggio post-pubblicazione. Questo funge da ancora per il pacchetto di fonti da cui le altre edizioni attingeranno.
Fase 3 — Edizioni dei mercati principali, in ordine di priorità. Lanciate le edizioni linguistiche di maggior valore una alla volta, ciascuna come un articolo scritto nativamente con l'integrazione delle fonti per edizione e la propria valutazione della notabilità — non traduzioni. Farle in sequenza significa imparare dalla ricezione di ogni comunità prima di impegnarsi con la successiva, e potete fermarvi o ripriorizzare se la soglia di un'edizione risulta più alta del previsto.
Fase 4 — Edizioni strategiche e di coda lunga, come giustificate. Aggiungete ulteriori edizioni solo dove appare una ragione concreta di mercato. Resistete all'attrazione della vanità. Ogni aggiunta è un impegno di manutenzione.
Fase 5 — Governance multilingue continuativa. Monitoraggio centralizzato, coerenza dei fatti guidata da Wikidata, modifiche divulgate trasparentemente e difesa dalla cancellazione per comunità sull'intera impronta — continuamente, per tutto il tempo in cui le pagine contano.
Il filo conduttore è l'onestà riguardo ai costi e ai rischi. Wikipedia multilingue e Wikidata fatti bene sono una delle più forti infrastrutture di visibilità AI globale che un'azienda possa possedere — la cosa che fa descrivere correttamente un modello, che la domanda arrivi in inglese, arabo o giapponese. Fatti come una corsa alla traduzione collettiva, è un modo rapido per spendere molti soldi generando cancellazioni in lingue che non potete leggere. La differenza è tutta nella disciplina: un'unica entità unificata, rispetto per le regole indipendenti di ogni edizione, lingue scelte per valore di mercato e manutenzione trattata come parte del lavoro piuttosto che un ripensamento.
Vendete in più di un mercato e non siete sicuri di quali edizioni linguistiche valgano la pena? Scriveteci a team@wikibusines.com e vi invieremo una mappa delle priorità linguistiche onesta e basata sul mercato — incluso quali edizioni salteremmo.