This describes how the localization is solved in the game
This is sub-layout for documentation pages
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
One translation consists of basically 2 things:
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.
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...)
When server starts, it loads ALL game related translations from database for both languages (En, Es) and keeps them in memory for the lifetime.
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)
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:
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.
All explained above is depicted by following diagram, which definitelly brings more clarity to the process than words:
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: