## The READ

From different action, we will submit to the Localization Service a set of string to translate. It can be from template, TyObject, etc...
Once the data in is Localization Service, we will send a request to Crowdin to let the translation team translate these sentences.

Hypothetically, Crowdin will contact the LS to notify the availability of a translation once it has been done via Webhooks. Once received, we will store it in our internal database to take ownership of the data.

This system is **NOT** real-time. String will be requested for translation and some time after, we can access it. We don't need it in the same page reload (request translation, waiting Crowdin IA and get in on-the-fly)

sequenceDiagram
    RSI-Website->>Localization Service: Submit new string to translate
    Localization Service->>Crowdin: String sent to Crowdin API
    Crowdin-->>Localization Service: Notification of translated string
    RSI-Website-->>Localization Service: THE READ

### 1. 🟢 Call the Localization Service API in order to get translations

We can perform a request to the Localization Server API with for some translated string instead of calling the database directly.
In order to do that, the Localization Service need to expose an endpoint to allow other project to contact it. It can be call from backend or frontend projects.
This endpoint can be an HTTP Controller who will just wait some string keys. The cache on the LS (memory cache) will check if some of string are already found and if not, search in the database.
📈*With a combo of cache / database we can achieve good performance.*

stateDiagram-v2
    direction LR
        RSI.Website --> Localization.Service
        Localization.Service --> Internal.Database
        Internal.Database --> Localization.Service
        Localization.Service --> RSI.Website

- **Advantages:**
- Exposing our own endpoint and not use directly the Crodwin one, get rid of rate limit on Crowdin
- Today some part of front are doing a GraphQL call on rsi-website to request some translations. It can replace this behaviour and let the translation request load from the Localization Service.
- We can create a cache easily with more granularity on the LS, group translation request & stuff like that

    stateDiagram-v2
        direction LR
        Request --> LS: Request translations
        LS --> Cache: 1 - Search for cached translation
        Cache --> LS: 2 - Found translated strings in cache
        LS --> Database: 3 - Search for untranslated strings
        Database --> LS: 4 - Found translated string in cache
        LS --> Request: Send all translations

- The logic behind the request to the Localization Service can be easily sharable: create 2 libraries / drivers / adapters on each language (PHP & TS) to implement easily an interface / service who know what to call to request translations. This system can implement a pseudo memory cache on TS side.

    pseudo TranslatorInterface
        + requestTanslationForString(...keys, ...strings)
        + getTranslatedString(...keys)
        - httpCallToLocalizationService()
        - checkOwnCache(...keys)

    flowchart TD
    A[Ship-Upgrade] -->|Call the lib| C{TS Driver}
    B[Customizer] -->|Call the lib| C{TS Driver}
    D[RSI-Website] -->|Call the lib| F{PHP Driver}
    E[Travern] -->|Call the lib| F{PHP Driver}
    C -->|Know how/where to request| G[Localization Service]
    F -->|And know how to receive & use it| G[Localization Service]
    G --> H(We don't care)

- With a good cache implementation, we don't need a lot of BDD instance, maybe one can be enough. Replication for the Localization Service (controller side) will do the job. Maybe sharding can be overkill in that case.

- **Disavantadges:**
- We are doing 2 request for a single stuff: contact the LS who will contact our Internal Database, it can impact performance on the loading page.
- Need to code & maintain more code on the Localisation Service

### 2. 🔴 Call to Crowdin directly

Instead of calling the Localisation Service or the database directly when we need a translated string, we can just call the source of truth: Crowdin.
More for a `real-time` system, it can be useful to call them directly.

stateDiagram-v2
    direction LR
        RSI.Website --> Crowdin: No Localization Service
        Crowdin --> RSI.Website

- **Advantages:**
- Simple to implement, just need to send GET request with string key and langage

- **Disavantadges:**
- We will reach easily the rate limit of Crowdin's API
- Less efficient to call an external API (comparing a local one)

### 3. 🔴 Call the Internal BDD directly

Instead of calling a middleware project between our projects and the database, we can contact directly the database. Depending on the choosen engine, it can be easy to contact directly via some simple request (like redis, already done on rsi-website) in order to get directly the datas.

stateDiagram-v2
    direction LR
        RSI.Website --> Internal.Database: No intermediaries
        Internal.Database --> RSI.Website

- **Advantages:**
- We don't need to manage a controller & implement a cache system
- It can be faster on request side: Crowdin have the whole infra to handle all these strings request to serve it fastly

- **Disavantadges:**
- The cache system can't exist on this side, and if we do it, we must implement it on each project

### 4. 🟢 Generate a translation file (dictionnary) for each project, "on-demand"

For each project like the customizer, the ship-upgrade, etc, we can download on each boot a partial translation file who contain all translation for these projects.
The LS will expose an endpoint and allow a file download containing all translations related to this project . That implies a `non` real-time system.
It can be at boot or simply on-demand, per example from an endpoint to call.

*This strategy is maybe not the best for an MVP, but this solution can be implemented to be a good complement to the 1st strategy at the end, for some project like **ship-upgrade** & **customizer***

sequenceDiagram
    Customizer->>Localization Service: Request translation file on boot
    Localization Service->>Database: Retrieve all translations linked to this project
    Database->>Localization Service: Build the "file"
    Localization Service->>Customizer: Send the file containing all translations

- **Advantages:**
- Simpler to implement. We just need to download a file one time
- The file is local, so really really fast to read and serve the data
- This system can be implemented as a complementary solution of other strategies

- **Disavantadges:**
- That implies a non real-time system
- We need to reload the whole service or expose an endpoint to reload the translation file