-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resource path to request calendar i18n data #284
Comments
This is being tracked on the frontend in issue Liturgical-Calendar/LiturgicalCalendarFrontend/issues/161 . |
JohnRDOrazio
added a commit
that referenced
this issue
Jan 16, 2025
# Issue being addressed #284 # Summary of changes allow requests for single i18n resources on the `/data` paths.
Merged
JohnRDOrazio
added a commit
to Liturgical-Calendar/LiturgicalCalendarFrontend
that referenced
this issue
Jan 16, 2025
# Issue being worked on #161 # Summary of changes With the new backend API functionality being worked on in Liturgical-Calendar/LiturgicalCalendarAPI/issues/284 / Liturgical-Calendar/LiturgicalCalendarAPI/pull/285, we load i18n data for the current calendar so as to be able to PUT / PATCH i18n data from the frontend interfaces. While working on these implementations, I also took the opportunity to refactor a lot of the code from jQuery to native javascript, considering that native javascript can do pretty much everything that jQuery has offered up until now. Even bootstrap no longer requires jQuery. The only bootstrap plugin that is still a jQuery plugin is the `multiselect`, so we still need to use jQuery for this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Now that all calendars, whether national or diocesan, have multilingual capabilities, we have to design our frontend in such a way that all the language strings can be defined in a PUT request, and subsequently updated in a PATCH request.
In order for the language strings to be updated in a PATCH request, we first have to be able to display them in the frontend, so we need to allow a GET request. Now we could request the same calendar data in multiple requests, one request for each supported locale; or we could request the full calendar data once in a specified locale, and then request ONLY the translation data for all other locales.
Perhaps this could look something like this for diocesan calendar i18n data:
https://localhost:8000/data/diocese/calgar_ca/fr_CA
Basically just add a further path parameter specifying the locale data being requested. This would not return the calendar data (
litcal
property as a collection of calendar events), but only the map ofevent_key
s andvalue
s.Similarly for a national calendar:
https://localhost:8000/data/nation/CA/fr_CA
And for a widerregion:
https://localhost:8000/data/widerregion/Europe/fr_FR
Should we allow
PATCH
requests against these endpoints? Or shouldPATCH
requests be made against the calendar data paths, i.e.:where the body of the request contains the patched data?
I'm thinking that when we are creating a new resource, for example diocesan calendar data, and we
PUT
against thehttps://localhost:8000/data/diocese
path, we should include all i18n data in the payload. That should simplify creating the data initially. This would mean that we have to update the schemas to account for a new property in the payload with i18n data in one or more different locales.The text was updated successfully, but these errors were encountered: