NOTE: The game fonts may not support certain language characters.

All the assets for localization are available in this Google Drive[drive.google.com] folder.

This guide is also available as a Google Doc[docs.google.com].

"en.json" is the file containing all strings for the game.

Newly added, changed, or removed strings per update are documented over at the “Changelogs” folder in the google drive folder.

When in doubt about anything at all, whether it be something the guide doesn’t cover, or the context of certain strings, the fastest way to reach us is via Discord[discord.gg].

If you find any issues or bugs related to localization (certain strings not being translated, or maybe UI overflow) - let us know over at the Discord as well, or on the Steam forums!

Good luck, and happy translating!

The locale file comes in the format of a .json file. If you are unfamiliar, .json is a lightweight data interchange format that stores a collection of name/value pairs, and you can open it with your text editor of choice.

Think of it like a massive dictionary, with each entry containing a key that the game uses to fetch the localized text from, and the value - which is, the localized text.


The "KEY": text represents the key, contained with quotation marks (“ “) and ends with “:” to point to the value. You never touch the key.

Rather, you want to edit the text that comes afterwards, as that is the value forwarded to the game. Like the key, it is also contained within quotation marks, and ends with a comma ( , ) if there is an additional entry afterwards.

To see your localization in action, simply drag the .json file into:


And launch the game - you should be able to pick your language from the Settings > Preferences menu, so long as your .json file is named in accordance with the ISO Language Code[www.lingoes.net] table.

If the language fails to load, it’s likely you’ve formatted your .json file incorrectly. The developer console should point to the problematic line in your file.

Often you’ll find tags in the localization strings, such as “<color=red>Text 1</color> Text 2”, for example.

These tags help mark specific sections of the string with different effects, and it is important to preserve them. You can find most of these tags here[digitalnativestudios.com]. We also have a website where you can input text and it will visualize the effects of the tags here[nanoshinono.me].

Here are all the tags we used in the MicroWorks locale:

(Color)

As you can guess, this tag sets the color of the text.

The tag opens with <color=>, and paints all text that comes after with the provided color.

Provided color can either be explicit (“red”, “blue”, “green”), or it can be a hexadecimal code for customized precision (“#FC5656”, “#FFEA7A”).

The tag closes with </color>, returning all text afterwards to the original color, or the previous color tag, if it was not closed off.



(Size)

This tag sets the size of the text.

The tag opens with <size=>, and resizes all text that comes after with the provided size number.

The tag closes with </size>, returning all text afterwards to the original size, or the previous size tag, if it was not closed off.



(Bold)

This tag sets the text to bold.

The tag opens with <b>, and bolds all text that comes after. The tag closes with </b>.



(Italics)

This tag sets the text to italics.

The tag opens with <i>, and sets all text that comes after to italics. The tag closes with </i>.



(Underline)

This tag sets the text to be underlined.

The tag opens with <u>, and underlines all text that comes after. The tag closes with </u>.



(Tab)

This tag adds a tab stop.



(Linefeed)

This tag moves the text down to a new line.



(Quotation Mark)

This one is interesting - remember how quotation marks are used to define the beginning and end of keys & values in the .json file?

If we’d want to use actual quotation marks in the localized value, we’d append “\” to it to avoid breaking the .json file.

Similarly to the tags above, but they don’t so much as stylize the text as much as they help us format it.

For example, in many cases we’d want to dynamically fill in a string, like “%{player} has joined the game!”, where %{player} is replaced by the player’s name.

You are not meant to translate those tags, but rather incorporate them into your localized string to create a coherent sentence.

Here are all the tags we used in the MicroWorks locale:

(Value Fill-In)

These tags are replaced by the game to fill in a specific text like a player’s name, number, or another localized string.

The ‘value’ inside %{value} represents a key that the game uses to fetch this tag - you must not change it.



(Keybind Fill-In)

These tags are replaced by the game to fill in a player’s keybind.

For example, if we want to display a hint that says the player should use the fire key, this is how we’d incorporate this player’s specifically set keybind.

The ‘bind’ in !{Bind+} represents the action key that the game uses to fetch the appropriate keybind for. The added + or - after represents whether the action is a positive or negative axis (for binds like a mouse axis or controller axis). Overall though, you must not change the tag.




(embedding this one as an image because Steam keeps trying to parse this and ruining the text)

Easily the most confusing one, but don’t worry. This isn’t so much of a tag, as it is a different type of text value, that allows us to construct an array and select different strings according to a provided count.

For example, when displaying a scoreboard, we want to show who is 1st, 2nd, 3rd, or nth. Depending on the placement, the text changes, which is what this type of value is useful for.

It is initialized with brackets [ ] instead of quotation marks, and for every entry inside this table, you add an additional two brackets [ ], and a comma , if there is another entry afterwards.

In each entry, you specify 3 values:
Min Number, Max Number, “Text”

If the value that the game provides is between min and max numbers, this string will be picked. “null” can be provided as an infinite value.

You may edit this table to suit the way your language would require handling the situation.

Colors are a significant part of MicroWorks, and you’ll often find them used in microgames like “Get On The X Platform”, or as a sequence like “Red, Blue, Green” in microgames like “Repeat The Sequence”.

In many languages (which are not English), the spelling of the colors may change depending on the gender of the described object, like “Red Platform”. So let’s go over how to handle localization of colors in microgames and boss stages:

Firstly, you’ll notice in the locale file that we have a list of Color names, one which is capitalized at the beginning and one that isn’t. For example:


The capitalized versions are used as nouns, or the general names of the colors. You can find them used in microgames like Repeat The Sequence: “Red, Blue, Blue, Yellow”

Or in boss stages like Falling Platforms: “Get on… Red”

The regular, non capitalized versions are used as adjectives, describing an object, like a Red Platform, or Green Tile. As you may have guessed, they are used in microgames like Get On The X Platform: “Get On The Red Platform”.

As mentioned earlier, some languages use gendered adjectives and, depending on the object, may need to use a different word. For example, the Red in “Get On The Red Platform” might not sound the same as the Red in “Step On The Red Tile”.

To combat this, you can duplicate the color entries in the locale file, but append “_Male” or “_Female” as a suffix to create the gendered variants.



And translate them according to the gendered Male or Female variant.

Pro Tip: You can also do this with the capitalized variant:



Then, when you have to translate a microgame and use a gendered color variant, like:


You would simply also append “_male” or “_female” (lower case this time!) to the value fill-in key. For example:


Keep in mind this only works for microgames & boss stages, where applicable.

Since Beta 5, MicroWorks gained support for proper string pluralization.

It allows for proper selection of the right locale string for various counts of a noun, since a lot of languages do not work well with the simple bound-based pluralization system described earlier.

The new system works by specifying different localization strings for the unicode-specified amount categories, like so:


The available amount categories and the rules associated with them are visible on the Unicode consortium’s website[unicode-org.github.io], as not every language uses all of them.

To set the pluralization group of your language, you can add a “pluralizedGroup” value in the localization string, right after the “values” declaration, like so:


The pluralization groups for every language are adapted from the Unicode consortium’s website and are defined in this document[docs.google.com], if there’s no specified group, the group will default to group 6 (English pluralization rules).

True pluralized strings can be used in any place regular bound-based pluralized strings were used before. If a microgame or string uses a number to specify the count of a noun, you can use either system to specify the proper plural version of said noun.

EXAMPLE

Checking on the Unicode website, Polish only uses “one, few, many and other”



If I were to implement the rules for “Pointmatch_Formatting” as defined by the Polish pluralization rules, I’d need to define entries for all of these categories. Unicode provides examples of which categories map to which ranges of numbers, as well as presenting them on a nice linear graph:



So, in order to have “Pointmatch_Formatting” properly pluralized as according to how the Polish language works like, I’d need to set the definition of it inside of “pl.json” like so:


Running this tag through the I18n system will output the proper pluralized versions depending on the “n” variable.

n of 1 will output “1 PUNKT”
n of 2 will output “2 PUNKTY”
n of 11 will output “11 PUNKTÓW”
n of 23 will output “23 PUNKTY”

And so on.

With Beta 6, we’ve added the ability to localize keybinds in MicroWorks.

It works by checking the localization file for the existence of tags in the form of “ControlKey_{name}”, where {name} is the name one of the key codes present in this list[docs.unity3d.com].

So, for example: if you’d like to translate the left shift bind, the proper way to do it is to add a new I18n tag into the localization file with the name of the key code corresponding to the left shift button.



Then, in the localization file, just add:

For example, this is how it would look like in the polish locale:

However, if a keybind doesn’t have a translation entry, it will just default back to its english name.

Also, to reduce the amount of things that need to be translated, we’ve introduced a special localization tag called "ControlKey_Numpad", which is used as the baseline for any button present on the numerical keyboard.

The English version of this tag looks like this:
where %{key} is the actual key pressed on the numerical keyboard.

So for example, if I were to press the numerical enter key, the end result would look like this: “Numpad Enter”.

The key of course is also translatable, and will just pull from the regular translation tag (in this case, it’ll be “ControlKey_Enter”).

Workshop support coming soon!!

Alternatively, if you'd like to incorporate your language officially into the game, you can contact us on Discord[discord.gg], for us to review, test and determine whether the localization is good for official implementation.

Before sending in your localization, please make sure and confirm you understand the following:

1. The language you are submitting is not already in the game.
   
2. The localization is fully complete and up to date with the latest game version.
   
3. If we choose to add your localization officially, you will be credited for your work in the game credits. You will not, however, be owed anything beyond, financial or otherwise.
   
4. We may choose to deny your localization for any reason.

...that being said, we are always appreciative of any help in making our game accessible worldwide, and we love working together with fans to make these kinds of things possible! So don't be shy to drop on by and ask a few questions.