Add a Translation Delivery API

[kjac]

Add a Translation Delivery API to the core

Currently there is no core Delivery APIs to distribute translations (dictionary items). It seems a reasonable thing to include in the core offering.

Credits go to @ToxicKevinFerm for the original proposal in #15132

Things to consider

1. How should this API be shaped? There are a multitude of use cases for translations:
   • Some "just" want all translations in one go.
   • Some structure translations by site in multi-site setups, perhaps with a shared translation structure too.
   • Some only require named translations.
   • ...
2. Which format should be output?
   • Some use cases call for a dictionary structure of [key,translation].
   • Some consumers would have a hard time consuming a dictionary structure and would prefer something more deterministic.

Challenges

1. The LocalizationService utilizes DictionaryRepository which is uncached at this point. It is not an option to expose uncached data in a potentially public API, as this would represent an easy attack vector for malicious users.

Known limitations

1. Heartcore does not feature a "Translation" section and thus will not follow suit with a Translation Delivery API

[ToxicKevinFerm]

Hey!

I had the idea that it could use a Start-Item/key argument and then optionally a depth or expand parameter following the current delivery API structure. That would allow for most use cases I think.
If your Start-Item or key is a tree and you want to expand, you'll get the whole tree below it, otherwise you just get that specific key.

In this way, we allow for all kinds of structures of dictionary, you could have everything in the root and you could structure it per site, or per function as per your use case.

My simple use case would be to internationalize a Next.js/Gatsby statically generated site, and being able to fetch a KV json-object would make using i18next (https://www.i18next.com/) or other internationalization standards very easy.

Maybe we could use an Accept header to determine what format to return. If the api is sent Accept: text/plain you can just return the value straight up.

[ToxicKevinFerm]

A little update on my journey, I did end up creating an index for dictionary keys for my own use, and it seems to work well.

In my personal use case, I don't need the parent nodes, just a flat structure in the index was fine for me, but you could easily save the parent key as well.

[ndamkjaer]

Thanks for your work. Can you please share the final code?

[BlagoCuljak]

Is there any news about this? Is it on roadmap, this would be great addition to Content API.

[bergmania]

There is no news.. On a official one and it is currently not on the roadmap.

I would encourage you to create it as a package and when you have figured out a stable API specification, we can consider to pull it into the CMS.