The existing shared example 'translatable' only works for edit actions.
This shared example allow us to check how translations behaves at new
resource pages.
Now this shared specs only works with Proposals, Budget::Investments and
Debates.
* Adapt translatable spec helper method to work with budget investments
* Remove old attributes from strong parameters
* Add missing locales to admin.yml and budgets.yml
* Change SpendingProposal.title_max_length and
SpendingProposal.description_max_lenght to Budget::Investment methods
* Add budget investment translatable attribute translations
After adding investment translatable fields to forms, they will be
generated with nested translations names and ids so we can no longer
use standard id locator.
Using input label text to fill in fields works with both types of forms.
After adding proposal translatable fields to forms, they will be generated with nested translations names and ids so we can no longer
use standard id locator.
Using input label text to fill in fields works with both types of forms.
New version of globalize uses RequestStore gem to store I18n.locale and
Globalize.fallbacks in a per request basis to avoid collissions between
different requests. This gem update broke Globalize.fallback results
because it tries to fetch fallbacks from RequestStore, where there is no
locale fallbacks definition.
The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
Sometimes when updating a resource you are not redirected to the same
resource, you are maybe redirected to the parent resource and the
translations can be different. This condition will be checked after
visiting the edit_path again.
We had a validation rule for milestones which made sure either the
status or the description was present. However, since the description is
now translatable, the validation error wasn't being displayed in the
admin form.
Moving the validation rule to the translation object fixes the problem.
However, the translation object needs to check an attribute in the
milestone object in order to know whether the description is required or
not. This is tricky because by default it loads the milestone object
from the database, meaning it doesn't work with new records and it
ignores params sent by the browser.
The solution is to manually assign the globalized model before
validating the object. It's a hack, but apparently Rails doesn't provide
a better way to handle this case [1].
[1] https://github.com/rails/rails/issues/32024
