Hoe u een vertaalkoppeling voor een bestaande bedrijfsapp afbakent
Plan vertaling in uw bedrijfsapp. Leg inhoud, talen, controle, gegevensregels, foutafhandeling en acceptatietests vast voordat u een offerte aanvraagt.
Begin met één volledige taak die uw team in een andere taal moet uitvoeren. Bepaal daarna hoe vertaling in die taak past. Zo geeft u een softwareleverancier een duidelijkere basis voor een schatting dan met een verzoek om een vertaalknop toe te voegen.
De afbakening moet de tekst, de mensen, de gegevens en het resultaat omvatten. Ze moet ook uitleggen wat er gebeurt als de vertaling mislukt. Gebruik de onderstaande stappen om die afbakening voor te bereiden voordat u een technische aanpak kiest.
Kies één werkstroom voor de eerste release
Schrijf op waar de brontekst vandaan komt en waar de goedgekeurde vertaling naartoe moet. Een supportmedewerker moet bijvoorbeeld een binnenkomend bericht lezen en een antwoord voorbereiden in de taal van de klant. Dit is een illustratieve eis, geen verslag van een Vavus-installatie.
Zet elke stap op een rij: het bericht openen, een vertaling aanvragen, de brontekst naast het resultaat lezen, het antwoord bewerken en het goedkeuren voor verzending. Bepaal of de vertaling automatisch start of pas nadat een medewerker daarvoor kiest.
Houd de eerste release klein. Eén scherm en één duidelijke bedrijfstaak zijn makkelijker te testen dan elk tekstveld in een applicatie.
Breng de behoeften aan inhoud en talen in kaart
Maak een lijst van de velden die vertaald moeten worden. Maak onderscheid tussen korte labels, vrije tekst, documenten en spraak. Die kunnen een andere verwerking en andere tests vereisen. Noteer ook velden die ongewijzigd moeten blijven, zoals ordernummers en productcodes.
Leg de bron- en doeltalen vast, inclusief eventuele regionale varianten. Noteer de gebruikelijke tekstlengte en het verwachte dagelijkse volume. Vraag welke taalcombinaties en invoerformaten de voorgestelde dienst ondersteunt.
Context kan belangrijk zijn bij korte tekst. De tekst-API van DeepL ondersteunt bijvoorbeeld een contextparameter die de vertaling kan beïnvloeden zonder dat de context zelf wordt vertaald. Volgens de documentatie delen afzonderlijke tekstitems in één verzoek ook geen context. [1] Uw afbakening moet vermelden waar bruikbare context vandaan komt.
Leg terminologie en menselijke controle vast
Verzamel de termen die uw bedrijf vaak gebruikt. Neem voorkeursvertalingen, productnamen en woorden op die onvertaald moeten blijven. Wijs één persoon aan die deze lijst bijhoudt.
Sommige vertaaldiensten ondersteunen glossaria. Google Cloud Translation omschrijft zijn glossarium als een aangepast woordenboek voor consistente vakterminologie. [2] Controleer de functie voor uw precieze taalcombinaties en de gekozen dienst. Een glossarium bewijst niet dat het hele bericht juist is.
Bepaal welke uitvoer moet worden gecontroleerd door een gekwalificeerde taalkundige beoordelaar. Geef de beoordelaar toegang tot de originele tekst. Leg een duidelijke goedkeuringsstap vast voordat tekst voor klanten wordt verzonden of gepubliceerd.
Stel regels op voor gegevens en toegang
Beschrijf welke informatie de werkstroom verwerkt. Gebruik kunstmatige voorbeelden tijdens de eerste tests. Kopieer geen echte klantgegevens naar een proef alleen om te zien of een knop werkt.
Vraag waar de tekst wordt verwerkt, wat de applicatie opslaat, wie die kan lezen en wanneer die wordt verwijderd. Betrek logbestanden en back-ups bij dit gesprek. Controleer de actuele voorwaarden van de aanbieder en de beheermogelijkheden die bij het gekozen abonnement beschikbaar zijn.
Een eigen interface maakt een externe vertaaldienst op zichzelf niet privé of offline. Vereist uw project lokale verwerking, vermeld die eis dan vanaf het begin en test de volledige gegevensstroom daartegen.
Houd rekening met vertragingen en fouten
Leg de verwachte responstijd vast en wat medewerkers moeten doen als de dienst niet beschikbaar is. De applicatie moet een duidelijke status tonen, zoals wachten, klaar voor controle of mislukt. Bewaar de originele tekst.
Vraag de ontwikkelaar om tijdelijke storingen te onderscheiden van fouten waarvoor een wijziging nodig is. DeepL beschrijft bijvoorbeeld vertraagde nieuwe pogingen bij fouten door snelheidslimieten, terwijl een uitgeput quotum een andere reactie vereist. [3] Herhaalde verzoeken mogen niet leiden tot dubbele bedrijfshandelingen, zoals hetzelfde antwoord twee keer versturen.
Spreek gebruiksmeldingen af en wie verantwoordelijk is voor de ondersteuning. Neem servicekosten, onderhoud en toekomstige wijzigingen mee wanneer u projectkosten vergelijkt.
Schrijf acceptatietests vóór de ontwikkeling
Kies representatieve voorbeelden voor elke benodigde taalcombinatie. Neem lange berichten, ongebruikelijke tekens, ontbrekende velden en termen uit uw goedgekeurde lijst op. Test de hele taak, van het bronrecord tot het opgeslagen of verzonden resultaat.
Stel criteria op die mensen kunnen controleren: productcodes blijven ongewijzigd, een niet-goedgekeurde vertaling kan niet worden verzonden, een mislukt verzoek is zichtbaar en de beoordelaar kan terug naar de bron. Laat een gekwalificeerde beoordelaar betekenis en toon beoordelen. Leg gebreken vast en herhaal dezelfde tests na wijzigingen.
Bereid een duidelijke offerteaanvraag voor
Stuur de werkstroom, voorbeeldvelden, taalcombinaties, het geschatte volume, de gegevensregels en de acceptatietests mee. Geef bij elk onderdeel aan of het nodig is voor de lancering of geschikt is voor een latere release. Vraag de aannames en uitsluitingen schriftelijk op.
Vavus biedt schriftelijke afbakening voor maatwerkprojecten. [4] Gebruik de offertepagina om uw bestaande applicatie te beschrijven en de taak die u wilt verbeteren. De voorgestelde koppeling, uitrol en tests moeten worden vastgelegd in de afbakening van uw project.
Vraag een schriftelijke offerte aan