ESCENARI
De llarg, l’escenari més complicat i un que és comú només per als proveïdors de serveis lingüístics que treballen per a altres empreses de traducció, normalment més grans. Comprèn dos subescenaris: El primer amb l’extracció de paquets i el segon amb la reassignació de proveïdors (no entrarem en detall, ja que ja està cobert a l’escenari 4 i a l’escenari 5).
Quan hi ha paquets de traducció implicats, l’eina CAT en línia de l’Automator pot crear un altre subescenari amb les complexitats descrites a l’escenari 3.
En aquest escenari, la feina de traducció arriba al sistema del client, com ara el portal Junction de Welocalize, però el treball de traducció es duu a terme en un altre lloc, com ara la instància Smartling del client.
Un altre cas típic és l’ús de Plunet o XTRF per configurar un projecte en una eina CAT en línia com memoQ o Memsource, i requerir al proveïdor que hi treballi. En aquest subescenari, els sistemes i els fluxos de treball són els mateixos, excepte que ambdues plataformes són propietat del client (i no del client final).
En el primer subescenari, el portal del proveïdor només proporciona a l’Automator les seves credencials d’usuari i l’identificador del projecte al sistema de gestió de traduccions. Hauran d’iniciar sessió a l’altre sistema i recuperar els paquets o assignar el projecte al seu traductor.
En el segon subescenari, hi ha una integració entre el portal del proveïdor i el sistema de gestió de traduccions, i l’Automator configura les assignacions d’usuaris al portal del proveïdor. Com a nota addicional per a grans LSP, és important tenir en compte que aquestes configuracions dificulten l’automatització, ja que augmenten el nombre de sistemes compatibles.
Aquest escenari mostra el nivell de complexitat que els grans proveïdors de traducció (MLV) amb la seva pròpia tecnologia afegeixen a la cadena de subministrament.
SISTEMES IMPLICATS
REQUISITS PER A L’AUTOMATITZACIÓ
En aquest cas, la coordinació entre el client i l’Automator (les dues empreses de traducció) és gairebé sempre imprescindible. El client ha de formalitzar la manera com subcontracta la feina (p. ex., evitar instruccions o fitxers addicionals per correu electrònic) i com connecten els dos sistemes.
Sovint hi ha situacions en què això és implícit i no hi ha cap senyal de l’altre sistema al portal del proveïdor, a part de la seva menció a les instruccions, sense més detalls. No obstant això, hi ha moltes situacions en què això era inconvenient: en lloc d’un “tipus de TMS”, “TMS URL”, “nom d’usuari de TMS”, hi ha molts casos en què un fitxer de Word de referència explica quin sistema s’està utilitzant i com fer els lliuraments, però no hi ha una identificació fàcil del projecte en qüestió; era una conjectura humana.
LA SOLUCIÓ BELAZY
Aquest tipus d’automatització és tècnicament viable, però desafiant a causa de la multitud de fluxos de treball en qüestió. Requereix discussió i un objectiu d’automatització per a cada part del procés per trobar una solució que funcioni per a tothom.
En lloc de simplement proporcionar solucions tècniques, cosa que és fàcil amb sistemes més senzills i comercialment disponibles, en aquest cas, prenem la iniciativa per facilitar una discussió entre grans empreses de traducció i els seus subcontractistes (SLV).
IMPLEMENTACIÓ D’EXEMPLE
TMS del client o eina CAT del client
BMS de l’Automator, possiblement eina CAT de l’Automator
Prova BeLazy amb el teu equip
Tell us more about your workflow and we will get back to you shortly
LOGIN WITH MICROSOFT
LOGIN WITH GOOGLE
