# Localization

This describes how the localization is solved in the game

Top

#### 1 Translations in database

Because this webpage has translations in database, and there is text, that will be common for both webpage and game, then game uses database to store all translations.
In table is just bit telling that some translation is related to game, thus, game server be selecting only the translations that are related to game only

#### 2 Translation token

One translation consists of basically 2 things:

• Token - identifier of translation
• Text - Corresponding text for that token
Example can be: token.example.hello : token.example.hola.
Then, when we want to reffer to the text from html or somewhere, we simply use the token.

#### 3 Static translations

Static translation is translation, that can be seen in pure HTML, which is rendered directly by EJS on server side. For such translations, the text is translated by server, and final translated text is sent to client in the HTML.

#### 4 Dynamic translations

Are translations, that can be seen in game itself (canvas), and are usually drawn by client.
In such case, only token is sent to client (for example, client knows, that upon ability usage, text with token game.console.freeze should be displayed in console, but client needs to be able to translate it...)

##### 4.1 How server operates with translations

When server starts, it loads ALL game related translations from database for both languages (En, Es) and keeps them in memory for the lifetime.

##### 4.1.1 Transporing translations to client

When client connects to the server, it sends sever information telling what language he requires. This, however, must be done via URL, since server could staticaly translate html to english, but the via socket will client require spanish, and there will be no way to re-translate the HTML, which is already in english.

Server will then send all translations of such language to the client.
Later on, server just sends instead of translated text only the token (for example, monster will have as display name some token, that shall be translated on client side).
Like this, considering that tokens will be generally shorter than translated text, will be during gameplay sent less text (because tokens will be sent instead of real text)

#### 5 Translation retrieval

The translations are taken from database, (more in-depth is explained here), and retreival takes place always, when server starts, with exception described below (in here)

##### 4.1.2 Optimalization of sent data

The sent data must be minified, to cut down the loading times, as much as possible.
Here is an example of client received translation data:

The same hashmap, but [game.console.] was substituted with [\$2] and [game.] was substituted with [\$1]

Hashmap of received translations (key is token, value is the translated text)

As you can see, the list is quite long, and it is still going.
The translated text can not be optimalized, but there are common parts of the tokens. That means, that for example game. can be substituted for special sequence of characters, such as $1$ for transporting the data. This would save us 2 letters in this example, at 100 translations we are saving up to 200 letters.

#### 6 Diagram

All explained above is depicted by following diagram, which definitelly brings more clarity to the process than words:

#### 7 Optimalization

In case of for example translations, the server would load all translations upon start, and keep them in memory for entire lifetime. For that, there is no other way (more efficient way) to do it, as if the translations would be loaded dynamically (only when requested from client) and the cached, the loading times would be enormous.

The optimalization lies in caching loaded database data to file. Upon startup, server check for cache file, and if there is nothing new against database, the cache file is used as data resource, speeding up the loading time enourmously.
The situation is displayed by following sequence diagram: