Come un'agenzia di contenuti con una sola persona realizza siti multilingue senza un traduttore
By Robert M
Come un'agenzia di contenuti con una sola persona realizza siti multilingue senza un traduttore
Un cliente chiede se puoi consegnare il loro nuovo sito in inglese, francese, tedesco, spagnolo e olandese. Gestisci un'attività da solo. Non hai un budget per la traduzione incluso nel tuo contratto, e non hai una rete di traduttori freelance a disposizione. Ma non vuoi nemmeno dire no a un buon progetto.
Questa è una situazione in cui si trovano molte piccole agenzie e freelance. La domanda di siti multilingue è cresciuta costantemente man mano che sempre più aziende cercano di raggiungere pubblici al di fuori del loro mercato di origine, ma le discussioni sul budget non sono ancora allineate. I clienti spesso considerano la traduzione come una voce di spesa da ridurre o eliminare, senza comprendere davvero quanto costa farla correttamente.
Questo post parla di come gestire praticamente questo divario, senza compromettere la qualità o subire perdite sul progetto.
Le vecchie opzioni e perché non bastano
I percorsi tradizionali sono familiari.
Potresti assumere un traduttore freelance per ogni lingua. Per un sito in cinque lingue con trenta pagine di contenuti, stai guardando a un costo significativo prima di considerare i giri di revisione, i tempi di consegna e il sovraccarico di dover istruire cinque persone diverse sul tono e la terminologia del cliente. Quel costo o erode il tuo margine o viene addebitato al cliente e improvvisamente il progetto è a rischio.
Potresti usare uno strumento di traduzione consumer e pulirlo manualmente. Funziona per frasi semplici, ma nel momento in cui il tuo contenuto ha una struttura (un file locale JSON, un post blog Markdown, una pagina HTML con attributi e tag) l'output diventa imprevedibile. Le chiavi vengono tradotte. La sintassi Markdown si rompe. Gli attributi HTML vengono danneggiati. Finisci per spendere più tempo a correggere l'output di quanto ne hai risparmiato non assumendo un traduttore.
Potresti dire al cliente che il multilingue è fuori dal campo di applicazione e fare un sito in una sola lingua. A volte è la risposta giusta. Ma non è sempre una conversazione che vuoi avere.
Cosa è effettivamente cambiato
La cosa che ha reso questo flusso di lavoro praticabile non è la traduzione AI in astratto. È la preservazione del formato in modo specifico.
Il problema di inserire contenuti strutturati in uno strumento di traduzione generico non è mai stata la qualità della traduzione. La traduzione automatica moderna è buona. Il problema era che gli strumenti non capivano la differenza tra contenuto e struttura. Trattavano tutto come testo da tradurre, comprese le parti che avrebbero dovuto essere lasciate intatte.
Un file locale come questo:
{
"nav": {
"home": "Home",
"about": "About us",
"contact": "Get in touch"
}
}
Tornava con le chiavi tradotte, la nidificazione collassata o l'intero file convertito in prosa. Qualsiasi di questi risultati significa pulizia manuale prima che il file sia utilizzabile, e qui il risparmio di tempo svanisce.
Un'API che tratta la struttura come off-limits cambia l'economia. Invi il file, ricevi indietro una struttura identica con solo i valori stringa cambiati. Inserisci il file di output direttamente nel progetto. Nessuna pulizia necessaria.
Il flusso di lavoro nella pratica
Ecco come appare il processo in un progetto reale.
Nella fase di contenuto, tutto va in file di testo semplice o Markdown invece di stringhe codificate. È comunque una buona pratica per la manutenibilità, ma significa anche che il contenuto è in un formato che può essere tradotto pulitamente.
Nella fase di build, uno script breve legge il file della lingua sorgente, lo invia all'API PolyLingo con la lista delle lingue target e scrive un file di output per ogni locale. Per un sito che necessita di cinque lingue, è una chiamata API. Lo script impiega pochi secondi. I file di output vanno direttamente nella struttura del progetto.
Nella fase di revisione, il cliente rivede il contenuto tradotto. È un passaggio che vale la pena mantenere. La traduzione automatica gestisce bene la maggior parte dei contenuti, ma i clienti a volte hanno terminologia preferita, frasi di marca o convenzioni regionali che necessitano di un occhio umano. La revisione è più veloce che tradurre da zero perché la struttura è già corretta e la maggior parte del contenuto è accurata. Stai revisionando, non producendo.
Nella fase di consegna, il sito viene consegnato con tutti i file locale al loro posto. Il selettore di lingua funziona dal primo giorno. Non c'è nulla da seguire.
Cosa costa rispetto all'assunzione di traduttori
I numeri dipendono dalla dimensione del progetto, ma la struttura del confronto è coerente.
Un tipico sito di piccole imprese potrebbe avere circa 2.000 parole di testo dell'interfaccia e contenuti di pagina. Tradotto in cinque lingue, sono circa 10.000 parole di output. Con una tariffa media di traduzione freelance, stai guardando a diverse centinaia di sterline o dollari prima delle revisioni.
Con PolyLingo, 2.000 parole di contenuto in cinque lingue target rientrano comodamente nel piano Starter a pagamento da 9$ al mese, inclusa la capacità per più progetti nello stesso periodo di fatturazione. Il livello gratuito (50.000 token al mese) copre progetti più piccoli senza alcun costo.
Il cliente fa comunque un passaggio di revisione, il che significa che è coinvolto nella qualità dell'output invece di ricevere solo una fattura. Questo tende a essere meglio nelle conversazioni di progetto.
La conversazione sul campo di applicazione con i clienti
Un cambiamento che questo flusso di lavoro abilita è modificare il modo in cui parli del campo di applicazione multilingue con i clienti.
In precedenza, "multilingue" significava "più costoso, tempi più lunghi, dipendenza da terzi." Ora è più vicino a una decisione di configurazione. Lo definisci, esegui lo script, il cliente rivede. La parte difficile è la strategia dei contenuti e l'architettura del sito, non la logistica della traduzione.
Questo cambia ciò che puoi offrire. Un cliente che avrebbe fatto un lancio in una sola lingua con un piano vago di aggiungere lingue in seguito può fare tutte e cinque al lancio senza raddoppiare il costo del progetto. Un cliente che continua ad aggiungere pagine può rieseguire lo script ogni volta che il contenuto cambia invece di tornare da un traduttore con un nuovo brief.
Cambia anche la conversazione su cosa comporta realmente il multilingue. Il lavoro dell'agenzia è costruire un sito con una corretta architettura i18n, un buon testo nella lingua sorgente e un processo di revisione per le traduzioni. È una conversazione di valore più alto rispetto a "ci occuperemo delle traduzioni una volta che la versione inglese sarà pronta."
Quando ha ancora senso usare traduttori umani
Vale la pena essere onesti.
Per testi di marketing che devono trasmettere un vero peso emotivo nella lingua target, un traduttore umano esperto produrrà un output migliore. La differenza conta soprattutto per campagne, dichiarazioni di posizionamento del marchio e qualsiasi cosa in cui la formulazione stessa è il prodotto.
Per contenuti altamente regolamentati (legali, medici, finanziari) un traduttore umano con competenze specifiche è la scelta giusta, e spesso un requisito di conformità.
Per contenuti editoriali lunghi in cui la voce deve sembrare nativa e non tradotta, la revisione umana è più di un semplice controllo leggero.
Il flusso di lavoro descritto qui è più adatto a testi di interfaccia, contenuti di pagina, descrizioni di prodotto, documentazione e siti di marketing dove l'accuratezza e l'integrità strutturale contano più della sfumatura stilistica. Copre una grande parte di ciò che una piccola agenzia effettivamente consegna.
Come iniziare
Il livello gratuito di PolyLingo include 50.000 token al mese senza bisogno di carta di credito. Per una piccola agenzia, copre una quantità significativa di contenuti prima di dover pensare a un piano a pagamento.
L'API accetta testo semplice, Markdown, JSON e HTML. Il traduttore no-code nella dashboard gestisce lavori occasionali senza toccare affatto l'API, utile per sessioni di revisione con il cliente dove vuoi mostrare l'output tradotto senza costruire nulla prima.