Course Overview

As a former intern of localization project managers (LPMs) and a freelance translator myself, prior to this course, I have already accumulated some insights into localization (L10N) process through observation. Therefore, when I was introduced to the standardized process and best practices systematically in this course, I had plenty of experiences to draw from. I found myself constantly comparing the localization practices I’ve observed or adopted with what I was learning in the course: from quote creating, quote issuing, pre-translation preparation, translation, reviewing, post-translation layout to linguistic testing. Thanks to our beloved professor Alaina Brandt, I have successfully gained a comprehensive understanding of a good L10N process through a project simulation.

Team Project: Beat Saber Press Kit Web Page Localization

In simulation, our team undertook a web page localization project from Hyperbolic Magnetism, an indie game studio based in the Czech Republic. We localized the press release page of Beat Saber, a very cool VR rhythm game, into six languages, including Russian, Simplified Chinese, Traditional Chinese, Mexican Spanish, German, and Japanese. We decided on this client because many of the actual clients who need L10N services are software or gaming companies and we wanted to go through the actual process to see what potential problems may be.

In this project, we first built an LPM office and then adopted a standard workflow, including three main phases: pre-production, production, and post-production.

We set up our office by…
  • Creating team Trello board and adding lists and cards to define what we need to do for the 3 mentioned phases
  • Creating a team Dokuwiki page which contains subpages of our team, client, and project
  • Creating a OneDrive folder structure template
  • Setting up job codes and tracking time spent for different stages with TopTracker
As for pre-production phases, the actions include…
  • Drafting specification templates and pinning down our project specification
  • Creating a project style guide for different languages
  • Stipulating talent screening requirements and procedures and recruiting translators
  • Creating quote template and quote our clients according to market rates
  • Creating WO and PO templates and draft the actual ones for our translators
  • Wiping off files properties
  • Creating translation and projects, TM, and TB in Memsource
  • Preparing a translation kit with translation project, TM, TB, WO, PO, and Style Guide in it
In preproduction phase, the actions involved are…
  • Translating: We translated project file on Memsource. Due to time constraints and the fact that we didn’t have professional linguists to translate for us, we machine translated it.
  • Editing: We ran QA check and spell check on Memsource and check translation quality in terms of terminology, accuracy, and fluency in bi-text format
  • Proofreading: We exported the files, ran checks again, did a final examination on formatting and locale specific details (numbering, currency, time format, etc)
  • Final Verification: We verified our deliverables once again, paying attention to both content (e.g. the number of paragraphs, brand tiles, etc) and structure (e.g. file type, file name, etc)
Finally, we entered post-production phase. The actions include…
  • Handing off deliverables to our client Updating TM, TB, and Style Guide
  • Invoicing our client and translators
  • Sending a follow-up email
  • Managing customer feedback and making changes if applicable
  • Conducting a post-mortem team meeting
  • Archiving the project

Lessons Learned

  1. Money matters.

As a novice LPM team, we sort of messed up when quoting client because we weren’t familiar with industry customs. For our translation fee, we charged our client with the exact translator rates, meaning that we didn’t profit from translation services. Therefore, we could only earn from the project management fee in this project.

Nevertheless, we still did a good job by setting a high rate for services we didn’t want clients to ask for. For example, we charged a pretty steep rate for alignment because we wanted to discourage our client from requesting.

In our final budget tracking, we found ourselves running slightly over budget. We were less than 2 hours over billable time, which made us the best performing team in the course. However, the fact is we were still over budget. According to Alaina’s suggestion, in this scenario, there were three solutions:

  • Shaving off the costs in the following stages. For instance, LPMs can cut down further billable hours like buffer time or lower the cost for editing.
  • In the worst-case scenario, LPMs will have to l tell clients the truth and wait for their approval before proceeding with further work. LPMs may also need to create a new quote for client review.
  • Or LPM’s organization can simply absorb the cost.

Based on my own judgement, I believe this 2-hour extra cost can be made up by saving up in future stage, as long as we identify this problem earlier in the stage. Therefore, it’s important that we LPMs keep track of budget constantly in every single stage.

  1. Start organizing from the very beginning.

Prior to the course, our team members and I didn’t really have a habit of tracking time during work. Since it was our very first time using Toptracker to record the time spent, we paid more attention to reminding one another to turn it on than setting a naming convention for our jobs. Therefore, we used ADM for almost every task, and we didn’t specify and name tasks consistently. So it goes without saying, when we tried to calculate how much time we spent on different stages or types of task, it took us an excruciatingly long period of time to manually rename the tasks and clean the data up. Therefore, I’ve learned the importance of reaching an agreement on the naming standard for our task. The standard should be set up as early as in the LPM office building phase.

  1. As an LPM, you can never be too careful.

I learned this lesson the hard away after we redid our production phase all over again. Memsource wrongly segmented our source file, and we didn’t notice it until we entered the QA stage because we machine translated it without paying much attention. (Also some of us don’t speak the language we were working on.) Since we wanted a usable TM, we had no choice but to fix this problem. We tried several times reuploading the file on a certain day, but it didn’t work. However, when we tried it again later on another day, it magically worked, so we assumed Memsource experienced some bug on the previous day. I believe after this experience, everyone on our team will always check segmentation in CAT tools before sending files to translators.