Skip to content
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

Open
JohnRDOrazio opened this issue Jan 15, 2025 · 1 comment
Open

resource path to request calendar i18n data #284

JohnRDOrazio opened this issue Jan 15, 2025 · 1 comment
Assignees

Comments

@JohnRDOrazio
Copy link
Member

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 of event_keys and values.

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 should PATCH requests be made against the calendar data paths, i.e.:

PATCH https://localhost:8000/data/diocese/calgar_ca
PATCH https://localhost:8000/data/nation/CA
PATCH https://localhost:8000/data/widerregion/Europe

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.

@JohnRDOrazio
Copy link
Member Author

This is being tracked on the frontend in issue Liturgical-Calendar/LiturgicalCalendarFrontend/issues/161 .

@JohnRDOrazio JohnRDOrazio self-assigned this Jan 16, 2025
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.
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant