It has been detected that for the :pt-BR, :zh-CN and :zh-TW locales,
the translate button was being displayed, but when requesting the
translation, the remote translation validation failed due to:
'''
validates :locale, inclusion: { in: ->(_) {
RemoteTranslations::Microsoft::AvailableLocales.available_locales }}
'''
That available_locales method did not contemplate these 3 languages
in the format used by the application.
To solve this problem the api response is mapped to return all
locales in the format expected by the application.
Add remote translation model test to ensure that a remote translation
is valid when its locale is pt-BR.
Co-Authored-By: Javi Martín <35156+javierm@users.noreply.github.com>
TranslatorText isn't compatible with Ruby 3, so we need to use a
different gem.
The 'translator-text' gem response was an array of one or more objects.
Now with the 'bing_translator' gem the response is an array with one or
several translated texts.
We remove the concept of object in the code. And we also remove the
"create_response" method from the specs since it is no longer necessary
to emulate that object and we can simply use arrays with texts to emulate
the new response.
Since we changed the way we integrate coveralls in commit 8ed8cc8b9,
we're getting 6 additional checks displayed in our pull requests.
We don't need these checks, and they only add noise. The only reason we
use coveralls is to know the test coverage in our master branch.
So we're changing the code so coveralls only runs on the master branch.
There's also a chance that the test suite will be faster because it
doesn't need to keep track of the coverage, although I haven't noticed any
significant differences during my tests.
I haven't found a more elegant way to say that a certain step should
only be run on push on master, so I'm setting the environment variable
we were already using.
We were getting many errors when trying to run them, from uninitialized
constant `HTTP` to undefined method `headers`.
We might move these examples to the documentation repository in the
future, but we need to look for possible side-effects first.
Since we're now allowing <h2> and <h3> tags in the description, we
remove the broken <h3> tag from quiz-question class. Since its content
is also in the <title> element, and in order to be consistent with other
show actions in the public area, we change this tag to <h1>.
We add <h2> tag in the "Share" heading and we replace the broken <h4>
tag above adding new styles.
To be consistent with the previous commit we update the text that appears
in the administration tables for discussions and proposals. Now instead of
"Proposals" and "Discussions" will appear "Title" which makes more sense
and is more consistent.
In the images.yml file we have a duplicate key with the same translation,
so we can remove it.
In the admin.yml file we have a duplicate key with different translation.
This translation is only used in 2 places in the application:
- In the administration table for collaborative legislation proposal index.
- In the <% provide :title do %> of the same page.
Although it is true that now the second translation (Title) is applied in
both cases, I think it makes more sense to use the first one (Proposals)
in the page title because it seems to make more sense and be more useful
to use "Proposals" instead of “Title”.
In order not to modify the behavior in the translation shown in the
administration table, we add human_attribute_name to obtain the expected
result.
The test that was not passing sometimes since commit 915999db4 because
we no longer created the budget before visiting the page that loads it.
So now we're forcing its creation with `let!`.
When accessing the valuation area, we were only displaying the
investments directly assigned to the current valuator, but we weren't
displaying the investments assigned to that valuator's group.
Using the `assigned_investments_ids` method, which takes the valuator
group into account, solves the issue.
We've also found an issue on our development machines: since we don't
have a unique index per `investment_id` and `valuator_id` in the
`budget_valuator_assignments` table, we've found duplicate records on
this table. When that happened, we were displaying the same investment
several times.
Since now we no longer join this table in the query returning the
investment, this issue is also solved, and we're adding a test for it.
We can now remove the call to the `distinct` method when calculating the
number of investments per heading.
This is consistent with the component for balloting stats. We're about
to change both components, and the changes are easier to follow if
they're similar.
We're also using consistent names in methods.
To get the heading where a user voted, we were relying on the
`balloted_heading_id` field.
Our guess is this was done so the total number of users is the same as
the sum of users who voted on a heading. That is, if 2000 people voted
just on the "All city" heading, 1000 voted just on the "North district"
heading, and 500 people voted on both, instead of showing "3500 people
voted in total, 2500 voted in all city, 1500 voted in north district",
we show something like "3500 people voted in total, 2250 voted in all
city, and 1250 voted in north district".
However, this approach has some disadvantages.
The first disadvantage is, the stats aren't correct. In the case above,
2500 voted on the "All city heading", so the statistics for this heading
don't show reality.
The second one is we weren't considering the last heading where users
voted inside the budget being displayed, but the last heading where
users voted, period. That means that, if all the people above voted on a
later budget, the stats for the budget above would become "3500 people
voted in total, 0 voted in all city, and 0 voted in north district".
That also means we were including headings from previous budgets in the
statistics for more recent budgets when people hadn't voted on the
recent ones.
So we're removing the `balloted_heading_id` since its data is lost once
people vote on a new budget. And, in order to show the right stats and
simplify the code, we're no longer trying to add votes just to one
heading when users vote on several headings.
Co-Authored-By: Julian Nicolas Herrero <microweb10@gmail.com>
The <th> elements should be inside <tr> elements.
Since we're changing this code, we're also adding <thead> and <tbody>
tags because that's what we usually do and it makes it easier to select
<tr> tags from either the table head or the table body using CSS or
JavaScript.
We're also moving the tests, but we're keeping one system test in order
to test the controller and the navigation to get to this page.
Note we're slightly changing the order of the methods in the component;
the order of the instance variables was `user_`, `vote_`, `vote_`,
`user_`, which was hard to follow.
We don't need groups to create headings since commit 20b1085dc, and
`let!` was used as a substitute for instance variables in commit
91c21b098, but it isn't necessary in this case.
We weren't allowing the `budget_id` parameter and then we were adding it
manually. We were also allowing other parameters that aren't used in the
valuation section.
So we're allowing budget and heading, which are the only parameter we're
offering filters for in the user interface. Note the `budget_id`
parameter doesn't seem to make sense because we're already inside a
`@budget.investments` statement, but the `budget_id` parameter is
required by the `scoped_filter` method.
We've experienced some caching issues with this code for years. We've
fixed some of them in commits 9979b5399 and 3645c333a, but we're still
running into other issues. In order to really cache this section, we'd
need to cache:
* Whether or not the investment should show the aside and vote/support
buttons (we could do it by caching its budget)
* Whether its budget is balloting or finished (we could do it by caching
its budget)
* Whether the current user is following the investment
* Whether the `remove_investments_supports` feature is enabled
* Whether the `community` feature is enabled
* The value of the `org_name` setting
* The value of the `twitter_handle` setting
We weren't caching all these elements, meaning that (for instance), we
didn't display the button to vote when a budget moved into the voting
phase if we had already cached this section without the button.
And chances are the list is incomplete. So, instead of trying to take
into account every single possible factor that should make us expire the
cache, we're restricting the cache so it only affects the content of the
investment. This is similar to what we do in the investments index,
where we cache the content of the investment but we don't cache the
vote/support buttons.
Since the change on commit cbbe188d6 we added a Poll.current.any?
condition to show the officing link on admin menu to officers.
That condition doesn't have much sense since Poll results only can be
added after a poll has ended, and there may be only one active poll.
In most sections, we had two specs testing what happens after accessing
one of the privileged areas. We're grouping the expectations and so
we've only got one test per area, making these tests faster.
This way we reduce the number of system tests or, in some cases,
requests during system tests, making the tests faster.
We're still testing the interaction with the menu when users have the
right permissions.
