As we cannot order budget investments by any translatable field through
AR queries we are doing the same using ruby Array sort method and doing
array pagination manually with Kaminari 'paginate_array' helper method.
This method will be used by any translatable model that uses pg_search
feature so it's better to have it within globalizable model concern so
all translatable models can use it.
Paranoia is activated on translation classes by reflection, this is
making Rails to load translation classes before to execute migration
that adds the new column.
With this extra check Rails will not execute this code until translation
table has this column created.
Move method from sanitizable to globalizable concern because
globalize_accessors were overiding sanitizable method and was never
called. Another solution to this could be to load sanitizable
always after globalizable concern.
Old method implementation was not working well with globalize_accessors,
it was returning nil always.
Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:
https://github.com/globalize/globalize/compare/v5.0.0...v5.2.0#diff-a1370b109e0dd567545b072bc6447b8fR51
This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.
To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.
Another way to properly load our custom Milestone::Translation class is
to place it inside parent model class, like the example below:
class Milestone
...
class Translation
delegate :status_id, to: :globalized_model
end
end
Or maybe monkey patching translation_class method from globalize gem
to make it find our custom translation class. I don't like this option.
This way we guarantee there will be at least one translation for a model
and we keep compatibility with the rest of the application, which
ideally isn't aware of globalize.
