Difference between revisions of "How to tackle an Approval"
m (→Include links to guidelines and tutorials)
m (→What is the job of an approver?)
|Line 2:||Line 2:|
==What is the job of an approver?==
==What is the job of an approver?==
Approval is the last task before publishing, so the approver has to verify the quality of the translation
Approval is the last task before publishing, so the approver has to verify the quality of the translationmistakesthe transcript or translation were poorly reviewed and extensive editing is necessary, the approver should the task back with instructions detailing what needs to be changed and how (ideally including links to helpful resources like the [reviewing talks]).
'''Important:''' Note that when you send back a review, this may cause a crediting error where you will end up being credited for the subtitles. If this happens, please email the TED OTP team at [mailto:firstname.lastname@example.org email@example.com], explaining what happened, and including all the relevant info (link to the talk on Amara and on TED.com/YouTube and the
'''Important:''' Note that when you send back a review, this may cause a crediting error where you will end up being credited for the subtitles. If this happens, please email the TED OTP team at [mailto:firstname.lastname@example.org email@example.com], explaining what happened, and including all the relevant info (link to the talk on Amara and on TED.com/YouTube and the of the people who should get credited).
==How to approve a task==
==How to approve a task==
Revision as of 10:01, 20 October 2014
Approval is the last step that the translation or transcript go through before they are published. Approvals are done by Language Coordinators after a transcript or translation have been reviewed.
- 1 What is the job of an approver?
- 2 How to approve a task
- 3 How to select tasks for approval
- 4 What to put in your team notes
What is the job of an approver?
Approval is the last task before publishing, so the approver has to verify the quality of the translation. The approver also corrects mistakes, but if the transcript or translation were poorly reviewed and extensive editing is necessary, the approver should send the task back with instructions detailing what needs to be changed and how to fix the issues found in the subtitles (ideally including links to helpful resources like the tutorial on reviewing talks).
Important: Note that when you send back a review, this may cause a crediting error where you will end up being credited for the subtitles. If this happens, please email the TED OTP team at firstname.lastname@example.org, explaining what happened, and including all the relevant info (link to the talk on Amara and on TED.com/YouTube and the links to the TED.com profiles of the people who should get credited).
How to approve a task
Below, you will find instructions on what aspects may need fixing and how to fix them. Remember that if you find the transcript or translation need extensive changes, you can always send the task back, explaining what needs to be done. Don't make all the changes on your own; the hints below can be shared with the reviewer as team notes, instructing them how to fix these issues. Hint: before sending the subtitles back, it's a good idea to make the necessary changes in the first few minutes, to show the reviewer what you mean. Of course, if the subtitles contain only a few mistakes, you can consider fixing them on your own.
Scan for reading speed issues
In the Amara editor, you can see the reading speed and character length of every subtitle. This tutorial explains how to use this information. Subtitles with reading speed issues have a small red exclamation mark. You can fix the reading speed by compressing/reducing text or by editing the timing. If compression doesn't work, you can extend the duration of a subtitle a little and make the following subtitle start a little later. You can also sometimes merge subtitles that together form a complete sentence or clause (put all the text into the first subtitle, delete the second subtitle and extend the duration of the first one over the gap). Don't merge subtitles if the resulting subtitle would include part of the next sentence.
Scan for line and subtitle length issues
Subtitles with line or subtitle length issues have a small red exclamation mark. In languages that use Latin script, every subtitle longer than 42 characters must be broken into two lines, and no subtitle can have a total length of over 84 characters. Even if a subtitle is broken into two lines, the break may be placed in a way that splits up a linguistic whole, e.g. after an article. Fixing line breaks involves inserting line breaks into unbroken subtitles with over 42 characters and relocating the line-break if one of the lines is over 42 characters or if the current line break splits up a linguistic whole. It may sometimes be necessary to rephrase the translation a little to make breaking a subtitle in keeping with the rules possible. For more tips on line-breaking, see this guide.
Scan for timing issues
Make sure to watch the talk with the subtitles on to see whether the synchronization of the subtitles is correct. Perfect synchronization of the subtitles with the original audio is not necessary if extending the duration of a subtitle is needed to maintain the correct reading speed. Note that some less experienced users may inadvertently introduce incorrect timing when trying to adapt the duration of subtitles (e.g. ending up with subtitles of less than 1 second in duration). Timing issues are much more common in transcripts, the two most common being subtitles staying on the screen too long after the speaker paused speaking or subtitles displaying before the speaker says the equivalent bit of the talk.
Scan for translation accuracy, grammar, spelling and punctuation
Do a sweep for mistakes in meaning, grammar, punctuation and spelling. Some common types of mistakes are:
- Punctuation copied from the original
- No punctuation at the end of the subtitle
- Idioms translated literally or uncommon (e.g. archaic) idioms used to translate idioms where a non-idiomatic phrase would sound more natural
- Translations of terms created by the volunteers instead of being based on established translations in your language
- Weird word order or phrasing due to the translation being too close to the original (too literal or based on uncorrected machine translation)
- Special (non-English) characters in your language not used
- Incorrect naming of numbers (short scale vs long scale); units of mass and length not converted
- Proper names translated even though the speaker doesn't talk about their meaning and there is no common equivalent in your language (which makes it impossible to Google for more information on what the proper name refers to, since the viewer would be searching for the translator's novel translation)
- In transcripts: important on-screen text not transcribed even though there's room (wouldn't overlap with other subtitles, with good reading speed); subtitles embedded in videos played on the stage not included in the transcript (they have to be in order to make it possible to translate them into other languages)
- Subtitles stay on the screen for less than 1 second or over 7 seconds; sound representation (like (Applause) displays for over 3 seconds
Check the title and description
Make sure that the title and description were actually translated and that the speaker's name isn't missing. When approving TEDxTalks, make sure the title structure is correct, the single-sentence short TEDx disclaimer is translated, the general text explaining the TEDx program is removed, and that the description contains a brief description of the talk (learn more here). In TED-Ed videos, make sure that the information about the author of the lesson and the animation has been translated and that the link to the full lesson has not been removed.
How to select tasks for approval
Selecting tasks for approval may be tricky, especially if there is a long back-log of talks waiting. Here are some tips on the selection process.
Mix old tasks and new tasks
If there is a long queue of approval tasks waiting, try to mix working on some of the oldest tasks and some of the ones done recently. If you only focus on the tasks waiting the longest, new volunteers won’t get the feedback necessary not to make some mistakes in their future work. At the same time, if you only focus on the newest tasks, volunteers who have been waiting for their work to see the light of day may lose the motivation necessary to keep working on new tasks, and they may be less likely to go back and implement your suggestions if a long time has passed since they last worked on the given task.
Help people learn from your comments
Before you start, always look at the revision history and find out whose work you are approving. If you have sent back one reviewer's work several times before, and you saw them gradually improve based on your comments and actually implement your feedback, you may want to spend less time on making corrections on your own and instead send the work back with instructions. This may seem counter-intuitive, but more advanced reviewers will often enjoy improving their work armed with the knowledge gained from LCs' feedback – they can fix stuff that they simply didn't originally know was an issue. This approach can also give you more time to focus on guiding beginners by correcting more of their work.
If you can tell somebody is a beginner (e.g. it was their first review), consider making more changes than usual before sending the task back, or even fixing the mistakes on your own to provide a good model, while adding comments explaining what you did and why, and how to avoid similar mistakes in the future. The first-timer may be confused about your comments and not know how to make the necessary changes, so your model examples will help with that. Make sure to instruct the reviewer how to compare your revision with their final work.
What to put in your team notes
Team notes on an approval are an invaluable resource for the volunteers. Below, we have some suggestions on how to structure your feedback.
You will find yourself commenting on the same thing over and over (e.g. "Please use the correct title and description standard for TEDxTalks"). It may make your work easier if you and the other LCs who work in your language share a Google Doc with templates for the most common comments. You can then copy the appropriate comment and only adapt it a little to fit the current task (e.g. by giving examples taken from the subtitles you are working on).
Give examples of mistakes
While general feedback like "don't use English punctuation rules" may be helpful, it is better to provide at least one example from the subtitles you are working on to show the other volunteers what exactly you have in mind. In addition to quoting the example, add the corrected version (e.g. "This a, subtitle" --> "This, a subtitle").
Don't get personal
Remember that you are commenting on the work, not the contributors. Try to be objective in your comments and even if somebody has left a lot of mistakes in the subtitles, don't get your frustration out on the other volunteers. Keep in mind that the Open Translation Project promotes an atmosphere of peer learning and tolerance and a lot of volunteers will simply require some time to learn. If there are serious problems with somebody's work which don't seem to be helped by your feedback, discuss teaching strategies with the other LCs.
Find something positive
Very often, you may find yourself commenting only on the issues and mistakes. But remember to also point out what worked in the subtitles. Even if you needed to fix the reading speed in every subtitle, perhaps the translator was great at expressing humor or did careful research on terminology? Or perhaps the translation was full of spelling mistakes, but totally accurate in terms of meaning? The volunteers need to know about things they should keep doing, and your positive feedback will show them the way to go.
Refer to objective standards
To help the volunteers develop an attitude where they feel empowered to research the proper rules and solutions on their own, don't just base your feedback on your authority, but add a link to an outside, reputable resource that both you and the volunteers can refer to in judging what is correct. For example, when you are telling someone a phrase that they used is ungrammatical, find a link to a resource by a language authority in your culture that explains why the given phrase is incorrect (e.g. a well-known style guide). This way, the volunteers will feel that the level of skill necessary to be good at translating and reviewing is fully accessible to them provided that they base their decisions on more careful research.
We have a variety of general resources on how to prepare subtitles that you can share with the OTP volunteers to help them improve their work. When making a comment about an aspect of the subtitles that you have corrected (e.g. frequent reading speed problems or incorrect formatting of the title and description), make sure to link to the appropriate subsection of the whole guide. To obtain the direct link to a subsection, click its title in the table of contents at the top of the OTPedia article and copy the full URL from your browser's address bar.
Here are the links to some of the guides on OTPedia:
- How to tackle a translation
- How to tackle a transcript
- How to tackle a review
- How to break lines
- English Style Guide
- Video Tutorials
Some languages have their own translated guides. Based on the English-language resources, you can write your own guides in your language, and share them on OTPedia and in your language group.