E-learning localisation process

Upon receiving the source files from our client, we do double-check that the content type and that the files received are all editable and open properly. We also analyse them against our translation memories to see the final word count. We check whether there are any media elements embedded into the modules such as voice over, videos or images and look for potential resources being linked to the module.

At this stage we provide you with a quotation in which we will itemise the services requested and break down the word count for translation as per the matches we found in our translation memory (new words, repetitions, 100% matches) which will reduce the final cost. All our quotations are free of charge. This is also the stage where we discuss the costs and timeline associated with the different project steps. Once we are all set and get your go-ahead, we can start the localisation process.

While our team is organising the material received and making files localisation friendly, we are also lining up the selected resources for the project. This is also the moment when our team extracts any on-screen text, meaning the dead text present in images and videos. We also prep and time the audio scripts for the potential audio narration of the module or the voice over in the videos. SRT files are also created if video subtitling is involved. We take great care in selecting the right linguists for the material you send through. All our linguists have areas of specialisation and native languages which need to match your project to be considered. It is our job to find the best suitable linguists based on the specifics of the project. Depending on the client’s requirements, our team will now build a glossary as well to define the key terms, technical words and highly repeated words on which we need to consult our client’s SMEs in order to obtain approval before kicking off the actual translation stage. The glossary is then shared with our linguists which they will rigorously follow to produce localised content fully aligned with the client’s SMEs expectations.

The files to be localised have been prepped for translation in a previous step (image content, video content, resource content, e-learning export with slide content or page content, scripts) and are now sent to the relevant linguists who will work on the project. The translation received is then QA’ed by our project team through our internal verification step.

Once the translation step is completed and that the output has been verified by our team, we send the files to a revisor or proofreader, a second experienced linguist, who will compare the source text against the target text to make sure the translation is accurate and true to the source text. The proofread translation is then QA’ed by our project team through our internal validation step.

Before typesetting the translated content back into the source environment, Transladiem always offers our clients the opportunity to review the localised content in a friendly format (a bilingual table with source and target content presented in a word document or via our online review platform) and to add any potential changes they wish to make at this moment. This step exposes our work directly to the client in order to get amendment requests or sign-off on the translation before proceeding with the next steps of the localisation process. This step is highly recommended but remains optional as not all companies have the capacity to run through this. If our stakeholders insert edits into the bilingual tables containing the translations, we will check these changes to make sure there are no typos, grammar errors, double-spaces or any kind or wrong insertions before implementing all amendments.

Once all translated contents have been signed off internally and via the client review step, we can start recording the module audio narration and the video scripts using the voice talents selected by our client. Our project team will also run the compulsory QA checks on the audio clips recorded to verify the adherence to the scripts and that the instructions in terms of tone of voice, specific pronunciations and emphases have been respected.

When the translated contents are signed off and all scripts recorded, our video editors get involved in this localisation process as well if the module contains video. Our project team share with our video editing team the materials that will be used to localise the video into the target languages (localised SRT files, timed audio clips and translated on-screen texts). Our project team runs QA checks on the videos before sharing them with our e-learning engineer to be dropped into the module place holders.

When the localised content of the resources, images or side files (such as facilitator guides) is signed off internally or via the client review step, we will typeset the content into the original source file environment to mirror the original documents we received. Our team will then QA the work of our formatters, typesetters and a desktop publishing operators by skimming through the document to make sure all the elements are well displayed. Here truncation, alignment, punctuation, layout and display issues are fixed to make sure the file is ready to be used or printed.

This is the step in which we rebuild the module. All translated content is populated back into its original e-learning frame and our engineer works on the page and slide layout. Our engineer synchs the audio narration and the closed captions based on the slide or page duration as well as drops back into the module place-holders all media elements (images and videos). We also link the external resources to the module.

When the localised modules have been rebuilt, we ask native testers to go through them in order to flag any potential issue such as missing translation, wrong display, truncated words or functionality issues. Our team creates a bug report in which we screenshot the bugs, explain the issue and how it should be fixed so our e-learning engineer can apply the corresponding fixes. Our engineer fixes all language-related bugs and our project team check that the final changes reported have been implemented correctly before sending the Alpha version to the client, which is the first version delivered on which we expect feedback or sign-off from our client.

We send Alpha to the client. The client reviews the translated modules, indicates the languages that are signed off and the ones that will come back to us to perform some last language-related or display adjustments.

If changes are required for some languages, we check these changes, clarify them with the client if these create any inconsistency with the rest of the module and implement them according to the client’s instructions and latest discussions. The updated module created by implementing the client’s Alpha feedback is the Beta version, which is the second version delivered to the client. In most cases, the Beta version is also called the gold version as being the final one. In rare scenarios, more rounds of feedbacks can be added until obtaining final sign-off on all languages.

We deliver the Beta version of the modules and await client’s sign off or new changes to be implemented. We can deliver the open files (.CPTX, STORY, editable modules via RISE or Elucidat platforms, etc) or directly the SCORM packages.