- Cleanup Translatable module (`translation_params` method too large)
- Move globalize_helpers partial to admin folder
- Use any class for method translation_params
- Helpers in `GlobalizeHelpers` make sure all are in use and see if they can be more legible
- Review js name clases and methods see if they can be more legible
- Refactor milestone views into partials with nice spacing between attributes
Add specs to check that the translations
are being deleted correctly and the
current locale tab is highlighted when the
admin visits the edit milestone page.
There was a problem with the portuguese locale.
The locale was pt-BR, but `globalize_accessors` gem
doesn't allow the creation of methods using locales
with that format.
To avoid transforming pt-BR to pt and lose the distinction
of the different variations of the language, a function has
been added to transform pt-BR into pt_br (without changing
the locale itself). That way, when globalize uses the locales,
all of them will have a valid format (downcased and underscored)
AND they will be always the same (comparing pt-BR with pt_br
doesn't work).
When the locale changes the corresponding tab is
highlighted automatically.
When a language is added to the milestone, the tab
is highlighted automatically.
To delete a translation, a link has been added. This
link works for the selected language. It hides all the
things related to a language (the tab and the text_area)
and empties the text area, so that the value is blank
in the param hash. A variable called `delete_translations[]`
is changed.
e.g. If admin wants to remove English language,
delete_translations[:en] will be 1; if not, it will be 0.
When the milestone is updated, there is a before_action
callback that cleans the selected languages for deletion
(looking the delete_translations[] variable).
Because of the deleted translations are blank in param hash,
them won't be saved in DB.
Until we correctly make MapLocation relation with mappables a polymorphic
one... we'll need to return the investment_id and proposal_id values.
Right now it was returning the MapLocation ID, and the JS was making a
call searching for an Investment with the MapLocation ID... sometimes
finding a record with same ID but totally NOT the one associated to the
MapLocation.
The db:dev_seed rake logs info as it progresses as information for the
developer. But that's not needed when ran from its tests file, and it
bloats the travis/rspec output with unnecessary information.
Now the task will always log info unless the rake task receives an
optional argument.
There's no need to check again headers in this scenario, previous one
already does it.
Correctly naming variables, as well as using explicit expectations is a
good idea.
Last but not least, expectations where reversed but by luck or lack of
attention where passing.
The created investment didn't had all data to correctly assert each
column values are correctly exported.
The expectations checking if each particular text appears are invalid in
this test. The objective is to check that the downloaded file contents
are exactly as they should be... not particular parts checked in an
independent way as for example "Yes" could appear in two different
columns and just looking if the text appears is not a valid assertion.
The csv generation doesn't seem like a Model concern, at least not taking
into account the amount of lines of the method (36+). Just a simple ruby
class that encapsulates the logic makes it easier to read and maintain as
we increase the columns exported.. also customize in case other forks need
different values.
