LSO: how to linguistically approve a product for its release?
By Mónica Vega, Project Manager.
Before composing this post, I have looked back a few years ago when I was starting as a translator and I was new in the localization industry… I had to deal with several terms that I had never heard during my translation studies at the university. Nowadays the industry has changed very much. Internet is a very important and rich source of information for all students that have completed the Translation and Interpreting Degree, for that reason I would like to use this communication platform and dedicate my post to a very common task in the localization field, the Linguistic Sign-off or LSO, in order to help those translators that receive a LSO request but do not know how to accomplish it.
As a project manager, I receive many LSO requests from the clients every day. This task could be included within the several quality controls that are applied to a translated product before being submitted to the client. The Linguistic Sign-off is one of the last steps, it takes place when the text has already been translated, edited and proofread. It has passed through different automated quality controls and it is also possible that a reviewer did a LQI (see the post https://novalo.com/translation-tests-lqis/ in this blog). Therefore, our last contribution as linguists is to confirm the quality and accuracy of the text for being published, i.e. to « linguistically sign-off » a text in our argot.
During this phase we visually review the document or product —since we could also receive a LSO request for a video, web page or online course, for example— after being formatted by the engineers in order to detect and fix all possible bugs or errors that were entered during the DTP (Desktop Publishing) processes.
As a general rule, a predefined time is allocated to complete this task because the budget is very tight at this stage of the project and it is assumed that the text has passed through many quality filters, so the possibility of errors should be low.
To which items should we take special attention during our LSO check?
In this phase we must get straight to the point, which means to focus only on actual errors and avoid preferential changes. For this reason I recommend focusing mainly on the following items:
1- Layout of cover pages, headers and footers
2- Correct translation of titles and headings (in some cases segmentation may be tricky)
3- Numbers: it must be verified that we have not missed any number and that they are correctly translated according to the target language (for example, verifying that we have used decimal comma instead of point in Spanish, or changing the position of currency symbols when needed)
5- Presence of unlocalized text
6- Images: text included in images and graphics has to be correctly translated and consistent with running text
7- Overlapped or truncated text: this usually happens due to resizing issues, different font sizes or because images are not properly inserted
8- Layout issues such as font type or color, paragraph alignment, etc.
9- Date format
10- Punctuation: this must be correct and consistent according to the target language rules (for instance, punctuation in bulleted list)
11- Capitalization: when we can see the text in-context, it is easier to determine whether we have to use upper or lowercase
12- Links and buttons: we need to verify that they are correctly translated and work properly
13- Tables of contents: it is important to check that titles and sections are consistent with the table of contents
Of course, this list can be extended and enhanced based on the kind of document we are checking. As I mentioned above there are many product formats, therefore the LSO procedures will change whether we are checking a PDF file, a Word document, an online course or platform or a webpage. In the following lines I will explain each scenario in detail.
How to do the final LSO of a PDF document?
To accomplish this task, we will need a PDF reader program with annotation tools. We can find a free version of most PDF creator programs, such as Adobe Acrobat, Foxit, Nitro, etc. so we can use them without adding costs. All of them include a comment menu with different editing tools: highlight, strikeout, replace or insert text. Also there are other functions, such as inserting annotations or forms (rectangles, circles, arrows…), that enable us to insert global explanations or mark out the area affected by our comments.
For example, see the Nitro toolbar below:
When we insert an annotation, it is very important to keep in mind that the DTP engineer who is going to implement the changes does not speak or understand our language so the comments need to be written in English and must be clear and concise. We have to avoid ambiguities or nuances that could confuse the DTP engineer.
Every customer establishes his or her preferences and every translator applies his or her criteria but I recommend using the highlight tool whenever possible for helping the engineers to locate the error. Also the comments should be clear as the following ones:
How to do the final LSO of a Word document?
This scenario is maybe the easiest, since we have direct access to text, so we just need to check the document with the track changes function enabled and the engineer or client will be able to see what changes are to be implemented. For those changes that are to be previously approved by client or when they affect images and we cannot edit them, we can insert comments or text boxes with our indications.
How to do the final LSO of a product such an online course, a web page or a video?
Unlike the above situation, in this case we cannot edit the text, so the procedure is a bit more complex and time-consuming. Depending on the guidelines established by the client, we will have to record the errors in a bug database, register them in a form designed by the client or in a Word or Excel file created by us.
One of the most complex questions for this LSO is to be able to locate the bug properly since it is not always easy to explain to the engineer where or how to implement the change. There are several ways to do it, from indicating the page number or title to explaining the steps to reproduce the actions that lead us to the bug. I personally recommend including a screenshot along with our comments. Although the engineer can easily locate the bug, it is always more visual that we edit the screenshot and point out the exact position of the bug. Again we cannot forget that the engineer does not know our language and could be difficult for him or her to identify which word to change when there are more than one occurrence of the same word.
The Snipping Tool from Windows allows us to take screen captures in an easy manner and we can disregard the need of using other additional tools. However, if we need more advanced functionalities, we can use other tools such as Screenshot Captor, which includes functions to edit images; or SnapDraw, that enables us to save the images to clipboard, email or FTP, or DuckCapture, very intuitive and user-friendly.
How do we deliver the final LSO?
For LSO delivery, we need to include the annotated PDF, the Word document with track changes or the bug form with detailed errors and screenshots but, apart from that, it is very likely that we have to deliver the updated bilingual or clean files with our changes applied for record purposes.
Although we can think that the task finishes here… there is still another additional step usually called « LSO Regression » after delivering the LSO. The idea is checking that changes have been correctly applied. If we are lucky, there will not be any outstanding error and we will say goodbye to the text forever (after reading so many times a text, you need a definitive farewell). However, depending on the engineer’ skills and the clarity of our comments (I insist: be as clear and concise as possible), it could happen that errors were not properly implemented and we even need to do a second round of LSO Regression before confirming the quality of a text.
At this point I finish my introduction to this task, and I hope this post has been interesting and useful, especially to the translators with less experience. Please do not hesitate to send your comments to clarify doubts or procedures. I see you in my next post…
Sin respuestas a "LSO: how to linguistically approve a product for its release?"