Use new translation system

[Razzmatazzz]

Should be deployed to production in conjunction with the matching data manager PR. Changes the way translations are handled to save space and make it easier to get a list of which strings we use.

[github-actions]

👋 Thanks for opening a pull request!

If you are new, please check out the trimmed down summary of our deployment process below:

1. 👀 Observe the CI jobs and tests to ensure they are passing

2. ✔️ Obtain an approval/review on this pull request

3. 🚀 Deploy your pull request to the development environment with .deploy to development

4. 🚀 Deploy your pull request to the production environment with .deploy

   If anything goes wrong, rollback with .deploy main

5. 🎉 Merge!

Need help? Type .help as a comment or visit the usage guide for more details

Please note, if you have a more complex change, it is advised to claim a deployment lock with .lock <environment> --reason <reason> to prevent other deployments from happening while you are working on your change.

Once your PR has been merged, you can remove the lock with .unlock <environment>.

[Razzmatazzz]

.deploy to development

[github-actions]

Deployment Triggered 🚀

Razzmatazzz, started a branch deployment to development

You can watch the progress here 🔗

Branch: locale-streamline

[github-actions]

API Deployment - Development 🪐

The API has been deployed to the development environment 🚀

• Endpoint: dev-api.tarkov.dev
• Playground: dev-api.tarkov.dev/___graphql

Pusher: @Razzmatazzz, Action: issue_comment, Workflow: branch-deploy;

[github-actions]

Deployment Results ✅

Razzmatazzz successfully deployed branch locale-streamline to development

Environment URL: dev-api.tarkov.dev/graphql

[Razzmatazzz]

.deploy

[github-actions]

Deployment Triggered 🚀

Razzmatazzz, started a branch deployment to production

You can watch the progress here 🔗

Branch: locale-streamline

[github-actions]

API Deployment - Production 🌔

The API has been deployed to the production environment 🚀

• Endpoint: api.tarkov.dev
• Playground: api.tarkov.dev/___graphql

Pusher: @Razzmatazzz, Action: issue_comment, Workflow: branch-deploy;

[github-actions]

Deployment Results ✅

Razzmatazzz successfully deployed branch locale-streamline to production

Environment URL: api.tarkov.dev/graphql

[Shebuka]

Why not save the context in the worker? We are doing init with the context every time anyway so every consequent call to getLocale can simply use the context saved in the worker. Am I missing something? 🤔

[Razzmatazzz]

Each request has its own context, and part of that context is the requestId assigned to the request. Initializing the KVs using the requestId is necessary to avoid hanging promises. None of this is changed behavior from how the API previously worked; just instead of initializing using the requestId, it passes the context object which includes the requestId.

[Razzmatazzz]

.deploy

[github-actions]

Deployment Triggered 🚀

Razzmatazzz, started a branch deployment to production

You can watch the progress here 🔗

Branch: locale-streamline

[github-actions]

API Deployment - Production 🌔

The API has been deployed to the production environment 🚀

• Endpoint: api.tarkov.dev
• Playground: api.tarkov.dev/___graphql

Pusher: @Razzmatazzz, Action: issue_comment, Workflow: branch-deploy;

[github-actions]

Deployment Results ✅

Razzmatazzz successfully deployed branch locale-streamline to production

Environment URL: api.tarkov.dev/graphql

[Shebuka]

it passes the context object which includes the requestId

Exactly, so why not assign the context to the worker instance and use it directly in getLocale?

something like this:

class WorkerKV {
    constructor(kvName, dataSource) {
        this.context = null;

    async init(context) {
        this.context = context;

    getLocale(key, info) {
        if (!key) {
            return null;
        }
        const lang = this.context.util.getLang(info, context);

[Razzmatazzz]

Because that worker class is instantiated once for each KV we use. But a worker can respond to multiple requests simultaneously. If the worker saves every context it receives to a single variable, it will end up calling getLocale using the wrong context for some requests.

[Razzmatazzz]

To expand on this a bit more:

The overall cloudflare worker has a "data store" that basically consists of multiple instances of the WorkerKV object, one instance for each KV used in the API.

With the cloudflare worker keeping one copy of each KV for its entire runtime, we eliminate duplicate unnecessary KV reads. Once a particular KV is read, the worker holds the result in memory until that data is considered stale, and then it reads the KV again. So each cloudflare worker only reads the KVs as often as absolutely necessary.

When the cloudflare worker receives a new API request, it assigns that request a unique ID, and assigns that request ID to the context object that the GraphQL library uses (and that is available when resolving GraphQL queries). The "data store" of WorkerKV object instances is also added to the context for each request. When GraphQL is resolving a query, the WorkerKV objects use the request ID from the context object to track which requests are responsible for triggering an initial read of the KV data (if necessary). Each GraphQL query will also potentially be made in a different language.

So if the context object for a request is saved to the WorkerKV object, there is no guarantee that the correct context object will be available at that variable later in code execution. A subsequent request may have overwritten it.

[Shebuka]

Good explanation, thank you, I also now see that loadingPromises is an array of the request so it makes total sense.

[Razzmatazzz]

I should probably add comments that explain what's going on to help with maintainability. If I approached this repo fresh, there is a lot of stuff I'd think could be done differently and more efficiently but would actually cause errors due to the unique behavior of Cloudflare workers.