Traducció i localització de software: procés, costos i què cal enviar al vostre proveïdor
La traducció i localització de software segueix vuit passos: preparar el codi per a altres idiomes, extreure les cadenes en fitxers traduïbles, aportar context, acordar la terminologia, traduir i revisar, provar amb pseudolocalització i revisió en context, publicar i repetir el cicle en cada actualització. El cost depèn sobretot del text nou respecte del reutilitzat, del nombre d’idiomes i de la freqüència de llançaments. DEMA Solutions localitza software i documentació per a empreses tecnològiques europees.
A qui s'adreça aquesta guia
Aquesta guia està pensada per a qui ha de llançar un producte en diversos idiomes sense frenar el desenvolupament: product managers que preparen la seva primera versió multilingüe, responsables de desenvolupament que gestionaran els fitxers de cadenes i responsables de localització que han heretat un procés que funciona gairebé sempre. També s’adreça a fabricants de maquinària i equips els productes dels quals ja inclouen software, com un configurador, un portal de clients o una aplicació complementària, i que descobreixen que el software no es tradueix com un manual.
Les preguntes són pràctiques: què ha de passar al codi, quins fitxers cal enviar, com es prova el resultat i per què els pressupostos varien tant. Les seccions següents recorren el procés en l’ordre en què us el trobareu.
Què és la localització de software i en què es diferencien traducció i localització
Localitzar un software vol dir adaptar els textos visibles, els formats i el comportament d’un programa perquè resulti natural als usuaris d’un altre idioma i d’un altre mercat. La traducció n’és la part central, però només una part. Un producte localitzat també mostra les dates, els números, les monedes i les unitats com els esperen els usuaris locals, gestiona formes de plural que l’anglès no té, fa cabre textos més llargs als mateixos botons i quadres de diàleg i utilitza els mateixos termes a la interfície, al centre d’ajuda i a la documentació. Per això la localització en traducció de software va molt més enllà de canviar paraules.
La diferència entre traducció i localització és important perquè canvia qui hi participa. Un document el poden traduir només lingüistes. Un software, no: els desenvolupadors decideixen com s’emmagatzemen i es componen les cadenes, els dissenyadors quant espai té una etiqueta i l’equip de producte quins mercats surten i quan. Si aquestes decisions tenen en compte altres idiomes, la traducció és ràpida i previsible. Si no, els traductors reben fragments sense context i els problemes apareixen tard, a la compilació de llançament, en un idioma que ningú de l’equip llegeix.
Primer, la internacionalització
Abans de la localització hi ha la internacionalització, la feina d’enginyeria que prepara un producte per a qualsevol idioma. És la causa més freqüent d’una localització lenta i cara, i depèn gairebé del tot de l’equip de desenvolupament.
Externalitzeu totes les cadenes visibles. El text escrit directament al codi no es pot extreure ni actualitzar sense modificar el codi. Etiquetes, missatges, tooltips, plantilles de correu i textos d’error han de ser en fitxers de recursos, referenciats amb claus estables.
No construïu frases a trossos. El codi que concatena «You have » + count + » new messages» pressuposa l’ordre de paraules de l’anglès. Feu servir frases completes amb marcadors de posició amb nom i deixeu que cada idioma els ordeni.
Admeteu les regles de plural. L’anglès, el castellà i el català tenen dues formes de plural; molts idiomes en tenen més, amb categories diferents. Els formats de missatge que admeten categories de plural, com la sintaxi ICU, permeten als traductors aportar totes les formes necessàries.
Deixeu espai per a l’expansió del text. El text traduït sol ser més llarg que l’anglès, i les etiquetes curtes s’allarguen proporcionalment més. Els dissenys flexibles i els límits de caràcters acordats allà on l’espai és realment fix eviten la majoria dels textos tallats.
Feu servir formats segons la configuració regional i Unicode a tot arreu. Les dates, els números i l’ordenació han de sortir de la configuració regional, i cada capa, de la base de dades a les fonts, ha d’admetre els caràcters dels idiomes de destinació.
Res d’això és traducció, però cada mancança es converteix en un problema de traducció. Un bon proveïdor us assenyalarà els problemes d’internacionalització que trobi als vostres fitxers; el que no pot fer és corregir-los al vostre codi.
El procés de localització de software, pas a pas
Vist des de fora, localitzar sembla «enviar cadenes, rebre cadenes». El procés de localització que funciona a la pràctica té més passos, i la majoria passen abans o després de la traducció.
1. Definiu l’abast i els idiomes. Decidiu quins components (interfície, onboarding, notificacions, centre d’ajuda, documentació) surten en quin idioma i amb quina versió.
2. Extraieu les cadenes. Exporteu fitxers de recursos que el proveïdor pugui processar sense copiar res a mà, amb les claus, l’estructura i la codificació intactes.
3. Pseudolocalitzeu. Proveu la compilació amb text generat i allargat abans que comenci la traducció real.
4. Prepareu el context. Les captures de pantalla, els comentaris a les cadenes i els límits de caràcters indiquen al traductor on apareix cada cadena.
5. Acordeu la terminologia i l’estil. Es creen o s’actualitzen el glossari i la guia d’estil, aprovats per algú que conegui el producte en aquell mercat.
6. Traduïu i reviseu. Lingüistes nadius tradueixen les cadenes noves i modificades, es reutilitzen les traduccions aprovades i un segon lingüista revisa el resultat.
7. Proveu en context. Les cadenes traduïdes es comproven a les pantalles reals: significat, talls i coherència.
8. Publiqueu i manteniu. Cada correcció torna a la memòria de traducció i al glossari, perquè la versió següent parteixi del text corregit.
Les seccions següents s’aturen en els passos on fallen la majoria dels projectes.
Fitxers de cadenes i formats: què ha de rebre el vostre proveïdor
Els formats de recursos canvien segons la plataforma de desenvolupament, i cadascun té els seus riscos. El proveïdor no necessita conèixer el vostre sistema de compilació, però sí rebre fitxers que pugui obrir, traduir i retornar amb exactament la mateixa estructura. Els formats més habituals són:
- XLIFF, l’estàndard XML d’intercanvi per a la localització, que manté junts el text d’origen, la traducció i les notes;
- JSON, molt estès als front ends web i mòbils, sovint niat i sense cap camp nadiu de comentaris, de manera que el context s’ha d’enviar a part;
- RESX per a aplicacions .NET, amb un element de comentari per cadena;
- fitxers PO de gettext, que admeten comentaris per al traductor, context del missatge i formes de plural;
- fitxers .strings i .stringsdict per a aplicacions iOS i recursos XML de cadenes per a Android, cadascun amb la seva pròpia sintaxi de plural.
Sigui quin sigui el format, certs elements han de tornar intactes: les claus, els marcadors de posició com {name} o %s, les etiquetes de marcatge, els caràcters d’escapament i la codificació del fitxer. Els marcadors es poden moure dins de la frase, perquè l’ordre de les paraules canvia, però no s’han de traduir, eliminar ni duplicar mai. Els controls automàtics detecten la majoria d’aquests errors abans del lliurament, i preguntar a un proveïdor com detecta un marcador malmès és una prova ràpida del seu procés.
Hi ha un hàbit que estalvia molt de temps: envieu només les cadenes noves i modificades, o indiqueu clarament què ha canviat des de l’últim lliurament. Reenviar cada vegada els fitxers complets sense aquesta informació obliga algú a tornar a localitzar les novetats, i és aquí on s’escolen canvis involuntaris en cadenes ja aprovades.
Context: captures, comentaris i límits de caràcters
La majoria dels errors de localització són errors de context, no d’idioma. «Open», «Update» o «Save» poden ser un verb en un botó o un substantiu en un menú, i en català es converteixen en «Actualitza» en un cas i «Actualització» en l’altre. Una cadena com «%d items» pot referir-se a productes d’un carretó o a entrades d’un registre. Sense context, fins i tot un traductor acurat ha d’endevinar.
Tres tipus de context marquen la diferència. Les captures de pantalla mostren on és una cadena i quant espai té. Els comentaris a les cadenes expliquen per a què serveix una clau i què contindrà cada marcador. Els límits de caràcters per a botons, capçaleres de taula i notificacions indiquen al traductor quan cal una formulació més curta, abans que un provador trobi l’etiqueta tallada.
No calen tots tres en cada cadena. Una nota a les claus ambigües, captures actualitzades a cada versió i límits només allà on l’espai és realment fix eliminen gairebé totes les suposicions, i els equips que comenten les claus en crear-les gairebé no reben consultes dels traductors.
Terminologia i estil: una sola veu en cada idioma
Una interfície és un vocabulari reduït que es fa servir milers de vegades. Si «workspace» es tradueix de tres maneres entre l’aplicació, el centre d’ajuda i els correus de benvinguda, els usuaris es pensen que són tres coses diferents. Un glossari de termes de producte, amb la traducció aprovada en cada idioma i una nota sobre els termes que es queden en anglès, evita aquesta deriva. El nostre article sobre la gestió terminològica centralitzada entre traductors i proveïdors explica com crear un glossari així i mantenir-lo al dia.
L’estil també és important. La interfície tracta l’usuari de tu o de vostè? Els botons fan servir l’infinitiu («Desar») o l’imperatiu («Deseu»)? Com es redacten els missatges d’error? Una breu guia d’estil per a la traducció per idioma respon aquestes preguntes d’un cop, per a tots els traductors i revisors. En famílies de productes més àmplies, un servei estructurat de gestió terminològica converteix el glossari en una base terminològica mantinguda que poden fer servir tots els proveïdors i equips interns.
Traducció i revisió
Amb els fitxers, el context i la terminologia a punt, la traducció és el pas més previsible. Lingüistes nadius amb experiència en les convencions del software tradueixen les cadenes noves i modificades, les traduccions aprovades de la memòria es reutilitzen allà on l’origen no ha canviat i un segon lingüista compara cada traducció amb l’original pel que fa al significat, la terminologia, els marcadors i la longitud.
La traducció automàtica hi té el seu lloc, sobretot en centres d’ajuda, bases de coneixement i actualitzacions de documentació de gran volum. Funciona millor quan treballa sobre el vostre glossari i la vostra memòria aprovada, amb un lingüista qualificat que en fa la postedició. Les cadenes d’interfície són curtes, ambigües i visibles a cada pantalla, de manera que normalment necessiten un traductor humà des del principi. A la pàgina sobre traducció automàtica i postedició expliquem com decidim quins continguts són adequats.
Pseudolocalització i QA lingüístic en context
Dos tipus de prova protegeixen una versió localitzada, i cadascun troba problemes diferents.
La pseudolocalització es fa abans de traduir i prova el codi, no l’idioma. Un script substitueix cada cadena d’origen per una versió allargada, amb caràcters accentuats i entre marcadors visibles, de manera que «Save changes» es pot convertir en [Šåvé çhåñgéš !!!]. Quan es recorre aquesta compilació es veu de seguida quin text està escrit al codi (continua en anglès normal), quines etiquetes es tallen (desapareix el marcador de tancament) i quins caràcters es trenquen. Costa poc, no necessita traductors i detecta precisament els errors més cars de descobrir en deu idiomes alhora.
El QA lingüístic en context es fa després de traduir, en una compilació o un entorn de staging amb les cadenes reals. Un lingüista o un revisor del mercat de destinació recorre els principals fluxos d’usuari i comprova el que cap revisió sobre fitxers no pot veure: si una traducció encaixa en el seu context, si el text es talla, si les dates i els números apareixen correctament i si cada terme és el mateix a totes les pantalles. Les correccions entren a la memòria de traducció, no només a la compilació, perquè no tornin a aparèixer a la versió següent.
En un primer llançament convé fer totes dues proves en tots els idiomes; en les versions rutinàries solen ser suficients els controls automàtics i la revisió en context de les funcions noves.
Localització contínua per a llançaments freqüents
Els productes que surten cada una o dues setmanes no es poden localitzar en grans lots ocasionals: quan un lot torna, l’origen ja ha canviat. La localització contínua substitueix el lot per un flux constant: a cada versió es recullen i es tradueixen les cadenes noves i modificades mentre l’sprint continua en marxa, de manera que cada idioma surt amb l’original i no setmanes després. La nostra guia sobre traducció d’aplicacions i SaaS detalla com organitzar aquest flux en un producte SaaS, versió a versió.
Més que la velocitat, compta la disciplina. Les cadenes s’han de marcar com a estables abans d’anar a traducció; si no, el mateix text es tradueix tres vegades mentre la redacció s’acaba d’assentar. El context ha d’acompanyar cada lot, perquè el traductor no ha vist la demo de la funció. Les decisions terminològiques necessiten un responsable que contesti ràpidament, i la memòria s’ha d’actualitzar amb cada lliurament.
L’avantatge és tangible: els lots petits es revisen més fàcilment, els errors es corregeixen abans que es propaguin i cada versió costa només el que realment ha canviat. Aquí convergeixen gairebé totes les bones pràctiques de localització: localitzar poc i sovint, amb context, sobre una sola memòria i un sol glossari.
Interfície, ajuda i documentació coherents
Els usuaris no distingeixen entre la interfície i la documentació. Si el botó diu una cosa i l’article d’ajuda una altra, perden la confiança en tots dos. Tanmateix, aquests textos solen néixer en equips, formats i calendaris diferents, de vegades amb proveïdors diferents.
La solució és tractar-los com un únic conjunt de continguts. El mateix glossari i la mateixa memòria de traducció haurien de servir per a la interfície, el centre d’ajuda, les notes de versió, la documentació d’API i, en el cas dels fabricants, el manual d’instruccions. Els manuals i les guies d’instal·lació que acompanyen un software segueixen la mateixa lògica que la resta de les vostres traduccions tècniques: han de reutilitzar la terminologia de la interfície, no reinventar-la.
Si les vostres traduccions anteriors són en fitxers antics i no en una memòria, encara es poden recuperar. L’alineació de memòries de traducció aparella les traduccions prèvies amb els seus originals, de manera que la redacció aprovada sigui reutilitzable des de la primera versió amb un proveïdor nou.
Què determina el cost de la localització de software
La localització de software se sol pressupostar per paraula, però la tarifa explica menys del cost final del que molts compradors esperen. Aquests són els factors que realment mouen la xifra.
Text nou respecte de text repetit. Les cadenes ja aprovades a la memòria, o repetides dins del producte, costen molt menys que el text nou, i les coincidències parcials queden a mig camí. En un producte madur, la major part de cada versió és reutilització; en un primer llançament, gairebé tot és nou.
Aprofitament de la memòria. Un proveïdor que parteix de la vostra memòria existent factura només el que és realment nou; un que no la pot fer servir ho factura tot de nou. Per això la propietat de la memòria de traducció és tan important com la tarifa.
Nombre d’idiomes. El cost creix de manera gairebé lineal amb els idiomes, així que convé comprovar si cada component necessita realment cada idioma.
Freqüència de llançaments i mida dels lots. Cada lot comporta un esforç fix de gestió de fitxers, controls i gestió de projecte. Els lots regulars i planificats són eficients; les cadenes enviades d’una en una, no.
Context, qualitat dels fitxers i abast de les proves. Els fitxers nets, amb comentaris i captures, es tradueixen més de pressa i amb menys consultes. La manca de context es paga dues vegades, en consultes i després en correccions després de les proves. El QA en context i la revisió al mercat suposen un esforç que s’ha de planificar, no descobrir.
Un exemple senzill mostra per què pesa tant la reutilització. Suposem que una versió modifica 2000 paraules d’interfície: 1200 de noves, 500 coincidències parcials i 300 que ja són a la memòria. En deu idiomes són 12.000 paraules noves per traduir, 5000 per ajustar i 3000 per comprovar, no 20.000 paraules traduïdes des de zero. Un proveïdor que informa d’aquest repartiment a cada lliurament fa que el cost de cada versió sigui explicable.
Errors habituals i el que costen
Traduir abans que les cadenes siguin estables. El text que encara s’està reescrivint es tradueix, es torna a traduir i es canvia una altra vegada, i cada ronda es paga.
Enviar cadenes sense context. Les etiquetes ambigües s’interpreten, les suposicions semblen plausibles i els errors els troben els clients abans que els provadors.
Deixar que cada proveïdor tingui la seva pròpia memòria. Quan canvieu de proveïdor, o l’aplicació i el manual van a proveïdors diferents, la redacció aprovada es perd i la terminologia divergeix.
Què cal enviar al vostre proveïdor i com triar-lo
Un briefing complet, sovint anomenat kit de localització, permet al proveïdor pressupostar amb precisió i començar sense una ronda de consultes. Per a una versió de software hauria d’incloure:
- els fitxers de recursos amb les cadenes noves i modificades identificades, més l’ajuda o la documentació incloses en l’abast;
- els idiomes i les configuracions regionals de destinació, i quins components necessita cadascun;
- el context: captures o accés a una compilació de prova, comentaris a les cadenes i límits de caràcters;
- el vostre glossari, la guia d’estil i la memòria de traducció existent, si en teniu;
- el calendari de versions, la freqüència dels lots i la persona de contacte per a consultes.
Quan compareu proveïdors, feu preguntes que revelin com treballen. Poden processar els vostres formats de manera nativa i retornar-los sense claus ni marcadors malmesos? Quins controls automàtics s’executen abans del lliurament? Un segon lingüista qualificat revisa cada traducció? Parteixen de la vostra memòria existent, la podeu exportar en qualsevol moment i com indiquen què era nou i què s’ha reutilitzat? El nostre article sobre el control de qualitat de la traducció explica quines proves cal demanar abans de confiar un projecte a un proveïdor.
Com treballa DEMA Solutions en la localització de software
Els nostres serveis de localització de software i traducció tecnològica estan pensats per a equips de producte que publiquen de manera contínua. Les cadenes noves i modificades es tradueixen a cada versió, al ritme dels vostres sprints, en lloc d’agrupar-se en grans projectes ocasionals. Els fitxers JSON, XML i altres fitxers de recursos tornen amb la seva estructura original, sense extracció manual ni claus trencades, i els controls automàtics busquen variables malmeses, cadenes tallades i errors de format abans que arribin a una compilació de llançament.
Els nostres traductors són lingüistes tècnics nadius que treballen amb terminologia de software i desenvolupament, i el procés està certificat segons la norma ISO 17100, amb un segon lingüista qualificat que revisa cada traducció, tal com es descriu a la nostra pàgina de qualitat de la traducció. Els vostres enginyers i caps de producte poden revisar directament a l’entorn de traducció i no en fulls de càlcul exportats, de manera que les correccions arriben immediatament a la memòria. La memòria i els glossaris continuen sent vostres, exportables en qualsevol moment en formats portàtils com TMX i TBX, i els informes de reutilització mostren quina part de cada versió prové de text ja aprovat. Els nostres equips a Itàlia, Sèrbia i Espanya s’ocupen també de l’ajuda, la documentació d’API, les notes de versió i els manuals, amb un equip propi de maquetació per als formats de disseny, perquè la interfície i els documents comparteixin la mateixa terminologia.
On encaixa TUBE
Per a productes amb llançaments continus, TUBE és la nostra solució per mantenir cada cicle de localització sota el vostre control. El vostre glossari i la vostra memòria de traducció controlen la traducció automàtica, cada traducció aprovada passa a una memòria de la vostra propietat que podeu exportar, i els informes de reutilització mostren quina part de cada actualització prové de text que ja heu aprovat.
Preguntes freqüents
Internacionalitzar el codi, extreure les cadenes, pseudolocalitzar, preparar el context, acordar la terminologia i l'estil, traduir i revisar, provar la compilació traduïda en context i, després, publicar i portar les correccions a la memòria de traducció. Amb llançaments freqüents, el cicle es repeteix només amb les cadenes noves i modificades.
La internacionalització prepara el producte per a qualsevol idioma: cadenes externalitzades, gestió de plurals, formats segons la configuració regional i dissenys flexibles. La localització l'adapta a un idioma i un mercat concrets, incloses la traducció i les proves. La primera es fa una vegada i es manté; la segona es repeteix en cada idioma i cada versió.
El que el vostre sistema de compilació generi de manera fiable i que mantingui intactes les claus, els marcadors i el context. XLIFF és el format d'intercanvi més robust; JSON, RESX, PO i els fitxers de cadenes de cada plataforma funcionen bé si els marcadors són coherents i s'aporta context.
Substitueix les cadenes d'origen per text allargat i accentuat entre marcadors visibles, de manera que el text escrit al codi, els talls i els problemes de codificació apareixen abans de la traducció real. Convé fer-la servir abans dels primers idiomes i cada vegada que s'afegeixen funcions importants.
Depèn de quant text és realment nou, de quant se'n pot reutilitzar d'una memòria de traducció, del nombre d'idiomes, de la freqüència de llançaments i de l'abast de les proves. Demaneu pressupostos que mostrin per separat el text nou, les coincidències parcials i el text reutilitzat, per comparar proveïdors sobre la mateixa base.
Pot donar suport a continguts amplis i repetitius com centres d'ajuda i documentació, si treballa sobre un glossari i una memòria aprovats i un lingüista qualificat en fa la postedició. Les cadenes curtes d'interfície són ambigües i molt visibles, de manera que en general necessiten un traductor humà i una revisió.
Marqueu les cadenes com a estables abans de traduir, envieu només cadenes noves i modificades amb context, feu servir una sola memòria i un sol glossari per a tots els continguts i acordeu amb el vostre proveïdor un termini fix per lot.
Planifiqueu la vostra propera versió multilingüe
Si esteu preparant la vostra primera versió localitzada, o el vostre procés actual no aconsegueix seguir el ritme dels vostres sprints, expliqueu-nos el vostre producte, els vostres formats de fitxer i els idiomes de destinació. Revisarem els vostres fitxers i us proposarem un flux de localització adaptat al vostre cicle de llançaments.
Com us podem ajudar?
Expliqueu-nos què necessiteu i us respondrem amb les solucions adequades.