Traducció d'aplicacions i SaaS: com localitzar al ritme dels llançaments continus
La traducció d’aplicacions funciona amb llançaments setmanals quan forma part de la cadena de lliurament: les cadenes noves i modificades passen als traductors tan bon punt són estables, tornen pel mateix repositori, es proven en context i es publiquen juntament amb l’idioma original. Una única memòria de traducció i un glossari mantenen la coherència. DEMA Solutions localitza apps, ajuda i notes de versió per a equips de programari europeus.
A qui s'adreça aquesta guia
Aquesta guia està pensada per a qui s’ocupa dels idiomes en una empresa de programari que no para mai de publicar: responsables de producte que prometen funcions en diversos mercats alhora, responsables d’enginyeria al capdavant de la compilació i dels fitxers de cadenes, i responsables de localització que fan de pont entre tots dos i el proveïdor de traducció. Dona per sabuts els fonaments que expliquem al nostre article sobre el procés de traducció i localització de programari, com ara les cadenes externalitzades i els fitxers de recursos, i se centra en el que canvia quan el producte surt cada setmana o cada esprint.
Les preguntes són operatives: congelar o fluir, com viatgen els fitxers, com provar el que no podeu llegir i quant hauria de costar cada versió. Si el vostre producte és programari de màquina, com ara un panell d’operador o una interfície de control que es lliura amb l’equip, les regles són unes altres, i les tractem a la guia sobre traducció de programari per a HMI i màquines.
Què vol dir la localització de SaaS quan es publica cada setmana
En un projecte tradicional, la localització comença quan el contingut està acabat. Un producte SaaS no està mai acabat: la interfície canvia en increments petits, les funcions s’activen primer per a alguns clients, els fluxos de benvinguda es proven en variants i el centre d’ajuda creix amb cada versió.
Per això la localització de SaaS té una altra unitat de treball. No és un document, sinó un paquet de canvis: les cadenes afegides o modificades des de l’últim lliurament, més els articles d’ajuda, les notificacions i les notes de versió que les descriuen. D’aquí se’n deriven tres conseqüències. La rapidesa neix del flux, no de l’esforç heroic: les cadenes estables enviades a cada esprint tornen dins del mateix esprint, mentre que un lot trimestral sempre arriba tard. La coherència depèn de recursos compartits, perquè qui tradueix avui potser no va traduir el mes passat. I el cost per versió es converteix en la xifra clau, perquè el pressupost es gasta de manera contínua.
Congelació de cadenes o flux continu: triar el model de llançament
Hi ha dues maneres bàsiques d’encaixar la traducció en un cicle de llançaments, i la majoria dels equips amb experiència acaben combinant-les.
La congelació de cadenes (string freeze) fixa una data abans de cada versió a partir de la qual cap text visible no pot canviar. Tot el que s’ha congelat es tradueix, torna, es prova i es publica. És un model senzill, previsible i fàcil de pressupostar. Encaixa amb productes de llançaments mensuals o trimestrals, amb continguts la redacció dels quals requereix aprovació i amb equips que localitzen per primera vegada. El seu punt feble és el forat que crea: si la congelació és tres dies abans del llançament i la traducció, la revisió i les proves en necessiten cinc, o bé els idiomes surten tard o bé la congelació s’avança i el desenvolupament perd marge.
La localització contínua elimina la congelació com a esdeveniment únic. Les cadenes passen a traducció tan bon punt es marquen com a llestes, normalment quan es fusiona una branca de funcionalitat o s’aprova un pull request, i les traduccions tornen al mateix ritme. El dia del llançament, gairebé tot el text ja està traduït i revisat, i només queden els canvis d’última hora. Això és, a la pràctica, la localització àgil: la traducció avança en paral·lel al desenvolupament, no al darrere.
El flux continu exigeix més disciplina que la congelació, no pas menys. Les cadenes han de ser realment estables abans de sortir del repositori; si no, la mateixa frase es tradueix tres vegades mentre se n’assenta la redacció. Una marca de «llesta per traduir» o un breu període d’espera després de la fusió resol la majoria dels casos.
L’elecció depèn de la freqüència de llançament, de quant text canvia, de la rapidesa amb què algú del vostre equip respon les consultes i del risc que suposa una traducció absent. Un bon compromís és el flux continu per als textos d’interfície i l’ajuda, amb una congelació breu per a les notes de versió i els textos de la botiga d’aplicacions, que s’escriuen els últims i es llegeixen els primers.
Connectar el repositori amb el flux de traducció
El coll d’ampolla més habitual en la localització contínua no és la velocitat de traducció, sinó la gestió de fitxers. Si un desenvolupador exporta les cadenes a mà, les envia per correu, espera i copia el fitxer retornat a la carpeta correcta, cada versió perd un dia i corre el risc de sobreescriure alguna cosa. El que val per a qualsevol gestió del flux de traducció sense correus ni fulls de càlcul aquí val encara més: les cadenes han de viatjar entre el repositori de codi i l’entorn de traducció sense passos manuals.
En l’esquema més senzill, una tasca programada exporta les cadenes noves i modificades de la branca principal a una ubicació compartida, i els fitxers traduïts hi tornen perquè la compilació els reculli. En una configuració més integrada, l’entorn de traducció està connectat directament al repositori: detecta canvis als fitxers de l’idioma original, crea les tasques de traducció i, quan un idioma està complet, obre un pull request que els vostres desenvolupadors revisen i fusionen com qualsevol altre canvi.
Sigui quin sigui l’esquema, tres regles el fan segur. Els fitxers de destinació només els ha d’escriure el flux de traducció, perquè les edicions manuals no desapareguin a la sincronització següent. Les claus han de ser estables, perquè una clau reanomenada sembla una cadena eliminada més una altra de nova, i la traducció existent es perd. I l’estratègia de branques s’ha d’acordar per endavant: traduir cada branca de funcionalitat malbarata esforç en funcions que no surten mai, mentre que traduir només la branca de llançament deixa molt poc temps, així que molts equips tradueixen des de la branca principal després de la fusió.
Pregunteu al vostre proveïdor exactament com li arriben els fitxers i com tornen. Un tractament natiu de JSON, XML i fitxers de cadenes propis de cada sistema operatiu, retornats sense claus trencades ni canvis de codificació, elimina tota una categoria d’errors de compilació.
Memòria de traducció i glossari al llarg de les versions
Un producte amb cinquanta versions l’any genera cinquanta petits lliuraments de traducció. Sense una única memòria de traducció al darrere, el producte va acumulant tres traduccions de «workspace», dues maneres d’adreçar-se a l’usuari i verbs diferents als botons.
La memòria de traducció és el que fa que la localització contínua sigui rendible i coherent. Cada traducció aprovada es desa amb el seu text original; quan una cadena torna a aparèixer, igual o lleugerament modificada, es reutilitza la redacció aprovada i només es tradueix la diferència. La memòria ha de ser vostra, no del proveïdor, i s’ha de poder exportar en qualsevol moment en un format portable. Per això el valor estratègic de la memòria de traducció pesa més en un producte SaaS que en gairebé qualsevol altre contingut.
El glossari fa el mateix amb els termes. Un producte SaaS té un vocabulari reduït i molt utilitzat: noms de funcions, noms de plans, tipus d’objecte, accions. Cada terme necessita una traducció aprovada per idioma i una decisió sobre quins noms es queden en anglès. El màrqueting de producte sol reanomenar funcions, de manera que el glossari necessita un responsable que l’actualitzi abans que surtin les cadenes noves. El nostre article sobre la gestió terminològica centralitzada entre traductors i proveïdors explica com crear i mantenir aquest glossari.
Les decisions d’estil hi van just al costat. Tracteu els vostres usuaris de tu o de vostè? Els botons són verbs o substantius? Com es redacten els missatges d’error? Si també publiqueu en castellà, a més, convé decidir si la interfície s’adreça a Espanya, a l’Amèrica Llatina o a tots dos mercats amb una variant neutra. Una breu guia d’estil per a la traducció per idioma respon aquestes preguntes una sola vegada per a tots els traductors i revisors.
Context, revisió en context i proves de localització
Els textos d’interfície són curts i ambigus. «Archive» pot ser verb o substantiu, i «Free» es pot referir al preu o a la disponibilitat. En la localització contínua el risc augmenta, perquè el traductor veu un grapat de cadenes per paquet i no el producte sencer. Amb cada paquet de canvis hauria de viatjar el context: un comentari a cada clau ambigua, una nota sobre què conté cada marcador de posició, la llargada màxima allà on l’espai és fix i, si és possible, una captura de pantalla o un enllaç a l’entorn de proves.
Les proves de localització converteixen traduccions correctes en un producte correcte. Tenen dues parts. Les comprovacions funcionals confirmen que la compilació localitzada funciona: res de text en anglès codificat de manera fixa, etiquetes tallades, marcadors de posició trencats, formats de data, de número o de moneda incorrectes ni caràcters que no es mostren. Moltes es poden automatitzar i executar a cada compilació. La prova lingüística, o revisió en context, la fa una persona que llegeix l’idioma: recorre els principals itineraris de l’usuari a l’entorn de proves i comprova que cada traducció encaixa en el seu context, que la terminologia és la mateixa d’una pantalla a l’altra i que res no sona a fragment.
No cal una prova lingüística completa de cada idioma cada setmana. Un ritme pràctic combina comprovacions automàtiques a cada compilació, revisió en context de les funcions noves i un recorregut complet a les versions importants o quan es llança un idioma nou. Cada correcció ha de tornar a la memòria de traducció, no només a la compilació, o l’error tornarà a aparèixer a la sincronització següent. La nostra guia sobre el control de qualitat de la traducció explica com plantejar una revisió que generi observacions útils i no preferències personals.
Interfícies mòbils: llargada, plurals, gènere i escriptura de dreta a esquerra
La localització d’aplicacions mòbils afegeix limitacions que una interfície web sol absorbir: poc espai a la pantalla, etiquetes a la barra de navegació i mides de text dinàmiques.
Llargada. El text traduït sol ser més llarg que l’anglès, i les cadenes curtes són les que creixen més en proporció: un botó de dues paraules pot duplicar la seva llargada en català, en castellà o en alemany. Fixeu límits de caràcters per a les cadenes en espais fixos, feu proves aviat amb l’idioma més llarg i permeteu que el traductor proposi una redacció més breu en lloc d’imposar una abreviatura que no entén ningú.
Plurals. L’anglès necessita dues formes («1 file», «2 files»). Molts idiomes en necessiten més: el polonès distingeix entre un, pocs i molts, i l’àrab fa servir fins a sis categories. Els dos grans sistemes operatius mòbils i els formats de missatge habituals admeten categories de plural, però només si el desenvolupament les fa servir en lloc de concatenar un número i una paraula.
Gènere i concordança. En català, com en les altres llengües romàniques, en les eslaves i en alemany, adjectius, participis i de vegades verbs concorden amb el gènere del substantiu o de la persona. Una cadena com «{name} has been invited» necessita «convidat» o «convidada» segons qui sigui. Allà on el producte coneix el gènere o el tipus d’objecte, les cadenes separades o els formats de selecció permeten frases correctes; allà on no el coneix, el traductor ho ha de saber per buscar una formulació neutra.
Escriptura de dreta a esquerra. L’àrab i l’hebreu inverteixen la interfície: la navegació, les icones amb direcció i els indicadors de progrés es reflecteixen, mentre que els números i el text llatí incrustat continuen anant d’esquerra a dreta. El suport de dreta a esquerra és una tasca d’enginyeria que s’ha de provar en dispositius reals abans de poder jutjar la traducció.
Fitxes de la botiga, notes de versió i centre d'ajuda
La interfície és només una part del que llegeixen els usuaris. En una app mòbil, la fitxa de la botiga és el primer text localitzat que veu el client: títol, subtítol, descripcions curta i llarga, paraules clau i textos de les captures. Cada botiga fixa els seus límits de caràcters, i la fitxa és text comercial, no d’interfície. En la traducció d’apps convé confiar-la a un traductor que escrigui de manera persuasiva dins d’aquests límits i comprovi com busquen els usuaris de cada mercat aplicacions com la vostra. Els textos de les captures s’obliden fàcilment, perquè són en fitxers d’imatge i no en fitxers de cadenes.
Les notes de versió s’escriuen a última hora i les llegeixen els vostres usuaris més actius. Doneu-los una finestra de traducció breu i fixa i reutilitzeu la terminologia de la interfície, perquè la funció que esmenten les notes sigui la mateixa que l’usuari troba a l’app.
El centre d’ajuda sol créixer més de pressa que la interfície. Els seus articles són llargs, repetitius i s’actualitzen sovint, i per això són bons candidats per a la traducció automàtica amb postedició a càrrec d’un lingüista qualificat, sempre que el motor treballi amb el vostre glossari i la vostra memòria aprovats. A la nostra pàgina de traducció automàtica amb postedició expliquem com decidim segons el tipus de contingut. Els textos d’interfície són un altre cas: curts, ambigus i visibles a cada pantalla, de manera que en general necessiten un traductor humà des del començament. El vostre lloc web corporatiu segueix al seu torn una lògica diferent, amb criteris de cost i de posicionament propis.
Mesurar la reutilització i el cost per versió
En la localització contínua, la tarifa per paraula explica menys del pressupost que la composició de cada versió. Cada paquet de canvis conté text realment nou, text semblant a alguna cosa ja traduïda i text idèntic a una traducció aprovada, per exemple una cadena que s’ha traslladat a una altra pantalla. La proporció de text reutilitzat s’anomena aprofitament (leverage) i és la xifra més útil per entendre el cost.
Un exemple il·lustratiu: un esprint modifica 1.500 paraules d’interfície i d’ajuda. D’aquestes, 700 són noves, 500 són coincidències parcials amb traduccions existents i 300 són repeticions exactes. En sis idiomes són 4.200 paraules noves per traduir, 3.000 per adaptar i 1.800 per verificar, en lloc de 9.000 paraules traduïdes des de zero. Si el proveïdor detalla aquest repartiment a cada lliurament, veieu per què un esprint va costar més que un altre i detecteu problemes a temps: una caiguda brusca de l’aprofitament sol indicar que s’han reanomenat claus o reestructurat fitxers, i que la memòria ja no reconeix text que conté.
Tres factors més mouen el cost per versió. La mida del paquet: cada lliurament comporta un esforç fix de gestió de fitxers i comprovacions, així que enviar cadenes soltes surt car. La rotació: el text que es reescriu després de traduir-lo es paga dues vegades. L’abast de les proves: la revisió en context s’ha de planificar a cada versió, no descobrir-se després d’una queixa. Al cap d’uns quants mesos, els informes per versió donen a l’equip de producte una base fiable per pressupostar idiomes i funcions nous.
El procés de localització d'apps en un esprint, pas a pas
Així sol desenvolupar-se la localització d’apps en un esprint de dues setmanes, un cop la base està muntada.
A l’inici de l’esprint, producte i disseny acorden quines funcions surten i en quins mercats. Els termes nous, com ara el nom d’una funció, s’afegeixen al glossari amb les seves traduccions abans d’escriure cap cadena.
Durant el desenvolupament, els desenvolupadors creen les claus amb comentaris i límits de caràcters. Quan es fusiona una branca de funcionalitat, les cadenes noves i modificades es recullen automàticament i comença la traducció. Les consultes dels traductors arriben a una persona concreta del vostre equip, que respon el mateix dia.
A meitat de l’esprint, les traduccions tornen pel repositori, com a pull request o com a fitxers a la ubicació acordada. S’executen comprovacions automàtiques sobre la compilació: marcadors de posició, llargada, codificació i traduccions absents.
Abans del llançament, un revisor recorre les funcions noves en cada idioma a l’entorn de proves. Les notes de versió, els textos de la botiga i els articles d’ajuda es tradueixen en una finestra breu i fixa. Les correccions es fan a l’entorn de traducció perquè quedin a la memòria.
Després del llançament, el proveïdor informa de l’aprofitament per idioma, i els problemes recurrents, com ara la manca de context, es corregeixen per a l’esprint següent.
Errors habituals en la localització contínua
Editar els fitxers de destinació a mà. Un desenvolupador corregeix una errada directament al fitxer en català; la sincronització següent la sobreescriu, o la correcció no arriba mai a la memòria i l’error torna a la versió següent.
Reanomenar claus en refactoritzar. Per a un sistema de traducció, una clau reanomenada és una cadena nova. L’aprofitament cau, es refan traduccions i la redacció aprovada canvia sense que ningú no ho hagi decidit.
Deixar que cada equip o proveïdor tingui la seva pròpia memòria. Si l’app, el centre d’ajuda i el web es tradueixen per separat, la terminologia es dispersa, i canviar de proveïdor més endavant suposa perdre anys de traduccions aprovades. Si les vostres traduccions anteriors només existeixen com a fitxers solts, l’alineació de memòries de traducció permet recuperar-les i reutilitzar-les des del primer lliurament.
Com triar un proveïdor per a la traducció d'aplicacions
El proveïdor adequat per a un cicle de llançaments continu és aquell la manera de treballar del qual encaixa amb la vostra cadena de lliurament, no simplement el més barat per paraula. Aquestes preguntes revelen gairebé tot el que necessiteu saber:
- Com li arriben els fitxers i com tornen, i pot tractar els nostres formats de recursos de manera nativa sense trencar claus ni marcadors de posició?
- Quin termini es pot comprometre a complir per a un paquet típic d’esprint, i com gestiona les cadenes urgents?
- Quines comprovacions automàtiques s’executen abans del lliurament, i revisa cada traducció un segon lingüista qualificat?
- Poden els nostres desenvolupadors o responsables de producte revisar les traduccions en context, i les seves correccions actualitzen la memòria?
- De qui són la memòria de traducció i el glossari, i els podem exportar en qualsevol moment en un format estàndard?
- Informa per versió i per idioma del text nou, les coincidències parcials i el text reutilitzat?
Les respostes pesen més que qualsevol certificat en un web, tot i que un procés certificat segons la ISO 17100 indica que la revisió per un segon lingüista és la norma i no un extra opcional.
Com dona suport DEMA Solutions als equips de SaaS i d'apps
Les nostres solucions lingüístiques per al sector tecnològic estan pensades per a equips de producte que publiquen de manera contínua. Les cadenes noves i modificades es recullen i es tradueixen a cada versió, al ritme dels vostres esprints, en lloc d’agrupar-se en grans projectes ocasionals. Els fitxers JSON, XML i altres fitxers de recursos es processen i es retornen amb la seva estructura original, sense extracció manual i sense claus trencades. Les comprovacions automàtiques detecten variables trencades, cadenes d’interfície tallades i errors de format abans que arribin a una compilació de llançament.
Els nostres traductors són lingüistes tècnics natius que treballen amb terminologia de programari i de desenvolupament. Els vostres enginyers i responsables de producte poden revisar directament a l’entorn de traducció, sense fulls de càlcul exportats, de manera que les correccions terminològiques arriben a la memòria immediatament. El procés està certificat segons la ISO 17100, amb un segon lingüista qualificat que revisa cada traducció, tal com es descriu a la nostra pàgina de qualitat de traducció.
La memòria de traducció, els glossaris i les bases terminològiques es construeixen amb la terminologia del vostre producte i continuen sent vostres, exportables a petició en qualsevol moment en formats portables com ara TMX i TBX. Els informes d’aprofitament mostren quina part de cada versió s’ha reutilitzat. Més enllà de la interfície, els nostres equips a Itàlia, Sèrbia i Espanya tradueixen centres d’ajuda i bases de coneixement, documentació d’API i per a desenvolupadors, notes de versió i registres de canvis, perquè el producte i tot el que l’envolta comparteixin una mateixa terminologia.
On encaixa TUBE
TUBE és la nostra solució per a productes amb llançaments continus, en què cada esprint suposa un nou cicle de localització. El vostre glossari i la vostra memòria de traducció controlen la traducció automàtica, cada traducció aprovada s’incorpora a una memòria que és vostra i que podeu exportar, i els informes d’aprofitament mostren quina part de cada actualització prové de text que ja heu aprovat.
Preguntes freqüents
És l'adaptació d'una aplicació mòbil o web a usuaris d'altres idiomes i mercats: interfície, benvinguda, notificacions, centre d'ajuda, notes de versió i fitxa de la botiga. A més de la traducció, inclou formats, plurals, llargada del text i proves en context, i per això també se'n diu localització d'apps.
Consisteix a enviar a traducció les cadenes noves i modificades tan bon punt són estables, en lloc d'acumular-les fins a una congelació de cadenes abans de cada versió. Les traduccions tornen al mateix ritme, de manera que cada idioma es pot publicar juntament amb l'original.
No necessàriament per a tot el producte. Molts equips deixen fluir de manera contínua la interfície i l'ajuda i mantenen una congelació breu per als textos més visibles o d'última hora, com ara les notes de versió, les pàgines de preus i les fitxes de la botiga.
Les comprovacions funcionals confirmen que la compilació localitzada funciona: sense text codificat de manera fixa, talls, marcadors de posició trencats ni formats erronis. La prova lingüística comprova en pantalles reals que cada traducció encaixa en el seu context i que la terminologia és coherent.
Amb una sola memòria de traducció i un sol glossari per a tot el contingut del producte, un glossari que s'actualitza abans que apareguin termes nous, correccions fetes a l'entorn de traducció i no als fitxers de destinació, i claus de cadena estables.
Millor per versió que per any, a partir del volum de text nou, coincidències parcials i text reutilitzat en cada idioma. Els informes d'aprofitament de versions anteriors són la base més fiable per estimar el cost de funcions i idiomes nous.
Sol funcionar bé per als articles d'ajuda i la documentació, si treballa amb el vostre glossari i la vostra memòria aprovats i un lingüista qualificat en fa la postedició. Les cadenes curtes d'interfície i les fitxes de la botiga solen necessitar un traductor humà des del començament.
Una localització que segueixi el ritme de les vostres versions
Si els vostres idiomes surten més tard que l’original, o cada versió porta una nova ronda d’incoherències, expliqueu-nos com és el vostre producte, el vostre ritme de llançaments i els vostres idiomes de destinació. Revisarem els vostres fitxers de recursos i us proposarem un flux de localització que encaixi en els vostres esprints.
Com us podem ajudar?
Expliqueu-nos què necessiteu i us respondrem amb les solucions adequades.