We use a different logic to load the card depending on the controller
we're using, and then share the rest of the code. This way we simplify
the code a bit, since we don't have to check for the page_id parameter.
We didn't add any validation rules to the card model. At the very least,
the title should be mandatory.
The fact that the label field is marked as optional in the form but the
other fields are not probably means description and link should be
mandatory as well. However, since there might be institutions using
cards with descriptions but no link or cards with links but no
description, so we're keeping these fields optional for compatibility
reasons. We might change our minds in the future, though.
We're using the translation fallbacks for the icons, just like we do for
texts.
Note we use the `render?` method provided by view_component to make sure
the component will not be rendered when certain features are disabled.
Also note the `find_asset` method works differently in development and
production, and so we use different approaches here.
This class provides a method which shows whether a certain process is
enabled.
Even if it uses a helper, this class is inside the models folder because
the helper it uses actually only uses model methods. We might eventually
remove/simplify this helper and cache inside the model, like we did with
I18n content translations in commit 41dba842a.
The same it's done in the UN official SDG pages.
We could try to split the string on a space which is more or less in the
middle. However, this wouldn't work on languages which don't have spaces
between works, like Chinese.
So in the end I've added a new translation key, where the title is
supposed to be split in several lines the same way it's done by the UN.
The same way it's done in the official SDG icons. We're also using
uppercase with slightly smaller letter spacing for the same reason.
Even though we didn't do so in the past, we're moving the font to its
own folder inside the vendor folder and including the license file as
well in order to make it clear that these files do not follow the same
license CONSUL uses.
They were all following the same format.
Note we need to group the `see_all` translation keys together (the same
way it's done with the `most_active` keys) so we don't have an unused
translation warning.
We're also moving the "see all" link in processes outside the feed
content; the same way it's done in debates and proposals and removing
unnecessary classes in the processes feed: the column class is causing
the processes not to be aligned with the debates above them, and the
margin bottom is not needed because the margin of the footer is already
enough.
Note we're using the code instead of the ID to get the goal in the URL.
IMHO this is what most people would expect; visiting a URL with a "7"
takes you to SDG number 7, and not to the one with "7" as a database ID.
In order to avoid tests (either automated tests or manual tests) passing
by coincidence due to the goal ID and the goal code being the same, I'm
shuffling the codes before entering them in the databse.
I've tried using `resolve` in the routes so the code is automatically
taken into account, but it doesn't work since `resolve` cannot be used
inside a namespace, and here we're within the `sdg` namespace.
Note using `params[:relatable_type].classify` is recognized as a
security risk by some tools. However, it's a false positive, since we've
added constraints to the URL so that paramenter can only have the values
we trust.
This way we avoid fetching each translation every time it's requested.
This reduces the amount of queries in the development logs and also
makes the test suite faster.
