Fatshark’s 6 tips for better game localization and enhanced collaboration

What’s covered:

The complex life of content in game development and localization

A piece of content, or a content item in game development and localization process could include essential elements for the game’s content, such as a sentence of dialogue, item descriptions, and more. It can also encompass both the text for subtitles and the recorded voice simultaneously for a short string.

Each content item goes through stages of creation, review, and approval to ensure it fits seamlessly with the game’s design and narrative vision.

At Fatshark, managing a content item involves collaboration among numerous individuals across various stages.

Here’s a visualization depicting different roles responsible for handling a content item throughout three major phases: game development, creative writing and content approval, and localization, in which:

Game development is mainly handled by developers.
Creative writing and content approval involve narrative approvers and legal approvers.
Localization is executed by external translators and overseen by an in-house localization manager.

Game development

Essentially, everything starts with the developer who creates the game within the studio.

Developers manage various game assets including gameplay programming, character creation, and item design. They also draft the initial version of text, providing explanations on its purpose and information for the writer.

Within Fatshark’s workflow, developers are responsible for adding new content items and updating all fields with necessary information.

Creative writing and content approval

After developers, creative writers handle the next step of Fatshark’s content workflow. They take the developer’s text and any associated metadata to craft appropriate wording that fits seamlessly into the game universe. The writers play a crucial role in refining the English wording and grammar based on input from the developer.

Throughout this process, writers collaborate closely with both the narrative and legal teams: narrative producers ensure alignment with the story and characters, while legal approvers ensure compliance with intellectual property and legal standards.

Once the writers complete their task, the text undergoes scrutiny from these two key approvers. If either approver rejects the text for any reason, it is returned with detailed notes for revision. The writers must then make the necessary revisions, restarting the approval process.

Localization

When a content item has its final text and all approvals, it’s time for localization. Translators are external and can only see the content items that are fully approved. They work closely with a localization manager, who oversees progress to ensure quality and accurate translations of the content.

From the localization manager’s perspective, it’s important to have a quick overview of what is left to do and where translations are missing.

Fatshark also extends the entire workflow from game development to content approval to include other external parties, such as recording studios for voice-overs. In this case, Fatshark works with a sound manager to oversee the work, and instead of translators, they collaborate with recording studios.

The recording studios follow a similar approval and feedback process as the writers, receiving input from the in-house sound manager. They also have the ability to upload sound files directly as part of the content.

This way, the content items will contain both the text for the subtitles and the recorded voice.

Common challenges in game localization

The major issues companies often struggle with, and also Fatshark had in the past, revolve around:

Manual effort required for importing and exporting data sheets.
Localization managed in different tools across various stages of the game.
Long load times for content to load from various databases, hindering fast iteration.

Currently, Fatshark uses Gridly for all text in their games, including UI text, voice-over scripts, subtitles, in-game store content, and item names. We asked Krister Larsson and Oscar Tillgren about the tips Fatshark used to overcome their challenges and achieve efficient localization and enhanced collaboration.

6 practical tips for better control on content localization and enhanced collaboration

Tip #1 - One source of truth with views for different roles.

In reality, the Fatshark team has one live database for each project and one testing sandbox. In the sandbox, everyone has full access to experiment and test features. This setup essentially simplifies the process of requesting changes, as Fatshark has restricted permissions to alter core elements in the live environment.

Users have various options for organizing data in Gridly. At the top level within the app is the company, which includes multiple projects. Each project contains several databases, and within each database are one or more Grids.

Grids are similar to spreadsheets but function more like database tables, with a precisely defined structure for individual content types.

Hierarchy structure in Gridly

Here’s how projects are organized in Gridly and what a Grid hosting the database at Fatshark looks like:

An overview of Projects in Gridly

Fatshark’s default view of a Grid

1.1. Role-based views

Given that different people don’t need to see all the columns, Fatshark creates separate role-based views.

With Views, you can define which data in a Grid is displayed and how it is shown. They also allow users to control access to content. Views can display all or part of the data in a customized format for different purposes.

For example, different Views can be created for translators, LQA, or external contractors within a single Grid.

An example of how the Admin and Writer have different views of the same live database

Most users don’t have permissions to change the view setup and have far fewer elements cluttering their interface.

At Fatshark, every role is assigned two views to manage their tasks effectively:

Regular View: This view is named after a role, such as Writer. It displays exactly what the company wants to show for each role based on their responsibilities.
To-do View: This view is also named after the role, followed by “TODO”, e.g. “Writer-TODO”. It shows only the tasks left to complete for that role.

Both of these Views hide any columns not needed for the role, and some columns are visible but not editable.

Regular and to-do views for the writer

The to-do views is created based on two major types of requirements:

Localization status
Approval columns for some roles

1.2. Localization status

When a piece of source content is added or changed, how do different roles in the localization workflow become aware of these changes and know what actions to take? What if the localization workflow involves two source languages, with one serving as an intermediary step to translate content from the original source to the target languages?

Fatshark has two types of source language stored in two columns: “Developer Text” and “Master Text”.

“Developer Text” consists of raw text provided by developers in English.
“Master Text” is updated by writers, also in English.

Other columns contain translated content in different languages that depend on the “Master Text”, while the “Master Text” relies on the “Developer Text”.

This setup allows developers to add strings in the “Developer Text” column while ensuring that writers are responsible for finalizing the text stored in the Master Text column.

Fatshark uses the Dependencies function in Gridly to establish one-way relationships between source and target languages. If any string is updated in the “Developer Text” cell, the “Master Text” cells and the corresponding target languages are highlighted, signaling the need for attention from the creative writers and the translation team.

1.3. Approval columns for some roles

In the Grid, Fatshark has several columns indicating different stages, such as “Approved”, “Needs Re-approval”, “Not Approved” and “Not Set”.

An example of how these stages shown in a Grid of Fatshark

The workflow here is that when a writer finishes, one of two things happens:

If the content item is new, the writer does not need to take any action; it will automatically appear in the narrative approver’s to-do list.
If the record has been changed after already being approved, the writer needs to manually set the “Narrative State” to “Needs re-approval”. This ensures it will also appear in the narrative approver’s to-do list.

Once the “Master text” is completed and everything is approved, the record will disappear from the writer’s to-do list.

In a Grid, columns can represent various data types such as single line, multiple line, boolean, datetime, etc. The approval columns, such as “Narrative State” and “IP State” are formatted using the single-selection data type.

1.4. Conditions to dynamically update role-based views

How Fatshark sets up to-do views is simple, based on different conditions for each role. Here is an example of the conditions used to set up the “Writer-TODO” view, filtering and displaying only records that meet these criteria:

“Master Text” is not “Up-to-date”
“Narrative State” is not “Approved”
“IP state” is not “Approved”

All Fatshark to-do views are constructed in the same way, but with varying conditions.

An example of how to set up “Writer-TODO” view

Tip #2 - Quick access to references for particular releases

Another highly effective way that Fatshark has improved their localization experience is through the use of Reference columns. Fatshark uses this approach to avoid having their team members manually input text (even if it is a very short piece of text) to minimize the chances of creating errors and mismatches.

Setting up a static dropdown list indicating a certain version using the single-selection column data type can be challenging because content items may undergo multiple versions throughout a project. Using reference columns instead of a static dropdown list keeps the data dynamic and updated, providing a more flexible solution.

Reference is a special column data type. It allows users to point to data and values in another column in another Grid.

Users can therefore refer to the existing content from various locations. When updated, the changes are populated everywhere.

On the main Grid, which hosts examples for their entire live database, there are two columns named *“Release”* and *“Release Date”*. The *“Release”* column displays a dropdown list, and the *“Release Date”* column is updated automatically after a selection is made in the *“Release”* column.

These options are sourced from another Grid that stores the original information. Anytime the Grid containing the original information is updated, it will populate the “Release” and “Release Date” columns in the main working Grid.

Tip #3 - Length limit control for translation

Game localization always requires translations to fit the placeholders perfectly and without any truncation. To help team members easily be aware of this, the Fatshark team used formulas on Grid columns to check the length of translations. (Gridly not only has a spreadsheet-like UI but also allows columns with formulas similar to those in a spreadsheet).

Now, with the built-in function Set Length Limit on localization-related columns, Fatshark team members working on a particular column can quickly determine whether the translated text is within or exceeds the allowed limit.

Setting a length limit allows users to regulate the maximum number of characters in both the source and target translations. Users can set a character limit for the source language and specify the number of additional characters allowed for target languages.

Once setting is completed, a small icon will appear in the cells to indicate the character length status. Hovering over the icon will show the current translation length and the maximum permitted length.

If the limit is exceeded, the icon will turn red. This function also allows users to filter strings that exceed (or do not exceed) the character limit.

Tip #4 - Communication through API

Internally, Fatshark built two types of tools that frequently communicate with Gridly: importers and exporters.

Importers are tools designed to collect game data that require translation and upload it into Gridly. This data can include elements such as voice-overs, item descriptions, and other relevant content.

Conversely, exporters function in the opposite manner: they retrieve strings from the Grids, download them locally, and then apply necessary data transformations to fit their intended use. For instance, since the localization requirements differ between the game launcher and the game itself, Fatsharks use two distinct exporters to accommodate these variations.

Gridly API supports various programming languages. Given that Fatshark build their importers and exporters with C#, the team fork the Gridly’s C# SDK and leverage that in their programming tools (importers and exporters) to easily call API functions and retrieve desired content.

Tip #5 - Screenshot generation for better context

To enhance clarity and understanding through the contextual provision of content localization, Fatshark takes snapshots of items when importing data into Gridly. This practice helps writers quickly grasp the purpose of each item, especially for those whose functions may not be immediately clear from their descriptions. Additionally, having these snapshots simplifies the process of reviewing data in Gridly, allowing users to easily see what they are working with.

Tip #6 - The use of caching

Since the Gridly API limit is 20 requests per second, Fatshark utilizes a cache to minimize the number of API calls to Gridly, thereby preventing potential overload. Fatshark uses a cache for each tool used by the team, which is loaded at the start of each tool.

The cache at Fatshark stores strings in a .json file that includes a dictionary containing key-value pairs and timestamps. In this setup, the keys correspond to the string IDs from Gridly, while the values represent the actual strings.

Using a cache significantly reduces bandwidth consumption for Fatshark because it eliminates the need to download all entries every time they are accessed. This efficiency also saves considerable time, as downloading numerous entries can be time-consuming.

Below is an outline of how the cache operates:

Read the cache entries and retrieve the latest timestamp stored.
Download all entries from Gridly that are newer than the timestamp in the cache.
If an entry downloaded from Gridly already exists in the cache, update it. Otherwise, add the entry to the cache.

In the Darktide game, Fatshark reveals that they have around 11,000 strings for UI and 5,000 strings for the dialogue. With 12 languages supported in Darktide, this turns into lots of data quite quickly.

Cache saves a lot of time for Fatshark when it comes to exporting translations into the game. It would take 20-30 minutes to export a database, but with caching in place, it’s only a matter of seconds.

Frequently asked questions

How many people are typically involved in localizing a single piece of game content?

More than most studios anticipate. At Fatshark, a single content item — a line of dialogue, an item description, a UI string — passes through developers who draft the initial text, creative writers who refine wording to fit the game universe, narrative producers who validate alignment with story and characters, legal approvers who check intellectual property and compliance, a localization manager who oversees translation progress and quality, and external translators who produce the final multilingual versions. For voiced content, recording studios and sound managers are added to that chain. Each handoff between roles is a point where context can be lost or errors introduced if the workflow is not structured carefully.

What are the most common technical challenges in game localization workflows?

Three problems recur across studios managing localization at scale. The first is the manual effort required to import and export data sheets between tools — a process that is time-consuming, error-prone, and difficult to audit when something goes wrong. The second is localization managed across different tools at different stages of production, which fragments content and makes it nearly impossible to maintain a single source of truth. The third is long load times when retrieving content from databases, which slows iteration and forces teams to batch their work instead of making fast, incremental updates. Fatshark encountered all three before centralizing their workflow in a single platform.

What is a single source of truth in game localization and why does it matter?

A single source of truth is a centralized content repository where every piece of game text — UI strings, dialogue, item descriptions, voiceover scripts — is stored, updated, and accessed by all contributors. When teams work across multiple spreadsheets, shared drives, or disconnected tools, different contributors end up working from different versions of the same content simultaneously. This produces translation errors, version conflicts, and data loss that are expensive to detect and fix after the fact. At Fatshark, maintaining one live database per project — with a separate sandbox for testing — means every change made by any contributor is visible to every other contributor in real time, with no file exchange required.

How do role-based views prevent errors in collaborative localization workflows?

Role-based views restrict what each contributor can see and edit to exactly what their role requires — nothing more. A translator does not need to see developer notes or approval status columns; a legal approver does not need to see translation memory suggestions. When all columns are visible to all users, the interface becomes cluttered, contributors make edits outside their area of responsibility, and sensitive information is exposed unnecessarily. Fatshark gives each role two views: a standard view showing all relevant content for that role, and a to-do view filtered dynamically to show only the records that currently require that role’s attention. This keeps each contributor focused, reduces interface complexity, and prevents accidental edits to columns that should be read-only for that role.

What is a dependency in a localization platform and how does Fatshark use it?

A dependency is a defined relationship between two content columns that automatically flags downstream content for review when upstream content changes. At Fatshark, the “Developer Text” column (raw developer-provided English) has a dependency relationship with the “Master Text” column (refined writer English), which in turn has dependencies with all translated language columns. When a developer updates a string in “Developer Text,” the “Master Text” cell and all corresponding translated cells are automatically highlighted to signal that a writer and translators need to review and update them. This eliminates the need for manual communication about what has changed — the system surfaces the affected content automatically, ensuring nothing is missed across a project with thousands of strings.

How do you enforce character limits for game translations across multiple languages?

Character limits in games are not optional — text that exceeds the allocated space in a UI element is either truncated or breaks the layout, both of which are unacceptable in a shipped product. The challenge is that translations are typically longer than the source text, and the length varies unpredictably by language and string. Fatshark enforces limits using column-level length limit settings that display a real-time character count indicator directly in each cell. When a translation exceeds the permitted length, the indicator turns red, making the violation immediately visible without requiring a separate QA pass. Translators can also filter the entire Grid to show only strings currently exceeding their limits, allowing targeted batch correction rather than manual string-by-string review.

Why do game translators need screenshot context and how is it provided efficiently?

Translators working from a list of strings without visual context must guess at the meaning, register, and spatial constraints of each piece of text — and those guesses are frequently wrong. A two-word UI label like “Back” or “Confirm” may require different translations depending on whether it appears in a combat menu, an in-game shop, or a settings screen. A voiceover line needs different treatment depending on the emotional context of the scene. Fatshark addresses this by automatically generating and uploading screenshots at import time, so each string in the database has a corresponding screenshot displayed alongside it. This allows translators and LQA testers to instantly understand the context and constraints of every string without needing to launch the game or request information from a developer.

How does API integration streamline the game localization pipeline?

Direct API integration replaces the manual export-translate-import cycle with automated, programmatic data transfer between the game engine and the localization platform. Fatshark built two categories of API-connected tools: importers that automatically collect game content requiring translation and upload it into Gridly, and exporters that retrieve approved translations and apply the format transformations needed for each specific use case — for example, the localization requirements for the game launcher differ from those for the game itself, so separate exporters handle each. Built on Gridly’s C# SDK, these tools allow the engineering team to trigger content updates and retrieve translations without manual intervention, keeping the localization database continuously synchronized with the state of the game.

What is caching in game localization and why does it matter at scale?

Caching in game localization means storing a local copy of retrieved strings — with timestamps — so that subsequent requests only need to download content that has changed since the last cache update rather than re-fetching the entire dataset each time. For a game like Warhammer 40,000: Darktide, which has approximately 11,000 UI strings and 5,000 dialogue strings across 12 languages, a full database export without caching would take 20 to 30 minutes. With caching in place, that same operation completes in seconds, because the exporter only pulls the strings that have been updated since the previous run. This performance difference directly affects iteration speed during production, where translators and developers may need to export updated content multiple times per day.

How does Fatshark handle voiceover localization alongside text?

Voiceover localization runs through the same content workflow as text, with recording studios treated as external contributors in the same system rather than managed through a separate process. When a content item requires both subtitles and recorded voice, the text and audio file are stored together within the same content record. Recording studios receive access to approved content items, upload completed audio files directly into the platform, and follow the same review and approval stages as translators — receiving feedback from the sound manager and revising until the recording is approved. This unified approach means the subtitle text and its corresponding voiceover file are always associated in the same record, eliminating the version tracking problems that arise when audio and text are managed in separate systems.

What can other game studios apply from Fatshark’s localization approach?

The core principle behind all six of Fatshark’s practices is reducing the gap between content creation and localization by eliminating manual steps, ambiguity, and tool fragmentation. Any studio can apply this thinking by centralizing all content in a single database with clearly defined column structures; assigning role-based access so contributors only see and edit what is relevant to their responsibilities; using dependency tracking to automatically surface downstream content that needs updating when source strings change; enforcing character limits programmatically rather than relying on translators to self-check; providing screenshot context at the point of translation rather than on request; and using API integration to eliminate manual file exchanges between the game engine and the localization platform.

Fatshark’s innovative use of Gridly has allowed them to streamline their localization process and enhance team collaboration. By leveraging these 6 localization practices, game studios can gain insights into optimizing localization workflows to deliver an immersive gaming experience through high-quality localized content for global audiences.

>> Learn more about localization management with Gridly

>> Explore how to take LQA to the next level

>> Learn how Rovio, the creator of Angry Birds, accelerated LQA by 4x