English to French IT Translator Blog

Does Knowing Another Language Give You a Richer Vocabulary in Your Mother Tongue?

Originally shared by Rebekka Wellmanns

As as freelance translator dealing with languages daily, I wonder if knowing another language makes you a language snob i.e. do you start to use ‘bigger’ words in your mother tongue when you are learning or know another language?

My immediate answer is yes, only because I learnt my source language at a young, impressionable age where I might not have had a wide vocabulary yet. We are exposed to a larger Latin vocabulary when we start to learn one of the modern romance languages (from my experience). For example, languages such as French and Spanish have a rich Latin base. English, in my opinion, has in a sense been “dumbed down”, in that we use everyday words rather than maybe a richer, more “formal” vocabulary.

For example, it is frequent to see Latin words in Spanish e.g. cadáver which is common in everyday use whereas in English the direct equivalent cadaver is seldom used in an informal context, where dead body is generally preferred. This might be down to ignorance of the word unless you’re a medical specialist.

In French the expression “I’m dead tired” is “Je suis mort de fatigue” (literally translated: ‘I’m dead of fatigue’). Fatigue being a word in English which is not very frequently used in an informal context. Although you wouldn’t use fatigue to translate this expression.

This may all be down to which technical vocabulary we use in certain contexts, however I do believe when we are learning another language we are exposed to more Latin based words (only looking at the languages I know) and through this we start using a richer vocabulary in English.

Conversely though, we could say that people, translators or not, learning English not so much enrich their mother tongue but are exposed to a wider range of synonyms in English. For example, hoard in Spanish is acumular roughly translated as accumulate. Some translators find it difficult to get out of the translationese rut and use the word accumulate, rather than hoard when referring to, for example, the Diogenes Syndrome. Take another example, the word feckless translated in Spanish is débil or incapaz and doesn’t quite portray the richness of meaning which feckless has i.e. lacking strength of character. English is a language full of synonyms. Other languages’ vocabulary often paraphrase words e.g. cot death in Spanish is muerte súbita del lactante (Lit. sudden infant death) and has no other equivalent.

Interestingly, the Inuit people have over 15 words to describe certain types of snow. So this whole discussion could be down to context and how we relate our immediate surroundings to the number of words we have for use in different contexts and the corresponding words.

I would like to know if you have had any experiences of your vocabulary being enriched from having learnt another language. In my case I was fascinated by the many Latinisms when I was learning Spanish which I could transfer to English and sound “smarter”. E.g. discussing the television series CSI with my friends I could say cadaver instead of dead body.

Game Localization and Internationalization Checklist

I’m taking the chance to share again the game localization and internationalization checklist we created at the IGDA LocSIG, a very useful resource based on our Best Practices. Ideally, you will want to read it and keep these points in mind during development, then use it as a final reference when you are producing localized versions of your games.

Game Localization and Internationalization Checklist

If you follow the general advice given here, the whole process should go smoothly. To take things further and make the most out of your localization initiatives, you can dig deeper and look for more specific resources. Most development environments offer some sort of internationalization and localization features nowadays – that is the case for for Unity3D (some interesting solutions are available on the Asset Store), XCode and Android Studio, just to name a few. No need to reinvent the wheel when great solutions already exist.

You could also save time and money by following the cost-saving tips that may apply to your project. In the end, being prepared and informed is what will save you from headaches and help you release your games in new markets at a reasonable cost.

[Guide] How to Become a Game Translator

This is the text version of the presentation I showed on Crowdcast with SmartCAT (video available here). It is based on the notes I took to prepare for the webinar, hence the disjointed writing style. Still hope you will find it useful to start your journey toward a career as a professional translator!

Working in the game localization industry is a dream for many gamers, but the path that leads to a career in this young world isn’t necessarily obvious. Here are a few pointers to help you get started and work in the right direction.

What Studies?

An educational background in translation/languages is not a necessity, but always a welcome addition to your CV. Two scenarios here:

Relevant university studies

As far as I know, there are no university studies fully dedicated to game localization yet, but a few specializations will help you in your quest for a job. Here are the three types of studies you should be aiming at:

Audiovisual translation: More and more universities offer courses in audiovisual translation, which generally include a part about video game localization. You can find a list of such universities here.

Translation (general): More broadly available, courses in translation will teach you the general theories of translation and help you prepare your career in the industry. Although not as focused as the above, it is still perfectly relevant and appreciated in the industry.

Languages and culture: Translation will have a smaller, but not insignificant role here. Such studies are also valued highly, especially if you study the language in a country where it is natively spoken. When I was working in-house, several of my Japanese to English translator colleagues had graduated from such schools in Japan and found a position soon after.

You’ve already graduated

A diploma is great, but you may be considering a career switch after working in a different industry. Don’t worry, there are still ways to fill the Education part of your CV.

Lessons/Courses/Books online and offline: first of all, you will want to learn about translation as a profession. There are plenty of courses and books available online and offline, some as specific as teaching you the basics of game localization, while other covers different aspects of the job, from finding clients to managing your taxes. Perform an online search, compare the options and see what works best for you

Go to seminars/workshops: look for relevant seminars and workshops in your area. A quick Google search will generally do wonders, but you can also check the websites of translator associations in your country. Most of them have a calendar listing such events

Consider taking a certification exam: once you’ve learned enough about the job and are confident in your skills as a translator, you may consider taking a certification exam. The most famous one is probably the ATA‘s, but again, feel free to look for options closer to you

Freelancing vs. Working In-House

Game localization projects can be handled in-house by developers, outsourced to localization agencies working with their in-house team and/or freelance translators, or handed directly to translators. Your first decision in your journey will be to decide the way you want to follow: in-house position or freelance work.

Here are the main characteristics of both:


More freedom: as a freelance translator, work whenever you want, wherever you want. No commuting, no fixed hours.

Possible better long-term income and security: once you’re established and projects keep flowing in, you will likely make more money than you would in-house. And you don’t risk losing your job all of a sudden. If one of your clients closes their doors, you still have other customers to keep you busy

Requires motivation/self-discipline: freedom is great, but you’ll still need to dedicate enough time to your job. You’ll have to keep track of projects, chase clients for payment, keep marketing yourself, etc. That’s also part of “being one’s boss” job description. I know some extremely talented translators who never managed to succeed as freelancers because they didn’t have that self-discipline

Getting established takes time: building a clientele takes time,  no matter how hard you try. Receiving enough work to live on translation will take you at the very least 6 months, while 2 years or more is not rare at all. Try to put some cash aside before taking the plunge, or keep a part-time job on the side to keep bills paid

Working in-house…

Stable income, no need to hunt new clients: busy or not, your income is the same and you don’t have the pressure of finding new clients

More focused work: you will be translating/editing most of the time (hopefully). No accounting, no marketing, no sales, just what you like and what you’re good at

Comparatively limited financial prospects: the higher the risk the greater the reward. A busy freelancer will typically make more money than an in-house translator. In general game translator salaries are rather in the low end in the gaming industry. There are, of course, fortunate exceptions to this


Qualifications alone won’t land you assignments. Before you start your job hunting efforts, you will want to make sure you are prepared for success.

Learn about the ins and outs of the job (read articles/ebooks, take courses, etc.): this is especially true if you are going to work as a freelancer. Learn about the business aspects of freelance translation (how to define your rates, how to get paid properly, how to communicate with your clients in different situations, etc.). You will find a lot of articles, ebooks and courses online for a large number of topics.

Build a solid CV/introduction highlighting relevant strengths: make sure you highlight every relevant educational or hands-on experience you’ve got with translation. Be specific: make it clear game localization is your main or one of your main specialization fields. Mentioning your favorite genres can be a plus when project managers will need to select the most suitable translator for their project.

Note about fan translations: in my opinion, that kind of experience is perfectly relevant and show your motivation, but you may not want to get too specific in public to avoid trouble. Mention word counts, game genres, etc. but only give names informally to parties interested in more details (small devs and game localization agencies will generally be curious and really just want to know what you’ve worked)

Gain experience with a few projects: the best way to be ready for prime time is to actually try your hand at a few projects. Put everything you know in practice and make your beginner’s mistakes. More on how to gain experience in a minute.

About translation tests

Many potential employers and clients will ask you to take a test. All have different criteria for evaluation, but I would classify them in two categories:

Ability tests: typical with localization agencies, a classical pass/fail test. Your basic translation ability will be checked: are your translations accurate, natural, free of typos/punctuation mistakes, do you follow instructions and terminologies? Most criteria here are objective, and a serious work should be enough, regardless of style considerations.

Shootouts: typical with end customers. They want to find the one translator whose tone matches theirs. You’ll of course need to meet the basic quality standards expected of a professional translator, but the rest is very subjective in nature. You may deliver a great translation and still see someone else get the job.
As a general advice, check their games, see what inspired them and try to find something similar in your native language to give you ideas about what they may be looking for.

Gaining Experience (Part I)

Offer free translation to indie devs

To gain experience, it can be a good idea to offer your help for free. Rather than helping big companies for peanuts, I suggest starting with indie developers who really need help and don’t have the finances to hire a professional translator.

Browse the Indie Game Localization group on Facebook. Devs regularly post help requests there.

Contact indie devs directly: you can use social networks to find interested devs. I particularly recommend Facebook and LinkedIn groups for indie devs (there are too many of them to list!) where people like to share information about their upcoming games

Offer to translate game mods, articles, fan sites, reviews, etc.: let your imagination do the work here, there’s so much to explore!

[!] Keep word counts reasonable: be willing to help, but don’t let people take advantage of you. Politely explain than you can only handle a few hundred words for free. An App Store description, menus? Why not. A whole set of dialogs? Probably too much.

Gaining Experience (Part II)

The LocJAM:

Online game translation contest, a chance to compare your skills to your peers. Winning entries are selected by reputable video game localization agencies, giving you a great chance to get noticed by professionals

Free and open: no need to join the contest, you can translate and share your work anytime (translation kits available here). That’s concrete work you can show your prospects

Local study groups: generally before/during LocJAMs. Great opportunity to learn & network with fellow translators

For more information about the LocJAM, you can read this related article.

Note: The contest is on a bit of a standby at the moment, the IGDA LocSIG is working hard to come back with a new formula

Gaining Experience (Part III)

Start in a different position in the game/localization industry: many game translators started in testing, marketing, project management, etc. Once you have a foot in the industry, it’s much easier move toward a translation position, for the same company or somewhere else

Consider internships: many localization agencies have some sort of internship program. It can be a good chance to gain experience and possibly impress your employer. Again, I know of people who started as interns and became full-time employees after that. I also know several freelance translators who still work with companies where they used to be interns

Finding Work In-House

Specialized game job sites: browse industry sites such as games-career.com, Gamasutra’s job section and similar portals in your native language

General job sites: big job sites such as Indeed, Monster or even LinkedIn have a lot of localization job listings. Make a smart use of filters and notifications, and check new postings regularly

Local job sites: don’t underestimate the smaller job portals. Many of them are free and appreciated by employers for this reason. You may find exclusive offers there, so look at sites specifically covering your area

Translation portals (Proz, TranslatorsCafé): while most projects posted on those websites are aimed at freelancers, offers for in-house positions, including in the video game industry, are occasionally published there. They’re also a great place to network with and learn from fellow professionals

Dev websites, social media accounts: regularly check the websites of developers/agencies in your area that have a job page. Follow such companies on social networks and look for job offers in your feed

Networking, online and offline: more on that a little later

Finding Work as a Freelancer

Register and check job postings on translation portals (Proz, TranslatorsCafé): register on those websites and build a solid profile to gain visibility and be able to bid on projects posted. A lot of agencies are recruiting new translators and offering projects through such platforms

Contact specialized agencies directly: there are lots of localization agencies specialized in video games, and many of them are constantly looking for new translators. Check their website, social accounts, etc. and see their preferred method contact.
Be careful to only contact reputable agencies with good payment practices. The Blue Board on Proz is a good way to distinguish good payers from the bad ones. To help you get started, I included a small list in the notes of the slideshow above.

Freelance offers on job sites: you can occasionally find freelance (sometimes labeled as “part-time”, “remote”, etc.) job offers on all types of sites mentioned in the previous section

Networking, online and offline

More on Networking…

I am a strong advocate for networking. It has plenty of benefits. You meet great people, build relationships, learn from each other and, yes, get access to jobs otherwise unavailable. Many experienced translators are happy to refer their clients to younger translations when they are busy, or to introduce them to colleagues in different language pairs.

Prepare business cards and an introduction: always carry business cards with you. Make sure the key information is there: your name, language pair and specialization, contact info, etc. Also prepare a quick introduction you can repeat when you meet new people. Clearly tell who you are and what you do. Then forget a bit about business and try to build a genuine relationship!

Go to game/translation conferences, seminars: conferences and seminars are great places to meet potential clients and colleagues. Don’t restrict yourself to just translation or game-related events, both are perfectly fine places to network. Don’t underestimate smaller, local gatherings. It’s easier to talk to people and have them remember you when the place is not awfully crowded

Join associations, attend meetings: here again, target both game and translation associations. They will always have more or less formal networking events, besides conferences mentioned above. For those that have a directory of service providers on their website, it’s also a good way to earn visibility

Also look for informal meetings around you: once you start networking with people and join their circles, you will realize that a lot also happens besides publicly advertised meetups. I can only speak for Japan here, but we have a lot of fun meetups, with a good mix of freelance translators, in-house project managers, developers, students, etc. Be curious!

Use translation portals social media to interact with colleagues and game developers: establish yourself as an expert in your field. Share interesting content, interact with developers and colleagues, answer questions people may have about localization. Consistency is key here. If you regularly show up in someone’s feed with strong content about localization, they may remember you the next time they are looking for translation services. Websites like ProZ also allow you to discuss various topics with translator colleagues. It’s a great way to learn about best practices and business principles

Start acting now!

Define your goals and strategy: decide if you will be a freelance translator or try to work in-house, do your homework and pick up a couple of strategies you feel comfortable with to get started. It always gets easier once you take that first step

Look for communities around you: look for associations and groups in your area, as well as online. Join a few and start networking

Join the IGDA LocSIG group on Facebook: because we’re a bunch of nice people who love games and languages. You will find plenty of useful information about translation case studies, interviews, tips for beginners and the latest news about the LocJAM.

And don’t forget to connect on LinkedIn!

Video Game Culturalization: Definition and Best Practices (IGDA LocSIG)

The Best Practices for Game Localization is a true gem of information kindly shared by the IGDA LocSIG. It contains everything one needs to know about game localization. The format in which it is shared might make it a little hard to find and digest, so I decided to split it in a format easier to share and process.

The document starts with a very interesting part on game culturalization: its definition, its different aspects and best practices recommended for game developers. Often overlooked, that step of the globalization process is critical to avoid cultural issues down the road – some other which can have disastrous effects (an example of a game discontinued for that reason is given in the document).

That specific section was written by Kate Edwards, executive director of the IGDA and expert on the topic. She first worked for Microsoft, creating the Geopolitical Strategy, which evaluates and manages geopolitical and cultural content in software products. After her stint at the IT giant, she started her own consulting firm, Englobe, engaged in content culturalization and strategy, primarily for the video game industry.

Here, she shares her knowledge in a well-written, simple yet exhaustive text, with her main points clearly organized and summarized.

What is game “culturalization”?

Culturalization takes a step beyond localization, making a more fundamental examination of a game’s assumptions and choices, and then assesses the viability of those creative choices in both the global, multicultural marketplace as well as in specific locales. While localization assists gamers with simply comprehending the game’s content through translation, culturalization allows gamers to engage with the game’s content at a potentially more meaningful level. Or conversely, culturalization ensures that gamers will not be disengaged by a piece of content that is considered incongruent or even offensive in the game’s environment.

Cultural mistakes often prove to be costly for game developers and publishers – not just the loss of potential revenue but the greater effects of negative public relations, damage to corporate image, and strained relations with the local government. In the worst-case, a local government may not only ban the game but take more direct action against the company, including detainment of local personnel for questioning and even incarceration.

Levels of game culturalization

The need for game localization is a well-known necessity within the game industry; however the need for culturalization remains relatively unrealized. Culturalization isn’t just a specific task; it’s also a broader intent for all international adaptation of content. In its most basic form, content culturalization can be viewed as the following three phases:

  1. Reactive culturalization: Make the content viable; i.e., avoid disruptive issues to allow a game to remain in the target market.
  2. Localization & Internationalization: Make the content legible; i.e., perform “typical” localization to allow the game to be understood.
  3. Proactive culturalization: Make the content meaningful; i.e., adapt and provide locale-specific options to allow the game to be locally relevant.

In regards to these phases of culturalization, some clarification may be helpful:

Localization is critical but the process of achieving legibility through translation is not the only step required in preparing content for other cultures. This is true for video games as much as it’s true for every other type of content.

It may be argued that a game title should be “legible” before it is “viable.” But a government will restrict a game based on sensitive content regardless if it’s localized or not.

These phases are not a hierarchy. As with localization, culturalization takes place in various stages within the typical game development cycle and is a coordination of various tasks and priorities being orchestrated across the entire development process.

Top Four Cultural Variables

The effort of thinking outside our given cultural worldview often makes it difficult for a game designer in one locale to be aware of the issues that could cause problems in another locale. However, by considering at least the following four cultural variables that most often generate conflict between the game’s context and local cultures, it is possible to reduce the potential for issues to arise:

  1. History: Past and Present

The issue of historical accuracy is one of the most sensitive issues for local markets. Many cultures are extremely protective of their historical legacy and origins, so any alternate or inaccurate history can yield strong, emotional backlash. History is a compelling topic, but it’s rarely possible to provide the full context of a historical event in a game. But it’s not only distant history that can be problematic but recent history can be a very sensitive topic as the memory of the events and outcome are very fresh in people’s minds.

  1. Religion and Belief Systems

Game content creators need to be sensitive to the underlying mechanics of the cultures into which their game titles are to be released. In general, a society based on sacred rules tends to be less flexible and yielding to the context in which information appears because they are following what they consider to be a higher standard than human judgment; i.e., if the problematic content appears at all, regardless of context, then there is potential for backlash.

  1. Ethnicity and Cultural Friction

Besides the more volatile issues of history and religion, there are many of issues that fit under a broad category that addresses various forms of disagreement, misperception, attitude and ongoing friction between cultural groups. Chief among those is the use of ethnic and/or cultural stereotypes and the perception of inclusion and exclusion with a negative bias towards a specific group.

  1. Geopolitical Imaginations

National governments often reinforce their local worldview and the extent of their geographic sovereignty through digital media, including online maps and video games. This involves a situation where the government claims certain territories and they expect those territories to be shown as integrated with their nation, whether it’s on a functional map or in the world of a video game (hence the term “geopolitical imagination,” as the depiction they’re demanding doesn’t reflect reality). With some governments, such as China and India, there is no room for error on this issue as they maintain laws that dictate how national maps must appear or how their local political situation must be shown.

Culturalization Best Practices

The underlying principle of culturalization is that a minor investment of time and effort during the game development process will offset a major loss of time, money and public relations in resolving post-release issues. Fortunately, there are some key steps developers can take to be more proactive about their culturalization strategy.

Gain awareness

  1. Attain a basic awareness: A key step is to attain a fundamental awareness of the potential for cultural issues; content creators and managers need to understand that cultural issues can occur and in which key markets and which key types of content. For example, most people are aware that China, India, Korea, and the Middle East can be sensitive markets. Also, many people know that certain types of content can become a real flashpoint for backlash, such as maps, flags and historical information.
  2. Ask questions: The goal isn’t to establish subject-matter expert proficiency, but to ask appropriate questions during development. For example, the game Kakuto Chojin (2002) contained a brief audio track with a chanted portion of the Islamic Qur’an, resulting in widespread backlash that eventually caused the product to be discontinued (note: this happened after an official protest from the Saudi Arabian government. Despite the problem being known at the time of the release, the developer assumed the issue wouldn’t be noticed. There have later been attempts to release an amended version of the game).
    Screenshot of Kakuto ChojinThis issue could have been avoided if someone had asked the question: “From where did these lyrics originate and what do they mean?” If something doesn’t seem quite right – even if the exact reason isn’t known – raise the issue immediately.
  3. Create accountability: In order for culturalization to be successful, it must be treated as a standard component of the development cycle. This means that responsibility for the process should be assigned to a specific person/team, often times the content coordinators and/or editors. Also, a new bug type “cultural” or “geopolitical” or whatever appropriate should be created in the bug tracking system to ensure the issues are flagged and resolved.

Identify issues

As mentioned previously, culturalization is most effective the earlier it’s applied to game content, thus engaging in team discussions around meaning, intent and purpose of characters, plots, environments, objects and so on during the conceptual stages can often catch the majority of potential issues. Here are the fundamentals of identifying potential issues:

  1. Context proximity: Stated simply, contextual proximity is the concept that the closer a content element approaches the original context in person, place, time and/or form, the greater the potential for cultural sensitivity. Developers should be looking for content that mimics real world locations, buildings, people, events, religions, nationalities, ethnicities and so on, and then evaluating the degree to which the content resembles its real world inspiration.
  2. Leverage external resources:
    a. Text references: Many reference works can be useful for basic research, such as cultural studies, country-specific guides, symbol dictionaries, encyclopedias of religions and deities, etc.
    b. Online research: Wikipedia, official government websites, non-government organization (NGO)
    websites, religious organizations, etc.
    c. Local opinions: Accessing the knowledge of people from a specific locale and/or culture can be particularly useful. If you work in a large multinational company, make use of the internal diversity of the company and ask your fellow employees for opinions. Alternatively, you can solicit opinions online in various forums (e.g., Yahoo Answers). This ad hoc opinion gathering may contain subjective viewpoints, but a large enough sample can reveal a clear pattern.
    d. Subject-matter experts: If the above forms of research do not yield clarity, seek out people in different fields such as history, cross-cultural studies or geography.

Assess severity

Just because issues have been identified in the research, it doesn’t mean every potential issue needs to be fixed. After identifying potential cultural issues, the key in next stage is to be able to effectively determine the “must fix” issues.

  1. Triage the found issues: Separate the “overt offenses” – the obvious things that you know for certain will be a problem from the “reasonable risks” – the things that might raise some concerns but won’t likely prevent a game from staying in the intended locale.
  2. Document your choices: Every game publisher has a choice as to whether or not to change sensitive content. Most companies do but there are times when it may not make sense to make even a minor content change because the issue is borderline sensitive. In such cases, it’s critical to document the decision-making in a defensive explanation, in case it might be needed if a government or consumers raise the issue.

Implement with precision

Many game designers carry a preconceived notion that culturalization is about making massive changes and rethinking the entire game idea. This is a misperception, and one key reason why many don’t confront the geopolitical and cultural aspect at all, as they believe it’s going to be too disruptive. This highlights one of the most important principles of culturalization:

  1. Be surgical: Make the most minimal change to the least amount of content. Only change what really must be changed in order to ensure distribution to the game’s target market. In the majority of cases with cultural issues, the resolution is a small, precise fix of a specific symbol, or word, or character design; it’s usually not a major issue such as the entire game’s premise (although this can occur).


Create the game you want to create, but don’t forget the global, multicultural audience who will be participating in your vision, and hopefully enjoying it without any cultural disruption. Well-executed culturalization within a development cycle isn’t turnkey; it takes time to implement successfully. However, the benefits to a company’s content quality, government relations, and public image amongst local gamers will prove to be a valuable long-term investment.


IGDA LocSIG Elections 2017 – Running for a Second Term

I am happy and proud to announce I am running for a second term at the IGDA LocSIG. It took me a while to settle on a decision. Not because of lack of interest -quite the contrary actually-, but because I had the interests of the group in mind: was it worth running for a second term and possibly getting on the way of new candidates when I knew I would be contributing to the community with the same energy either way?

Ultimately, my reasoning was that although my degree of motivation isn’t dictated by my presence in the SIG, the reach of my actions pretty much is. There’s no point in organizing international events and creating useful content if nobody hears about them. With your support, let’s make sure more events (in quantity and in variety) for both young and experienced game translators can come to life and succeed. Let’s do more of what the LocJAM and related initiatives did for 5 editions: giving the community a chance to come together, learn, exchange and, most of all, have fun.

You can vote for up to 5 candidates at the following link: http://www.igda.org/surveys/default.asp?id=2017_LocSIG_Election

My candidate statement

One important thing I learned during the previous term is that small and concrete actions beat big but unrealistic ideas. We are a tiny team of busy volunteers, and the best way to move towards our greater goals is to proceed by small steps.

Since joining the SIG early last year, I managed to contribute in various ways: I’ve given our newsletter a fresh start, helped the community through different channels (workshops, webinars, presentations at conferences, various articles…), and been increasingly involved in organizing the LocJAM, probably our biggest source of growth at the moment. These may sound like small things taken separately, but put together, I believe they helped make a difference.

For the new term, my objective is to build on this foundation to help the SIG develop further. Concretely, besides a renewed push to promote good practices in localization, I plan to organize more events: a successor to the LocJAM (if not in name, at least in spirit) and a worldwide, non-competitive event where people gather offline and localize a game together within a short time frame. In my experience, such meetups are incredibly effective at getting the word out among translators and developers altogether.

No rhetoric here, as I’m already taking action: I have started building a small library of localizable games (written in English or Japanese) that could fit both concepts, and acquired the knowledge to manage the organization and coordination of such events.

The only thing I need to bring these concepts to life is a little spark, which I hope you will give me. Whatever the future holds, I will keep doing everything I can to support our amazing community.

Game Localization Link Roundup – April 2017

Besides controversy surrounding Persona 5’s localization, April has been a rather calm month in the game localization world.

June will see new elections organized for the IGDA LocSIG steering committee. It has been a great pleasure to help the SIG over the last year and half. Achievements include the resurrection of our newsletter – a repository for everything interesting happening in the industry -, 3 workshops/local study groups for the LocJAM, actual help organizing the event itself (finding/internationalizing a game, most notably), a couple of webinars, various articles and presentations…

Will I run again? I don’t know yet, but I am certainly planning to keep contributing to the community in various ways. More specifically, I am starting to build a small list of games that can easily be localized by anybody (= to gain experience and build a portfolio, to help young translators enter the industry) and thinking about new events that could encourage the global community to gather and celebrate what we do offline, regardless of background and experience.

But personal talks for now, here are the links for April!

Persona 5: How Atlus USA Localized an Instant Classic

Localize Everything – Finding Hardcore Fans Worldwide – Extra Credits

Pictures from LocJAM4 study groups – Our community in action!

“I am preparing a guide for indie game devs: How to save money on localization.” – Interesting thread on Reddit where a few devs kindly shared internationalization/localization good practices

The Legend of Heroes: Trails Series – Localization Blog #2

Preparing Your Video Game For Localization

Originally written by Jan Nedoma.

In our time, the world is getting smaller. Thanks to multinational corporations you’ll see the same goods in the shops in many countries all around the world, you’ll see the same TV show on TV in the US and in Iceland. Of course, this phenomena also applies to computer games. Game distributors would tell you games in local language usually sell much better, and the same could be said about indie games. But before the game can be “exported” to foreign markets, it needs to go through the process called “localization”. This article will discuss how to make your game localization-ready and what problems you’re likely to encounter.


By localization we typically mean translating the game to a different language, but generally speaking, it’s about adapting the game to cultural differences of a given country. You will find surprisingly few materials concerning this part of game development in the internet. This article is based on my personal experiences with game localizations and the procedures described here have been successfully used in real life. Nevertheless, neither me or anyone else knows everything, and I’m not claiming everything described here is the only and perfect way. Consider this article a set of suggestions, based on real-life experience. If you have any corrections and/or suggestions, you can contact me at [nedoma (at) dead-code (dot) org].

This article is written from the programmer’s point of view (on Windows platform), but most of the concepts are generally usable for localization.

To make your game easily localizable means making it localization-ready. Let’s get through several most important areas affecting the game localization readiness.

Localizing the in-game texts

The string table – creating and maintaining

The in-game texts are the most obvious localization target. There are several approaches, but ideally all the in-game texts should be summarized in a big text file (let’s call is a “string table”), which can be easily handed to translators to do the actual localization work. The game should be able to load all the texts from this file and use them. Which means, by simply replacing the string table file you’re able to switch languages on-the-fly at runtime (or at install time, whichever way you prefer). But how to achieve this ideal situation? Firstly, every single text needs to be augmented by a unique identifier. This will allow us to internally only reference the string IDs (which don’t change) and the actual text content can be switched without affecting the game code. Assigning the IDs to text strings is a quite complicated task, because it’s hard to manage large quantities of text and avoid duplicities, not to forget anything etc. Of course, it depends on the game type, hence on the amount of text. In case of simple action games which only contain a couple of strings such as “New game” and “You are dead” it’s easy to maintain a string table by hand, but a large RPG or adventure game will probably require some kind of utility which will do the dirty work for you.

The approach I’m using is to develop the game (relatively) ignoring the future translation, and only when the game is finalized enough (namely the texts are more or less final), I use some kind of tool to extract all the localizable texts from the game files and to export them to a string table. During this process every text is also assigned a unique ID, and the original text occurrences in game files are replaced by this ID.

This approach brings some pitfalls, though:

1) How to extract all the texts used in the entire game? I’ll give you a single advice: try to design the game data files structure so that it’s as easy as possible. The most important thing to remember is, forget about texts hard coded in the game executable. All the texts should be stored in data files, or in the game scripts. It’s better to use text-based data files, not binary ones. The popular XML format is a good candidate, because when choosing the right structure you’ll be able to extract all the localizable texts using some generic tool, which doesn’t even have to know the actual structure of your game files. For example, imagine an XML file describing units in a real-time strategy game:

 <?xml version="1.0"?>
<Name Localizable="true">Archer</Name>
<Description Localizable="true">Ineffective for close combat,
but deadly for ranged attacks.</Description>
<Name Localizable="true">Catapult</Name>
<Description Localizable="true">A slow but very powerful unit.</Description>

Notice that the “Name” and “Description” entities are marked with a “Localizable” attribute. That means we can make a generic tool which will load an XML document, scan all the entities (without looking for any specific names) and if they contain the “Localizable” attribute, their content will be exported to a string table. The advantage of the XML format is that there are many ready-to-use parsers available, so you don’t have to write your own. But of course, you can use a similar approach when dealing with your custom file formats.

If your game uses some kind of scripting language, you’ll probably want to extract all the string constants from the scripts. In my opinion, the best approach here is to modify the script compiler itself, because it knows exactly when it encountered a string constant when compiling the script, including the exact line and column in the source file. It shouldn’t be a big problem to extract the string constant and replace it with an identifier. Sometimes scripts contain string constants which are not supposed to be localized. For this purpose I’m using an ignore list and a library of “known code patterns” to filter out irrelevant strings.

2) The process described above will yield the following results. All the in-game texts will be stored in a string table and their original location will be replaced by some unique identifier. Even though it’s basically what we wanted to achieve, the problem is, that the original files will become a little unreadable after that. Imagine the following script:

Frank.Talk("Hi Joe, how are you?"); 
Joe.Talk("Yeah, I'm okay.");
Frank.Talk("I gotta go.");

After our intervention and after exporting the texts, the script will become something like this:


While it’s pretty obvious what the first script does, the second one is totally unreadable because of the absence of the texts, which can be a problem for any subsequent script changes. There’s an elegant solution I’ve seen in some LucasArts games. Just keep both the original text AND the identifier in the source file, using some unambiguous syntax. For example:

Frank.Talk("STRING0001|Hi Joe, how are you?");
Joe.Talk("STRING0002|Yeah, I'm okay.");
Frank.Talk("STRING0003|I gotta go.");

As you can see, the texts in the scripts are now stored like this: “identifier | original text”. This approach brings us two advantages. Firstly, the code is still readable, and secondly, there’s a chance to get back to the original text if needed. For example, if the game cannot find any string table, it will still run, but it will only display the texts on the right side of the “pipe” character. Additionally, it’s easy to re-export all the texts from the game files, because the extraction tool will know exactly which texts have already been exported, and which ones are newly added (the ones not using the “pipe” syntax yet).

We haven’t looked yet at how does the generated string table look like. The decision is up to you. I’m using a simple text format, where each line contains one string. There’s the identifier, a “tab” character separator and the actual localizable text. The translator can simply open the file in any text editor and replace the texts with their translated equivalents. The string table from our example would look like this:

STRING0001 Hi Joe, how are you? 
STRING0002 Yeah, I'm okay.
STRING0003 I gotta go.

And the German translator will send you back something like:

STRING0001 Hi Joe, wie geht's? 
STRING0002 Alles bestens.
STRING0003 Ich muss weg.

You can improve the string table format to suit your needs. For example, lines starting with semicolon can be treated as comments (the game will ignore them when loading the table) so that the translators/designers can add notes to the string table file, etc.

The string ID itself can be improved too. For example, you can use some standardized format to encode the character speaking and/or the location where it’s being used etc. These are things that make translators’ work a lot easier.

In case of large games the designer will probably need to add comments to the table, to describe the context of some of the texts, otherwise the translators might get lost and the translation quality will suffer.

Another useful feature is to allow string table entries to reference other entries in the table. Typically one text appears in the game in different situations. If you allow the inter-table references, the translator can only translate the text once and “redirect” all the other occurrences of the same text to the translated entry. I don’t recommend exporting multiple occurences of the same string as a single string table entry, because they might need different translations in other language (depending on the context). Leave it to the translator to decide which strings should be the same.

Using the string table in your program.

All right, now we know how to create the string table, but how are we going to use it? Our game engine needs to load the table into memory. Considering the data structure (an identifier with a text attached) we’ll probably want to use some sort of hash table. If you’re programming in C++, the STL map container is probably a good choice.

Loading the string table file should be a trivial matter. We’ll simply read the file line by line; if the line is empty or starts with a semicolon (i.e. it’s a comment), we’ll ignore the line. Otherwise we split it into two parts: the part left of the “tab” character (the identifier) and the part right of the “tab” (the actual text) and we’ll store the pair in a hash table. Again, there’s a lot of space for improvements, such as reporting duplicate entries, reporting lines without a “tab” character (the translator accidentally replaced it by a space) etc.

A special note about whether to keep all the texts in memory at once. It might look like memory wasting to you, but the truth is most “talkative” games only contain a couple of hundreds of kilobytes of text. Very few games contain more than one megabyte of text. Considering the average memory capacity of today’s PCs, I think you can safely store the entire string table in memory. But if you’re still not convinced, or if you’re targeting a platform with limited memory (PocketPC), the solution can be dividing the table into more parts, for example generic texts and then specific texts for each level of the game etc. Then you’ll load and unload parts of the string table as needed.

From the programmer’s point of view, it’s a good idea to encapsulate the string table into a class, which will keep all the texts and provide a method (preferably a static one), which will accept the original text and return a translated text. By “original text” I mean the text in the “identifier|original text” format. The method will do the following:

  • Check if the original text contains the identifier.
  • If not, the text is not supposed to be translated, so simply return the original text we received.
  • If yes, the method will split the original text to the identifier and the text part.
  • Using the identifier, it will try to find a translated text in the string table.
  • If the string table contains this identifier, a translated text is returned.
  • If not, the method returns the textual part of the string it received.

That way we achieved that even if there’s no translated version of the text, the game will still display SOMETHING (the original untranslated version). Certainly better than displaying an empty string or some error.

Once again, we can further improve the process. A debug version of the game can report texts with missing translations, or it can return the translated text including the string table ID, so that the ID is displayed on screen. That can be useful for beta testing the translation. If the testers encounter some text with wrong translation or some grammar mistake, they can write down the identifier of the text and report it back to the translator.

The only thing left is to find all the “end points” of the program, where the texts are being used, and change these to call the method of our string table class to replace the original text with a translated one. What do I mean by “end points”? Typically these are the parts of the code where the text is actually presented to the user. Whether it be displaying it on screen or writing it to some text file etc. There are usually relatively few such points in a game engine (if it’s well designed, that is).

Let’s see one (dumb) example of how to add localization support to our code. Let’s assume we have a piece of code, which displays a message box whenever it encounters some critical error. The original code would look like this:

 MessageBox(NULL, "A critical error has occured.", "Error", MB_ICONERROR);

To display the message in another language, we’ll modify the code like this:

 MessageBox(NULL, CStringTable::Translate("SYSSTR0001|A critical error has occurred."), CStringTable::Translate("SYSSTR0002|Error"), MB_ICONERROR); 

CStringTable is the class encapsulating our string table, Translate() is a static method, which gets the original text as a parameter and returns the translated text (described above).

The code got a bit more complicated, but not too much. Alternatively, you can use a macro to further shorten the code:

 #define LOC(String) (CStringTable::Translate(String))

And the resulting code would look like this:

 MessageBox(NULL, LOC("SYSSTR0001|A critical error has occurred."),

Similarly, you’ll need to modify all the pieces of your code where the texts are in some way presented to the user.

Storing the in-game texts

ASCII versus Unicode

Note: The following section is intentionally a little simplified. I’m just trying to describe the concepts and motivations, not to make any in-depth analysis of the history of character encoding 🙂 Also, for further simplicity I’m going to use the term “ASCII” for any 8 bit characters, even though, technically speaking, this term isn’t always completely accurate.

Another area of interest is the actual storage of the game texts in memory. Historically, most programs were using (and are still using) texts stored in the form of 8 bit characters, i.e. one character takes one byte of memory. That means one can use up to 256 different characters. The ASCII norm, where this character storage originates, was designed to store just the basic Latin alphabet (a to z, A to Z), the numbers and the symbols. Even 7 bits were enough to describe those (128 characters at most). As the software was getting more and more complex, it became necessary to store various other characters, specific to other languages (most European languages, other than English, are using some kind of accented characters). The remaining unused 128 characters were used for storing these national characters. The problem is, if you take all the national characters used by various languages, you’ll get far more than 128 of them. That’s why the concept of so called “code pages” was introduced. There were several groups of national languages defined, and it was possible to switch the code page. That means, the 128 non-English characters were getting different meaning depending on what code page was currently being used. For example, for European languages we’d define groups like: Western European, Central and Eastern European, Cyrillic, Greek etc. Similarly the code page concept supports languages such as Arabic, Hebrew and others.

To make things even more complicated, there are several standards for code pages, incompatible with each other. Some encoding was used in DOS, other in Windows, other is an ISO standard, there are some local standards…

What does that mean for game localization? If we are storing texts as 8 bit characters (i.e. the classical C “char” data type) we’re able to display at most 256 different characters. If we want to support multiple languages (we do!) we’ll have to deal with code pages. In reality, this means one thing: our game must use different fonts for different code pages. But we’ll talk about fonts in the next chapter.

I think it’s obvious that the concept of code pages is far from being ideal. In programmer’s jargon I’d call it a “hack”, or how to stuff infinite number of characters into 256 available cells as easily as possible. Also notice that I didn’t mention Asian languages yet…

The effort of solving the national characters problem once and for all resulted in a standard called Unicode. The goal of Unicode is to consolidate the fragmented code pages for various languages/regions and to define a standard set of all possible characters in all languages (or at least their vast majority 🙂

From the programmer’s point of view it’s important to notice, that – as opposed to ASCII – one byte is no longer enough for storing a single character. Currently Unicode defines over 90 thousands of different characters. There are several standards for storing Unicode characters, two most commonly used standards are UTF-8 and UTF-16. The “UTF” abbreviation stands for “Unicode Transformation Format”, the number is a number of bits used for storage. You may object that neither 8 or 16 bits are enough to describe 90,000 different characters. The point is, that a single Unicode character can be described by multiple bytes. The number of bytes is different for various characters. In case of UTF-8, one character can take up one to five bytes (and “common” characters, i.e. latin, only take one byte, therefore e.g. English text looks the same in UTF-8 as it looks in ASCII). UTF-16 uses 16 bits (word) to store characters, and even though in theory 16 bits are still not enough, practically one 16 bit word is equal to one Unicode character (unless you’re using some “obscure” language, such as ancient Japanese).

All right, that was a very brief introduction to Unicode, let’s get back to game localization.

If you want to avoid the code page problems or if you want to support Asian languages, your game engine should store texts in Unicode format. More and more modern games are using Unicode, simply because localization is now an important part of game development process, and Unicode makes localization easier.

Above I mentioned two ways of storing texts, UTF-8 and UTF-16. UTF-8 uses normal 8 bit chars, UTF-16 uses the wchar_t data type, which is typically 16 bit integer (note: this is true for Windows platform; Linux uses 32 bit wchar_t by default). One great advantage of UTF-8 is that if you already have a finished old program using 8 bit characters, you don’t need to change anything to store UTF-8 strings. That’s a great time saver. Also all the standard C-style string manipulation functions (strcpy, strlen etc.) will work on UTF-8 strings. But of course, you must remember that one UTF-8 byte isn’t necessarily equal to one character (as I said, one UTF-8 encoded Unicode character can take up multiple bytes). It means, for example, that the strlen function will return the number of bytes in the string, NOT number of characters! Also if you’re accessing individual bytes of the string using the [] operator, you’re getting bytes, not characters. But even with these disadvantages, UTF-8 is an (almost) ideal solution for those developers who need to add Unicode support to their legacy code quickly and easily.

Nevertheless, if you are starting to design a new system, I recommend using the wchar_t type for storing text strings. The ANSI C standard now contains all the string manipulation functions in two versions: the classical ones, working with “char” data type (strcpy, strlen…) and their equivalents for the “wchar_t” type (wcspy, wcslen…). Similarly, STL offers you both “string” and “wstring” types.

Of course, storing the texts is one thing, and displaying them on screen is another thing. But we’ll get to that later in the Fonts chapter.

Unicode on various platforms

Of course, the problem of national characters and localizations is not game-specific and needs to be handled on operating system and development platform levels. So let’s take a brief look at how some of the most popular platforms deal with Unicode.

Linux was historically built on ASCII characters, therefore Unicode support is commonly realized using the UTF-8 encoding on this platform, and it became de facto standard for string interchange.

The situation on the Windows platform is a bit more interesting. Windows systems have been for a long time developed in two parallel branches. On one side, it was the Win9x branch (Win95, Win98, WinMe) targeted at low-end hardware. These systems were using 8 bit ASCII strings. On the other hand, the WinNT branch (WinNT, Win2000, WinXP, Vista) are using 16 bit characters from the beginning. But to maintain backward compatibility with programs written for Win9x, the NT-based systems must be able to handle ASCII strings as well. In reality, all the Windows API functions working with strings are provided in two variations. The functions use the same name, but the ones working with 8 bit characters end with “A” (for ANSI) and the ones working with 16 bit characters end with “W” (for Wide). For example, we’ll find the MessageBox function as MessageBoxA and MessageBoxW. The “A” functions only work as a stub, which converts the string parameters from ASCII to Unicode and calls the “W” function. On Win9x systems this conversion is also partially supported, but the other way around and only for a couple of selected functions. Fortunately, Microsoft later released a separate library called “Microsoft Layer for Unicode”, which allows programs written for Win9x to use the entire set of Unicode variations of API functions.

Unlike Windows NT, the Windows CE (Windows Mobile) platform for mobile devices got rid of the compatibility and only supports 16 bit characters. If you are developing a game for WinCE, you can still use normal ASCII strings, but whenever you need to call some API function expecting a string, you’ll need to convert the string to UTF-16.

Modern runtime platforms Java and .NET are using 16 bit characters exclusively, even though they provide a large set of conversion routines from/to other text encodings.

In the end of this chapter I’d like to mention two useful Windows API functions for converting strings between 8 bit and 16 bit characters. MultiByteToWideChar converts from 8 bit characters to 16 bit and WideCharToMultiByte converts from 16 bit characters to 8 bit. The important thing is that both of these function can (among others) handle UTF-8 encoded Unicode strings.


In the previous chapters we were talking about how to separate in-game texts from the rest of the game and how to store them in memory. The result of all our efforts should be a localized text displayed on screen. Of course, we need fonts to actually render the text, but there are many possible approaches. Let’s take a closer look at some of them, especially taking localization into consideration.

The traditional approach to game text display is to load a special texture, which contains all the characters, and then render each character as a single quad, textured by the appropriate part of the texture with the image of a specific letter. This approach is understandable and easily implemented. The problem is, the font texture only contains a limited set of characters, typically 256 of them, i.e. a single code page (more on code pages in the previous chapter). To be able to display texts for various languages, our game will need to be able to use different fonts for different code pages (for example a texture with Russian font will contain completely different characters than a texture with Greek font). Now, it depends on how the font texture is made. There are generally two ways. Either the texture is manually created by an artist using utilities such as Bitmap Font Builder or FONText, or the texture is automatically generated by the engine at runtime. In the first case it will be necessary to manually create font textures for all the code pages our game is supposed to support. In the second case the game has to know which code page should be used when generating the font texture. For example, if we are using Win32 API for generating the font, we have to create the font using the CreateFont function, which accepts a code page identifier as its 9th parameter.

As you can see, we’re once again sinking into the limitations of code pages and ASCII strings. Besides, this approach has several more or less fatal limitations:

  • By painting the text ourselves, letter by letter, we’re bypassing the font rendering engine. No matter if we’re using Windows API, FreeType or some other font rendering library, these libraries are usually designed for rendering continuous blocks of text. This allows them to render the text with respect to certain typographic rules. For example, they’re using so called kerning, i.e. different space between various letter pairs (kerning pairs), which improves the look of the rendered text, especially for larger text sizes. If we are rendering the text ourselves, we’re missing these advantages (or we have to reimplement them).
  • By painting text letter by letter we’re losing advanced text formatting options. And here we’re getting back to localization. Some languages, namely Hebrew and Arabic, are writing text from right to left (right-to-left, RTL). While Windows API directly supports RTL texts, and we can enable the support by specifying one parameter of the ExtTextOut function, when painting the text ourselves we have to handle RTL ourselves as well. You might say implementing right-to-left text rendering shouldn’t be too hard, but it’s more complicated that that. Hebrew and Arabic texts can contain parts written in Latin (for example names) or numbers, and these parts need to be rendered left-to-right. It’s so called bidi text (bidi = bi-directional).
  • And there are the Asian languages. While in case of European languages we can use code pages, it’s not quite feasible to render all Chinese characters into a single texture. We have to look for other solutions.

The problems described can be solved using the following method. Instead of using the existing font rendering engines just for painting individual letters into a font texture, we can let them paint into the texture the entire text we’re about to display on screen. That way we can use all the advanced text formatting functions practically for free. Of course, this approach also has its deal of disadvantages. Depending on the amount of text the resulting texture can be quite large and it will take a lot of video memory. Also, it might be necessary to divide the texture into smaller parts, depending on the capabilities of the video card.

Compared to the static font texture, this approach is more time and resource demanding when generating the text texture. It’s not feasible to re-generate the text texture in each frame. Fortunately, each text caption typically stays on screen for some time, therefore it’s possible to implement some sort of texture cache, which will hold, e.g. 10 most recently rendered texts. The text texture will be generated in one frame, and reused in all subsequent frames.

In any case, it’s up to your consideration to decide which of the described ways will better suit your needs. I just tried to summarize the advantages and disadvantages than might not be obvious at first.

Other aspects of game localization

In the previous chapters we talked about game localization, especially about storing the game texts and their rendering using fonts. These are no doubt the most important areas, but localization also affects other parts of development. Let’s take a look at these in this final chapter.


There’s a single most important rule: try to avoid using any text directly in graphics whenever possible. All the texts should be rendered programmatically using fonts. Keep in mind that all the textures containing text will need to be repainted for all language versions of your game. If you are creative, you can sometimes avoid using texts altogether. For example, don’t use buttons with text labels, use icons instead. Or just display a textual tooltip when the mouse is hovered over the button.

User interface

By user interface I mean various windows for saving game, main menu, confirmation dialogs etc. Even when designing the user interface you should think about localization. Keep a lot of additional free space for all the text labels. Remember that the translated text can be much longer than the original. This is especially true if your original language is English. English is in general quite brief and other languages usually need much more space to describe the same thing. Also remember, that for Asian languages you’ll probably need to use bigger fonts, so make the text area slightly higher than necessary.

Funny fact: German is probably one of the most critical languages when it comes to text lengthening. In Oblivion the player is picking up healing potions, described as “Light potion of healing” in the inventory. German localizers translated the name as “Schwacher Trank der Lebensenergie-Wiederherstellung”, which wouldn’t fit in the reserved screen space, so they had to abbreviate the name to “Schw.Tr.d.Le.en.-W.”, which is… kind of hard to comprehend 🙂 It’s a nice example of badly designed user interface, resulting in poor localization.

Voiceovers and videos

If your game contains voiceovers, keep these sound files separate from the generic sound effects. How to organize and name the voiceover files depends on situation, but you can use the string identifier from the string table to name the sound file. For example, if your string table contains something like:

 STRING0001	Hi Joe, how are you?

The voiceover file for this line would be stored in a file called “string0001.mp3”. The game engine can then automatically find and play the voice over for the line being displayed on screen. Also, if your string table ID contains the character the line belongs to, you can easily filter lines for a specific voice actor etc. Well designed string table structure even allows you to generate entire scripts for each voice actor.

Always allow subtitles display for videos in case the localizers won’t be able to record localized voiceovers. You can use standard formats for video subtitles, such as .SUB or .SRT, because there are existing editing tools for them.

Keyboard input

If your game uses any kind of keyboard input, such as the player name or saved game description, don’t use DirectInput for this purpose, but the Windows API messages, like WM_CHAR. That way Windows does the dirty job of mapping various keyboard layouts to national characters, “dead keys” handling etc.

Cultural references

When designing the game try to avoid references and jokes specific for one language and/or nation. They are hard to translate and complicate the localization process. If you have to use these, try to provide the translators with a sufficient description, so that they can adapt it to their local cultural environment.

Try to avoid game situations that can be offending to some national or religious groups (remember the Muhammad cartoons controversy, for example).


This article concentrated on the often-omitted area of localization readiness of game engines. We went through several most important topics, revealed some of the possible pitfalls and tried to find solutions. If you are planning to implement localization support in your game, hopefully this article will help you to avoid some dead ends. Thanks for reading.

Should I Hire A Freelance Translator Or A Translation Agency?

Whenever you are looking for a translation service provider, the first thing you will need to do is to choose whether you will go for a freelance translator or a translation agency. When you do so, your decision should be based on few things:

  • Type of project (one-time project or long term project; bilingual or multilingual project)
  • Type of text (highly sensitive and confidential content; highly specialized content)
  • Services you need (language services only or other additional services)
  • Budget

Let’s analyze each of the situations.

  • Type of project

If you are going to need translation services repeatedly, it is better to search for a freelance translator you can trust. Here is why. If you hire a translation agency, you won’t know who is working on your texts. You may be happy with the translation first time, but there is a great chance that your next text will be translated by somebody else. Agencies change their Project Managers quite often and your texts may be translated by different translators each time. It is important to have the same person translating a long time project for few reasons:

a)      They get to know your style preferences, your company’s specific slang, your products/services and your company’s philosophy and will implement them in the translation.

b)      There will be a high level of terminological and stylistic consistency throughout all translations.

c)       Usually, translators build local glossaries and translation memories that help them review translations they’ve done previously. This is important when you have phrases/sentences that repeat in your texts (like chapter titles, for example) and ensures that these repeated phrases will be translated in the same way all the time.

On the other hand, if you have a small project and you are sure you won’t need any other translations in the future, you may opt for the services of a translation agency. They will find a good translator for your project and you won’t have to spend time searching. Usually they already have translators registered in their databases and you won’t need to invest any additional time to find one.

It is also a good idea to contact a translation agency when you have a multilingual project (when your texts have to be translated in more than one language). They already collaborate with many freelance translators for different language pairs. However, if you are going to need translation services for a long period of time, I strongly advise you to invest the time needed and find a good translator that understands your needs.

  • Type of text

If the information that has to be translated is highly sensitive (like texts addressed to victims that were sexually harassed), or highly confidential (like business contracts, legal cases), it is better to contact a freelancer to do the translation. Here are the reasons:

  • Your text will be handled by one person only;
  • You can sign a confidentiality agreement with the translator;
  • Generally, translators have already their own terms and conditions of collaboration and usually they treat confidentiality with the highest level of professionalism;
  • You will know all the time who exactly is working with your text and whether that person can be trusted or not.

If you handle the text to a translation agency, there are multiple levels of employees that will have access to your text: your contact person, the project manager, probably the accountant as well + the translator.

  • Services you need

If you need a wide range of services besides translation, it is better to contact a translation agency. Assuming you need your text to be translated and proofread; then you want that somebody arranges the text in a special format (DTP services) or that the text is SEO friendly and links to different pages on your website, etc., a translation agency will find the right professionals to do each part of the job. A freelance translator alone usually specializes in translation and/or proofreading only and won’t be able to provide you all the services you need.

  • Budget

Like any other activity, there is a clear relation between the quality of a translation and the rate charged. Translators are usually people with university degrees in different fields and any educated professional expects to earn at least the medium salary in his/her country. If you see advertisements that promote quality translations at a very low price, you’ll probably pay for machine translations or crowdsourcing.

If you outsource your project to a translation agency, make sure you know what rates they offer to their translators. All businesses tend to try to cut costs down. You probably don’t want to pay a rate of 200 USD/EUR per 1,000 words to an agency, while the agency finds a cheap translator and pays them a rate of 30 USD/EUR per 1,000 words. Such gaps are very common in the translation industry. Make sure you know what you are paying for and that the quality you receive is worth your money.

Working directly with a freelance translator will usually cost you less and there will be 100% transparency regarding the money you pay.

Basically the rule of thumb here is to collaborate either with small translation agencies (few language pairs covered, they usually value both their clients and their translators), or with freelance translators directly.

Don’t believe those agencies who claim to provide good quality translations in all language pairs possible. It is usually not true. They won’t have the in-house staff to assess the quality of any text in any language.

LocJAM4 Kyoto Study Group Presentation, Topics and Personal Notes


The Kyoto Study Group for LocJAM4 took place on April 22nd and was followed by a networking party. The goal was the same as usual: embody the spirit of the LocJAM by gathering game enthusiasts with various degrees of experience to discuss localization, learn from our collective experience and simply have fun.

The Presentation

For my third LocJAM presentation in just a little over a year, I decided to move away from the game localization process approach and instead went for something a little more concise and practical.

Here is how we approached this year’s event:

  • Quick introduction of the LocJAM: Because a quick reminder of what the LocJAM is and isn’t always helps. The slide is pretty self-explanatory

  • Introduction of Ikinari Maou and playthrough: To understand where the LocJAM4 game is coming from, we introduced and played the original version of Ikinari Maou. Most importantly, we analyzed what is going on in the game (who is who at what time) and how to beat it. Getting that part right is essential to produce a good translation – more on this later

  • Comparison of LocJAM Japan winning translations: The reason I chose this approach for this presentation is that, although the Amateur and Pro winning translations were ultimately picked up by the same group of jurors, they came up with two radically different submissions in terms of style:The Amateur translation is a very creative one, with a well-crafted glossary and a bit of extra humor. It occasionally gets in the over-localization warning zone, but gets away with it thanks to the very solid writing and natural integration of the spiced up bits. And well, it’s a localization contest, so can’t blame people for trying to show off their talent in that area.The Pro translation, on the other hand, is a more faithful one, funny when the original is, neutral when it should be. Clean and accurate, to the point it sometimes gets close to be a little too literal – the perfect opposite of the Amateur translation.You can check the slides for a few examples opposing those two styles, or download the whole text here for Original/Amateur/Pro/LocJAM4 versions of Ikinari Maou.

  • Takeaways: So why did the jury went for two submissions that don’t seem to have much in common? The answer is simple: because above all, those two localizations were executed with talent.People keep asking us if jurors would prefer such or such style. But the truth is that, more than a specific style, jurors will be mainly looking for entries that grasp the spirit of the original game and offer the player a solid experience.Ikinari Maou is a puzzle game. Conveying hints and explanations properly is critical here. Only a few participants really understood what was happening in the game and transcribed that in English. Some other entries had great writing but lost tips in translation, effectively making the game harder than it is supposed to be. So my first advice here for LocJAM4 participants is to really understand how to beat the game and how to ensure the player experience isn’t altered by their translation.The second point is that there are lots of valid styles between over- or under-localization. You shouldn’t focus on what style the jury may or may not like, because 1. there’s no way to know that and 2. it’s not a critical factor in determining winners. More than anything, you should find your voice and stick to it consistently throughout your work. LocJAM Japan winning entries both got that part right, and it’s what truly made them stand out. Reading through their submissions, it was obvious they enjoyed translating the game and were in absolute control of their writing. Just focus on what you do best, and translate the way YOU think is right.

  • Introduction of LocJAM4’s version and quick playthrough: Here, we focused on how characterization and dialogs were purposely exaggerated for the main LocJAM event. We also mentioned the special set of instructions for Japanese translators, who are asked to find their own unique style for this “back-localization”.For the other languages, although we’ve got a spicier version here, the challenge is exactly the same as it was for LocJAM Japan: ensure your localized version preserves the original puzzle-solving experience, find your tone and don’t be afraid to exhibit your craft when the source text calls out for creativity.

  • A bit of fun with the machine-translated version: To end up on a lighter note, we checked a few parts of the original game translated with Google Translate. The result was… interesting, shall we say. Silly fun, but a good way for everybody to relax at the end of the presentation and get in the mood for a chat.

Topics Raised by Participants

Before and after the presentation, the study group gave us all an opportunity to chat about various game localization-related topics:

  • How to get started in the industry: a classic for aspiring translators. We quickly discussed of common job-hunting tactics: contacting localization agencies with a carefully crafted CV, networking, participation to industry events…
  • How to gain experience: the LocJAM, of course! Past edition texts are freely available for translation, regardless of your language pair. Something you can show potential clients, and thus solid marketing materials. Also mentioned the Manga Translation Battle contests for those with a broader interest
  • “A good localizer should also be a spontaneous consultant”: A non-translator participant noted that the game’s font was hard to read and that, if he was a dev, he would appreciate if translators mentioned that issue. It was the starting point of a fascinating discussion about the role of translators and communication with developers. How far we translators should get involved? Are we responsible for offering a similar experience in our native language by making recommendations for font/interface changes? If you’re working with direct clients, you may want to keep in mind that they may desperately need your advice on such issues. Time to polish our consulting skills?
  • How to handle translations for languages heavily depending on context and for which gender/numbers can be ambiguous, like Japanese: in short, experience, careful text analysis and queries when all else fails. If you need context for a large number of strings, try to go for general queries (“can you mention who is talking for each line?”)

How Did it Go?

  • We had a total of 20 people, mostly localizers (good mix of hopefuls/established ones), but also a small number of designers/devs, which encouraged constructive discussions, beyond the sole topic of translation
  • What really pleased me is that everybody blended in naturally. People just started exchanging naturally, and the atmosphere was very friendly. I sort of felt sorry to interrupt the audience to start my presentation
  • Getting a bit personal here: I’m a shy French guy with 0 public speaking skills. I’m not a native speaker of English nor Japanese. Of all the participants, I was probably one of the least qualified to make a presentation. And still, just because I took the initiative, we were able to have a fun event during which everybody learned something and made important connections. It doesn’t take much to organize a LocJAM event, and it doesn’t need to be perfect. Just do it and great things will happen, because we have an amazing community

Game Localization Link Roundup – March 2017

Another month gone in the small world of game localization! In case you missed it, LocJAM4 is now live, with a creative English version of Ikinari Maou as source material. We could have had another Tyrano Builder game for contest, had we wanted to, but we liked that retro-looking RPG-puzzle game so much we thought it would be a shame not to see it localized in more languages by some of our industry’s finest. We’re serving you a spicy, heavily westernized version of the game, but the winning entries of LocJAM Japan -more faithful to the source- are also available online.

We’re already seeing great content from participants popping up here and there, which pleases us immensely. I will myself present at Kyoto’s local study group on April 22nd, after which I will share my presentation and notes.

But for now, here’s the link roundup for March! Interviews and excellent content from the GDC are waiting for you.

Nintendo Treehouse Log – Nintendo’s secretive Treehouse (which handles the localization for many of Nintendo’s games) now has their own blog

Localization talks at GDC 2017 – Final Fantasy, advanced localization tools and Chinese shenanigans in this quick summary of the localization-themed talks at GDC

‘Witcher’ Studio Boss Marcin Iwinski: ‘We Had No Clue How To Make Games’ – Nice long interview with CD Projekt Red’s Marcin Iwinski, from Polish localization to the Witcher

Localization Shenanigans in the Chinese Speaking World – Straight from the GDC vault

Learning Japanese board game culture from Yakuza 0

Localization Roundtable 2017 – Summary – A summary of the topics discussed during the localization round table organized by the SIG during the GDC

Final Fantasy XV Localization Director Talks “Fantasy Based in Reality” and Much More