liturgical-calendar / liturgicalcalendarfrontend Goto Github PK

When creating a new festivity, it will almost always be a fixed festivity (if we define month and day, then it's fixed).

If however we use the strtotime option, this probably means that the festivity is mobile. Can the backend simply deduce this from the presence of the strtotime parameter?

There is currently confusion on how locales should be indicated.

In order to better associate geographical language data from various Missals within a wider region, the translation files associated with Wider Regions use the format nn_NN, where both locale and region are indicated.

However, when saving Wider Region metadata in a National calendar, we are still using only nn. This means the wider region data will not be effectively picked up:

Some national calendars might be printed in more than one language. For example, I believe that in the United States, Spanish is recognized as an official language in the liturgy, and there is a Spanish language edition of the Missal? This may need some looking into, but certainly there are nations that have more than one language, and more than one language edition of the Missal.

When switching between mobile or fixed festivity type using the mobile switch (when defining a calendar for a diocese for example), values are lost. We should find a way to keep values such that when switching back, we should get the previous value back...

after detaching the frontend from the API backend, and cleaning up the frontend, using CDNs for the vendor JS and CSS files, there seem to be a few issues that need looking into.

In the fullcalendar example, tooltips when hovering over single liturgical events are now showing as empty. Perhaps because the frontend relied on some of the translation strings / functions from the backend? Need to look into this.

Seeing that we just simply load Wider Region calendars and National calendars when selected and when they have already been defined, we should perhaps do the same with the Diocesan calendars, avoiding the extra step of having to click on "retrieve existing data". Then we could simply remove this button, which would become useless.

A lot of the form control code is duplicated between extending.js and admin.js. Perhaps the FormControl class should be abstracted out into a separate module that can be reused in both instances.

Readings are generally defined for new festivities.

In the case of the national calendar for USA, there is one new mobile festivity: Thanksgiving. However, the readings are not being added to the festivity object. Even if the readings are empty, the basic structure with corresponding properties should still be created. This is necessary for the JSON to evaluate properly against the schema.

When creating a Wider Region calendar, if isMultilingual is checked, we should be able to choose which languages are used in the region (probably which languages the Missals in the wider region are printed in).

This way the backend script can already create the basic translation files in JSON format for those languages.

Companion issue to Liturgical-Calendar/LiturgicalCalendarAPI#113 .
Once that is fixed, the frontend needs to make sure it produces the JSON accordingly.

With commit f55ef85 , the calendar select generated in PHP for usage.php and for liturgyOfAnyDay.php was standardized and made reusable by abstracting it to layout/calendarselect.php.

However, on the homepage, we are generating the Calendar Select widget via javascript, which is handled in assets/js/homepage.js:

We should standardize the two approaches, and use just one or the other for all instances.

On the main page, under data generation endpoint, in the dropdown with a list of calendars to choose from, only the Vatican is currently showing. We had forced Italy and USA to show even when there are no diocesan calendars defined, seeing that we have baked the data for these two national calendars directly into the API backend. For some reason, they're not showing now, and not even the Diocesan Calendars are showing. What happened?

Translation strings should be handled with Gettext on the PHP side, and with JSON strings on the javascript side. Seeing that a number of the translation strings may be in common with the API backend, handling translations through Weblate will make it that much easier to recycle previously translated strings from other "weblate components" within the same project.

There should be some information in the frontend website about how to go about with translations, who can do translations, what criteria to follow when doing translations... which translations get what done... and the current status of translations.

On the "Liturgy of any day" page, entering in a Day returns results for the day preceding the input day, see screenshot:

code (but the bug may be in the backend):
https://github.com/Liturgical-Calendar/LiturgicalCalendarFrontend/blob/main/liturgyOfAnyDay.php#L81

The sb-admin theme introduced by @mftruso added a pleasant interface to this project. However, the sb-admin theme doesn't always follow semantic html in a coherent manner. There have been updates to support Bootstrap 5, so we should try to update to a more recent sb-admin theme with Bootstrap 5 support.

Perhaps we could even look into an mdbootstrap admin theme (such as https://github.com/mdbootstrap/bootstrap-5-admin-template/ ), which probably has better support and follows html semantics in a more coherent manner...

Am currently trying to update to a newer sb-admin theme, however it's not very flexible... The sidebar seems to be pretty much hardcoded to a dark theme... I think that an mdbootstrap theme may be more flexible and adaptable...

My vision for the "extending the calendar" section of the frontend is a breadcrumb approach, starting from the more general areas down to the more specific areas:

Instead of having three separate menu items, we should always start from the Wider Region, and show a predefined list of all Wider Regions that have patron saints. In this list, we should see immediately which ones have already been created and which ones haven't (like green and red highlights). Clicking on an already created wider region will load the data, clicking on one that hasn't yet been defined will allow you to create it.

Upon creating a wider region, you can choose which nations belong to the wider region; upon selecting an already created wider region, you will have a list of nations that belong to it. From the list of nations, you should see which ones have been defined and which ones haven't.

Again, selecting an already defined nation will load it's calendar data; selecting one that hasn't yet been defined will allow to create it.

When an already created national calendar has been loaded, or a new national calendar has been created, we should see a list of dioceses that belong to that nation. And the process continues: select an already created diocesan calendar to load it, select one that hasn't yet been created in order to define it's data and create it.

Is this feasible? Are there patron saints that apply to continents? Should we start with a list of continents? Should there be multiple layers for the "wider regions"? For example, are there patron saints for wider regions that are not continents, but still comprise a number of nations?

A good start to help rationalize all this would be knowing which Romans Missals have been printed / approved, we would need a complete list. And knowing which "wider region" patron saints have been declared over the years, and map out which "wider regions" they apply to. Having this data will allow us to create the most rational frontend approach.