A translate@thon is a mass translation event (also called a localization sprint). Get a number of translators in one room and begin translating and you have a translate@thon. The general idea is that translation is simply a numbers game, get a large number of people translating and the task will be completed more quickly.
To get the most our of your Translate@thon it is important that you understand what kind of outcomes you can expect and align your expectations accordingly. You will get different outcomes from small and large events.
So what can you expect?
Use a small event to get work done. Get high quality translations. Use a large event to expose people to localisation, to get media coverage and to promote Free Software. Large events are the places were you fish out the one or two dedicated translators who will carry on. At one large event we met with lecturers on a translation studies degree, localisation is now being worked into their degree.
Without a dedicated session or two devoted to review and quality assurance, expect there to be many problems with quality. Build in review sessions as part of your planning if you want to improve the quality and train people on the detail needed for high quality translation. Below more issues about quality is discussed.
It might be good to involve a hosting partner. Traditionally we have chosen the language departments of Universities. They have access to good skills, computer labs and their own network of people.
You can take various strategies. Either throw the door wide open in which case you probably need to publicise the event slightly differently so that you can attract various people. Or make it a relatively closed affair with your hosting partner. For your first one it might be nice to make it closed as you can then ensure a quality audience. Remember that you have the chance to attract people who might not know anything about Free Software and who have their own networks that could tap into other potential translators. A mass event has issues about quality which we address below.
Your choice of venue should consider the following:
Remember to put lots of signage up on the day so that people can actually find the venue.
Work with you partner to arrange the venue, people, etc. Make sure you have actually seen the computer lab and tested how things will work. If needed make contact with the lab assistant, manager, whatever and get their buy-in. They’ll be a wonderful ally if things go wrong and you have brought them on-board.
It is also nice to arrange refreshment, prizes and talks. So plan for those and get sponsors if needed. And perhaps give a slot for people to talk on various aspect of Free Software and translation. Talks and refreshments give a nice break for people to network and get excited.
Ensure that you have a team of helpers that can assist newbies during translation, the number depends on the number of people expected. The ideal people are more computer focused then language focused. You need people who can quickly tell if something is a brand name, explain a computer term, describe what something does or how a term is used in computers. Having language specialists on hand is useful as they can direct the language aspect of the same word choice problems.
Choose a date so that the majority of people are available. Avoid the obvious like school holidays. Public holidays may actually be a good time to host the event unless they are family-oriented holidays or long weekends. If you want to attract students at University make it fall into their program, avoid exam times, holidays, etc.
Ultimately the choice should align with broader goals for the language team. If this is the initial translation then you might want to translate a glossary, especially if you have access to language experts.
Another thing to consider is that if people have something to show for it afterwards then it is more rewarding. So translating the Mozilla web-browser and actually completing it so that people could take it home or download it shortly after the event.
Remind people of the event and check the computers. Nothing is worse than no one coming or the computers not working. Check that you actually have access to the lab and its not closed for some obscure reason.
Arrange for yourself and helpers to arrive early. Check that the catering is OK. Recheck the computers. Welcome people.
Take it as it goes and adjust your program if it isn’t working.
This is the suggested program that we use.
|09:00||Arrive tea, Register (hand out program, translation guidelines)|
|09:30||Start – intro talk (very basics of translation)|
|10:00||Translate short session|
|10:15||More talk covering more advanced topics|
|15:30||Translate (hand out evaluation forms)|
|16:45||Continue Translating if you want|
This gives you 4 hours of translation time with none more than an hour long. Adjust as needed. If you have a mixture of new and experienced translators then it might be nice to arrange the venue so that experienced translators don’t have to listen to any of the talks.
Give people a copy of the program and include the titles of the talks.
Don’t forget to thank people. It is also good to get participants to fill out an evaluation form (example) as this allows people to give feedback. You can also use it to recruite people to the mailing lists and to help organise your next event.
Keep the energy going. Some ideas for this are to establish a mailing list. Send out copies of what was translated. Give prizes to those who did the most, had the least errors, made the funniest mistake. Share stories about errors that were funny.
How do you ensure quality of the work? These are people who have just started software translation and thus their work will be suspect, take that for granted. There are a few things you can do to increase quality.