kenaug74/Sylius
1
0
Fork 0
mirror of https://github.com/Sylius/Sylius.git synced 2026-07-14 09:02:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

docs #12752 [ADR] Strategy for resource internationalization in API (lchrusciel)

Browse source 
This PR was merged into the 1.12 branch.

Discussion
----------

| Q               | A
| --------------- | -----
| Branch?         | 1.12
| Bug fix?        | no
| New feature?    | no
| BC breaks?      | no
| Deprecations?   | no
| Related tickets | closes #11412
| License         | MIT


Commits
-------

d3ed76fbe1 [ADR] Strategy for resource internationalization in API
This commit is contained in:
Jakub Tobiasz 2023-02-03 13:48:11 +01:00 • committed by GitHub
commit 702a3fdf9d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 61 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

61
adr/2021_06_24_api_content_internationalization.md Normal file
View file

@ -0,0 +1,61 @@
# API - Customization internationalization
* Status: proposed
* Date: 2021-06-24
## Context and Problem Statement
A big chunk of resources available in Sylius have some part locale aware. Product descriptions, names of payment or shipping methods
should be translated to the customer to provide the best user experience. Right now most of the resources are returned with
all available translations in the store and proper localization of content is left to the frontend developers. What is more,
this solution is not consistent, as some endpoints already embeds some part of translatables in them. We should provide clear,
easy to use and consistent way of handling customer locales.
## Considered Options
### Returning all possible translations to the frontend
We can update all not coherent at the moment resources to always returning all possible translations and leave it to the fronted to render proper one.
* Good, because it is simplest and fastest solution at the moment of writing this document.
* Good, because it leaves decision of proper content localization to the frontend developer. This guarantees flexibility.
* Bad, because of data over-fetching. Most of the locales in the most to the cases won't be needed.
* Bad, because it leaves decision of proper content localization to the frontend developer. Additional work is required on the frontend
App in order to provide localization functionality.
### Taking advantage of JSON-LD specification for strings internationalization
As researched by @pamil, we can take advantage of JSON-LD processor, return data according to its specification and leave
proper data structure to the JSON-LD processor.
* Good, because it follows some external standard. This may allow us to take an advantage of the standard ecosystem.
* Good, because it solves over-fetching problem, yet leaves the flexibility to the developer if they decide to fetch more than one locale in a single request.
* Good, because it is suggested as a good direction for content internationalization by the API Platform core team.
* Bad, because we are bounded to only one standard. It may not solve internationalization issues with other formats than JSON-LD.
* Bad, because it is not part of API Platform yet and significant effort would need to be done in order to provide proper solution.
Ref.
* https://github.com/Sylius/Sylius/issues/11412
* https://github.com/api-platform/core/issues/127
### Flatting down translatable parts of resources to the structure of the main resource
This approach goes the most side to side with the default Sylius architecture. This is the way, how we treat Sylius resources
internally for most of the cases. It is supported out-of-the-box and can be easily achieved. By default all resources are
served in a default locale of a channel (or Administrator in terms of admin panel). This may fallback to app wise default locale.
* Good, because it follows our current behaviour.
* Good, because it solves over-fetching problem.
* Good, because it is straight-forward to implement.
* Bad, because it does not allow fetching more than one locale.
* Bad, because it will become our internal standard only.
## Decision Outcome
The first approach should be used in admin section of API, while the third one should be used in shop section. This way, we
will receive best of both worlds with the minimal effort. It is worth mentioning that Sylius have two distinguish entry points
to API - admin and shop. They are concerned about different things and resolves different problems. Unified view of a product
in the shop will make it easy and straightforward to build product pages. At the same time all translation approach should be used in
admin to provide full control over "translation" resource - as we should treat them. Therefore, every resource translation
should be linked to the main resource through IRI. Each of these translation resource may be a subject of all CRUD operations
accessible throughout HTTP Verbs.