Localization Project Management Office

Localization Project Management Office is a Trello board (referred to “board” hereafter) that contains the workflow of a localization project (referred to “project” hereafter) and templates that can be used in future projects. This board is built by me and my group members in the Localization Project Management class.

Board Overview

In the board, we use lists to represent each stage in the project cycle. Typically, a project contains 11 stages, but our group decided to add one more at the very end. The 12 stages are:

  • Submission
  • Project Specifications
  • Quote
  • Preparation
  • Translation
  • Editing
  • Proofreading
  • Post Layout Review
  • Final Verification
  • Delivery
  • Post Production
  • Client Feedback

Stage

Submission

This is the very first stage of the whole project cycle. Everything related to the project should be set up correctly so that the project can get off to a flying start. For example, a Client Page form will be filled out to document any important information regarding the client. The files submitted from the client will be properly placed in our network. At the end of the stage, a checklist will be run to make sure nothing is left out in this stage.

Project Specifications

In this stage, a Specification form will be used to establish the scope of the project. All of the requirements, agreements, resources provided, and clarifications should be included in this form. It will be a go-to document if something comes up later in the project cycle. We also have a checklist in place for project managers to quickly gauge the outcomes of this stage.

Quote

After the establishment of the scope of the project, a thorough analysis on the files from the client will be conducted. Combined with their experience, project managers can show the client how much time and money the project will cost. The quote checklist will be used to revisit every step in this stage.

Preparation

In this stage, as project managers, we need to prepare as much as we can to facilitate the processes down the road. The work includes: finding competent translators, preparing project specific translation kits, writing detailed work instructions to make sure everyone knows what the client’s expectations are and so forth. In light of the amount of work in this stage, having a checklist at the end of the process is extremely important.

Translation, Editing, and Proofreading

These three stages are the most related to the quality of the product. During these periods, translators, editors, and proofreaders are working with bi-text files. Each person will review the work from the previous one and give feedback. The files will not be passed down until the person finds no mistakes. While translators and editors are people who can read the target language, that is not necessarily a requirement for proofreaders since not understanding the target language can allow proofreaders to find mistakes that translators and editors cannot. The checklists in these three stages are divided into “before,” “during,” and “after” to encompass every task that should be finished before the project moves onto the next stage.

Post Layout Review & Final Verification

As opposed to the previous stages, people in these two stages work with files in the target language only. This allows them to see the products through target customers’ eyes . Usually, the person carrying out Post Layout Review understands the target language in order to mimic the real situation of a customer getting the product. Finally, a project manager, who may or may not understand the target language, will conduct a final check before delivery.

Delivery, Post Production, and Client Feedback

In the final stages, deliverables are delivered to the client. Any lessons learned during the processes will be documented for future improvement. We will also follow up with clients to ask for feedback so that the future cooperation will be smooth.

What I Learned and Gained

  • Not only were we developing the overall workflow of the project, we were also doing a mock project at the same time. At the end of the semester, I had a clear picture of the whole project life cycle and the roles of different stakeholders.
  • Documenting everything along the way is really helpful for future projects. For example, when we had to create a quote for our imaginary client, we didn’t have any experience to rely on. However, when going through the whole project, we tracked our time with TopTracker and got the time we spent on every task. That statistics can help us the next time we create a quote.
  • We produced a lot of templates checklists while completing our mock project. Although they are far from perfect, I will have something to start with when I start working.

This course is really valuable. It’s like I just spent a whole semester doing an internship.

Web Game Internationalization & Localization

We learned HTML, JavaScript, and one JavaScript internationalization framework in class. As our final group project, we chose a web game from Github to internationalize and localize. Our goal was to test if we could apply what we had learned to a new project and at the same time learn something new on our own.

Project Description

This game is called Guess the Money. It was originally designed for gamers in the U.S. Therefore, money amounts and dates were originally presented in the U.S. format. Our group would internationalize the game first so that it would be ready to change for gamers outside the U.S. Then, we would localize the game into simplified Chinese and Italian. All of this was carried out by using two JavaScript internationalization frameworks.

This is what our game originally looked like.

There are three elements that need to be internationalized and localized: text (strings), dates, and numbers for the amount of money.

Processes

String Internationalization & Localization

There are many user-facing strings (text) in the web game. If we localized the game without doing internationalization first, a translator would have to go through the code and translate each string. This is time-consuming, and translators typically don’t know how to navigate through code to find strings. In order to make translation process easier, separate files containing only source-target string pairs should be created for translators so that they can focus on translating. Here is where the 24 Ways framework comes in.

This is what the function looks like.

This is some of our source (English) strings.

The way it works is that we wrapped all of the source strings with this function.

When the game is run and the user changes the language, this function will go to the correct target language file to retrieve the corresponding target strings.

By doing that, every time this game needs to be translated into a new language. Translators will only get a file containing the source language, and they can start translating the strings right in the file and send it back when they are done. There is no need to look at code.

Date Internationalization & Localization

Not all countries in the world display dates in the same way, so this game needs to display them differently for gamers from different countries. In this project, the ECMAScript Internationalization API framework is used. Instead of displaying the date directly, another function is used to format the date first.

As shown in the screenshot, the date is stored into a variable called a, and the .toLocaleDateString method is called on a  to  format the date correctly. Another variable code is used here to determine in which country’s format we want to display. Then, the correct date will be stored in a variable called b.

Number Internationalization & Localization

Like dates, the way of displaying numbers change from country to country, so does the symbol for money. Therefore, simply putting numbers in the code is not an option. As with the dates, numbers need to be passed into a function for formatting.

As shown above, the number we want to format and variable code are passed into the function for determining the format. Another variable cur is also used to determine the symbol of the currency. All three variables together tell the function the correct way to display the amount of money.

Dynamically Changing the Content

After preparing the three elements for the change of language, it’s time to put everything together. With the two source-target language files (English to Italian and English to simplified Chinese) ready, the last step is to add code to distinguish which language has been selected.

As shown in the screenshot, the chosen language will be stored in a variable called currentLanguage. Next, if statements will be used to decide what the variables code and cur should be set to. For example, in the case of currentLanguage equal to “en-us,” code and cur will be set to “en-us” and “USD.” Throughout the game, all elements will be displayed according to the U.S. conventions.

The following is screenshots of the game in English, simplified Chinese, and Italian respectively. All of the elements can be changed dynamically.

After this project, I:

  1. Am more familiar with how 24 Ways works.
  2. Learned a new JavaScript localization framework.
  3. Reinforced the knowledge of how to link the language switcher with other elements in JavaScript so that they can be changed in real time.
  4. Learned the importance of internationalization. We localized our game into two different languages: simplified Chinese and Italian. If we had not internationalized the original version first, it would have taken us much more time to localize the game.
  5. Clearly understand the difference between = and ==. The former one is used when we are assigning values. The latter means equal to, which is used for determining if two values are the same or not.

Here is the Guess the Money web game files. Feel free to play around!

Application of SDL Trados to Translation Projects

Project Introduction

In class, we learned numerous CAT tools and the importance of having the correct file formats from the client in order to avoid difficulties later in the translation process. In this mock translation project, we applied what we had learned and used SDL Trados, the most commonly used CAT tools in the industry, to complete a mock translation project from English to  simplified Chinese and Arabic. Here is the final project deliverables, which includes:

  • Statement of Work
  • 6 source files
  • 7 pseudo-translated files: 1 Arabic and 6 simplified Chinese
  • 7 translated files: 1 Arabic and 6 simplified Chinese
  • 2 translation memories (TMs): 1 Arabic and 1 simplified Chinese
  • 2 termbases (TBs): 1 Arabic and 1 simplified Chinese
  • A video detailing our processes and lessons learned

Team members

Simplified Chinese Translators:

  • Lea Dong
  • Byron Chang
  • Summer Zhao
  • Serafina Zhuo

Arabic Translator:

  • Sherine Emara

After this project, I learned:

  • The importance of separating images from text that needs to be translated
  • The importance of pseudo-translating before projects start
  • How to educate clients on the importance of editable files
  • How to merge translation memories on Trados
  • How to maintain translation memories
  • The importance of team work

Post-mortem

It seemed reasonable that the four simplified Chinese translators worked separately to produce translations and sent all the translation memories and termbases to one person for merging afterwards. However, we had to manually merge everything. If we had used the package function on Trados to divide the work, all the merging process would have been done automatically when the returning packages were sent back to the person who created them. Next time when dealing with multiple jobs from one client, we will divide the them using package function.