There are some sections where we are not reusing it:
* The budget investments search is completely different, so this
component isn't appropriate there
* Booth assignment and officers are slightly different, and I'm not
entirely sure it's safe to refactor these cases
We were writing the same text over and over for the same translations.
Since they all serve the same function, it's perfectly fine for them to
have the same text, and so we can have a shared translation.
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>
We were repeating the same code over and over (with a few variants) to
setup tests which require an administrator. We can use a tag and
simplify the code.
Similar to what we do with settings, only for settings we return the
value of the setting (which is what we're going to need most of the
time), and here we return the object.
This way we'll be able to apply it to the SDG icon, which is not
included in font-awesome.
Note we're adding a font-icon selector so it's defined before the
admin-menu-icon selector and so in case of conflicting rules the ones in
the admin-menu-icon selector are used.
Since data for this model (title and description) is not generated in
CONSUL but by the United Nations, we aren't storing it in the database
but in our YAML translation files.
The reasoning is as follows. Suppose that, a few months after CONSUL
gets SDG support, a new language is added to CONSUL.
With YAML files, getting the texts in the new language would mean
updating CONSUL to include the new language.
But if we store these texts in the database, it means we have to update
the databases of all existing CONSUL installations, either each
installation by themselves (duplicating efforts) or running a rake task
(which we would have to write each time).
So we believe using translations works better in this case.
We're still storing records in the database with the code, so they can
be easily referenced via `has_many` or `has_many :through` associations.
This way we simplify the HTML and generating similar menus will be
easier. We also improve the experience for screen reader users, who
might have been hearing the icons as text because we weren't using the
`aria-hidden` attribute.
We're still keeping the "icon-" classes for compatibility with CONSUL
installations which might have changed this code.
From a semantic point of view, there's no reason to add a strong
emphasis to the menu items.
Besides, using CSS simplifies the code and is less error-prone. For
instance, the "stats" section didn't have a <strong> tag, and so it was
the only one which wasn't bold.
Now that there's no naming confict with the helper method used in the
ProposalsDashboardHelper, we can easily simplify the view, moving the
logic to the Ruby class.
The HTML `class` attribute was declared twice and so the second one was
being ignored.
In the case of messages, it was "working" properly because the
`class=is-active` part is not used on `<li>` tags when they've got a
`<ul>` inside them.
We no longer need to use the `menu_` prefix, since now these methods
aren't helper methods anymore, and so their names won't collide with
other helpers.
