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.
So tests won't fail when an institution changes the default organization
name.
The tests are also easier to understand now, since it's more obvious
where the "CONSUL" text is coming from.
This way screen reader users will be notified that the element is the
current one.
I'm not entirely sure whether `aria-current="page"` is more appropriate
than `aria-current="true"`, since it's a general helper which can be
used for any collection of links.
A list of links is a very common pattern in the web, and we use it in
many places. Here we're applying it to one of the most simple ones; the
help page.
Generally speaking, I'm not a big fan of helpers, but there are methods
which IMHO qualify as helpers when:
* They do not deal with application objects but mainly strings and
arrays
* They return text or an HTML tag
* Their logic is simple and splitting it into several methods is not
necessary
Many Rails helpers, like `tag`, follow these principles.
and its relation with the SDG goal model.
Add comparable module be able to sort collections of targets
by code attribute.
Co-Authored-By: Javi Martín <35156+javierm@users.noreply.github.com>
