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.
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.
Results were not including records without translations for current
locale (I18n.locale). Now we search for given title against all
translation fallbacks for current locale.
Also fix sort_by_title method [1]
[1] Use ruby sort instead of active record order scope because Globalize
does not provide a way to search over all available fallbacks when
translation for current locale does not exist.
* Convert proposal form into translatable one.
* Adapt translatable shared spec to define an owner when running at
frontend feature specs.
* Remove old attributes from strong parameters.
Also fix broken spec after removing translatable attributes from
strong_parameters definition. Now we need to send these attributes
as nested translations attributes.
Use activerecord.yml title attribute label so form helper could load it
from default location.
After adding debate 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.
Adapt retire form to include needed translations and move validations
from controller to model.
Also change sanitizable concern to sanitize not marked for destruction
translations.
- Conect to remote translation service and translate array of strings
- Create SentencesParser module with texts management methods:
- Detect split position method: When the text requested to translate is too large, we need split it in smaller parts for we can translate. This method search first valid point (dot or whitespace) for split this text so then we can get an response without dividing the word in half.
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.
Proposal, Debate and Comment "globalize_accessors" class method were
loaded before application available locales initialization because of
graphql initializer. This will cause unexpected translation errors at
any translatable classes declared at graphql api definition (api.yml).
Doing GraphQL initialization after application initialization should
solve this issue.
