What’s covered:
The complex life of content in game development and localization?
Common challenges in game localization
6 practical tips for better control on content localization and enhanced collaboration
- Tip #1 - One source of truth with views for different roles
- Tip #2 - Quick access to references for particular releases
- Tip #3 - Length limit control for translation
- Tip #4 - Communication through API
- Tip #5 - Screenshot generation for better context
- Tip #6 - The use of caching
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.
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.
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.
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.
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.
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
