It was accidentally deleted in commit 914bfa6.
Note the following spec passes on my machine if we add a `sleep 0.1`
call in the `:wait_readable` part of ruby's `Net::Protocol#rbuf_fill`.
Otherwise, it hangs forever after clicking the `.fileupload-file` div,
which closes its window. It might be solved when upgrading rails,
capybara, selenium or chromedriver.
scenario "Allows images in CKEditor", :js do
visit edit_admin_site_customization_page_path(custom_page)
within(".ckeditor") do
within_frame(0) { expect(page).not_to have_css("img") }
expect(page).to have_css(".cke_toolbar .cke_button__image_icon")
find(".cke_toolbar .cke_button__image_icon").click
end
within_window(window_opened_by { click_link "Browse Server" }) do
attach_file :file,
Rails.root.join('spec/fixtures/files/clippy.jpg'),
visible: false
find(".fileupload-file").click
end
click_link "OK"
within(".ckeditor") do
within_frame(0) { expect(page).to have_css("img") }
end
end
The test was failing sometimes because of the sequence:
within('#side_menu') do
click_link "Collaborative Legislation"
end
click_link "All"
expect(page).to have_content 'An example legislation process'
click_link 'An example legislation process'
Right after clicking the "Collaborative Legislation" link, the link 'An
example legislation process' is already available. So sometimes Capybara
might click the links "All" and 'An example legislation process' at more
or less the same time, causing the second link not to be correctly
clicked.
Making sure the "All" link doesn't exist anymore we guarantee Capybara
will wait for the previous AJAX request to finish before clicking the
next link.
Note the test to "Create Valid legislation question" is almost identical
but it doesn't fail because it doesn't use Capybara's JavaScript driver.
Skipping a spec in the middle of it, particularly after doing some
requests, caused Capybara to keep using the same driver in the following
spec.
Since the current spec uses the JavaScript driver, the next test would
also use the JavaScript driver, causing apparently random failures if
that test was supposed to use the Rack driver.
This spec was causing a side effect on another spec[2], making it fail 😌
I think it was because no translation had been called yet, in the failing spec, and so the the i18n backend translations had not been initialized, and was always returning empty translations for any locale. This might have been due to tampering with translations in the this newly introduced spec.
By forcing translations to load after this new spec, the other spec passes again
[2] https://github.com/AyuntamientoMadrid/consul/blob/master/spec/features/localization_spec.rb#L20
There where two issues with the current implementation:
- There was a possible duplication between looking up the language name in key "locale" and in key "i18n.language.name"
- The "default" option was not being picked up, as the fallback always returned the default locale's translation, "English"
With this implementation there is only a single place to put the language name: i18n.language.name. I think this place is easier to find and understand for Crowdin translators than a "locale" key hidden in general.yml
If the translation is not found we display the language key, instead of English, which makes more sense to me too 😌
Solution based on recent comments[1] on a related I18n issue
[1] https://github.com/svenfuchs/i18n/issues/365#issuecomment-419263847
We work with many languages using Crowdin[1]
Sometimes translators forget to fill in all the necessary plural forms of a translation (zero, one, other) and in those cases we were seing the exception InvalidPluralizationData being raised
There are a number of approches to fix this... from being more strict when approving translations, to automatically extrapolating what those plural forms should be
For now, we've gone for a simple approach to display the actual count(0,1,2,3,4, etc) instead of the whole translation
So, if the plural form of "1 comment" is missing, just a "1" will be displayed and no exceptions raised
Note: The first two specs, test what is really Rails' functionalities. However as we are monkey patching the pluralize method, I thought it was appropriate to doble check it
[1]https://crowdin.com/project/consul
By default records are already ordered by ID, so we weren't checking the
ordering by ID functionality was working properly.
Making the records be ordered by title first makes the test a bit more
reliable.
Just like it's done everywhere else in the application. Not doing so
means users who aren't logged in receive a "you aren't authorized"
message when they try to create a new legislation proposal instead of
being redirected to the login page.
We set `I18n.locale = :en` before each test, and so creating a new card
will automatically create English translations.
So visiting the Spanish page won't show the card, since no Spanish
translation exists for it. If we visit the klingon page after doing so,
the last used locale (Spanish) will still be used, and so the test will
fail.
Specifically creating Spanish translations instead of the English ones
makes the translations visible when visiting the Spanish homepage.
