Add a Translation Delivery API #15214
Replies: 3 comments 2 replies
-
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. 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Is there any news about this? Is it on roadmap, this would be great addition to Content API. |
Beta Was this translation helpful? Give feedback.
-
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
Challenges
LocalizationService
utilizesDictionaryRepository
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
Beta Was this translation helpful? Give feedback.
All reactions