You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 of event_keys and values.
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 the https://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:
# 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.
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: