This parameter isn't used since commit b86c0d3c3, which deleted a file
that wasn't used since commit 146c09adb. Further proof that this code
wasn't used is the fact that the `enable_translation_style` method,
which this code called, was removed in commit 5ada97544.
This way it's easier to test; changing it will also be easier.
During my experiments I made a mistake which wasn't covered by the test
suite. We're adding a test for this case.
Note we're using `i18n_content` in the component instead of `content`
because there's already a `content` method provided by ViewComponent.
We understand languages management as the ability to add new languages
or remove existing ones. When no option is passed it will allow language
manipulation by default.
There are 3 special places where we want block languages management:
- admin legislation processes homepage
- admin legislation processes milestones summary
- proposals retired form
Co-Authored-By: Sebastia <sebastia.roig@gmail.com>
It turns out it is not necessary to downcase and underscore
locale names to use the globalize-accessor gem. The gem
will automatically underscore the locale name when defining and
calling the accessor methods.
After creating a translation in spanish, it was also displaying it when selecting
the english locale.
This was due to the code picking the first translation available
With this commit, we are checking for an existing translation in the current locale
and displaying it if it exists
When visiting, for example, /admin/site_customization/information_texts?locale=fr
we were getting an `UncaughtThrowError: uncaught throw :exception`
With the following payload
```
File "/aytomad/app/participa/participacion/releases/20180726231929/app/views/admin/site_customization/information_texts/_form_field.html.erb" line 5
File "/aytomad/app/participa/participacion/releases/20180726231929/app/helpers/globalize_helper.rb" line 35 in block in globalize
```
Substituting this line seems to solve it
Note that we had to remove the portuguese local too, as it was giving a different
exception due to this change. This problem, has been solved in the original
globalization PR
In the admin section of the application, a new page
has been added so that the admins are able to manage
the selected texts for translate.
The texts have been divided in different "sections",
depending on the nature of themselves (budgets, polls,
proposals, management, etc.). Each section has become a tab
with a form associated to edit all the texts for her.
When a language is added, it's added for ALL the texts in the
application. That means that, if an admin adds french for debates,
the french form will appear for the rest of the texts. That doesn't
mean that they need to fill all the texts, only that the languages
work for all of them instead of individually.
