We need to replace ".title=" by ".title_#{locale}=" in one place because
for some reason globalize builds a new translation record when using the
latter but it doesn't build one when using the former.
Updating it required reorganizing the form so translatable fields are
together.
We also needed to add a `hint` option to the form label and input
methods so the hint wouldn't show up for every language.
Finally, the markdown editor needed to use the same globalize attributes
as inputs, labels and hints, which adds a bit of duplication.
Note the title field was hidden since commit 01b9aa8, even though it was
required and translatable. I've removed the required validation rule,
since it doesn't seem to make much sense and made the translatable
tests harder to write.
Also note the method `I18n.localize`, which is used to set the
milestone's title, uses `I18n.locale` even if it's inside a
`Globalize.with_locale` block, and so the same format is generated for
every locale.
The same way we did for banners.
We needed to add new translation keys so the labels are displayed in the
correct language. I've kept the original `title` and `body` attributes
so they can be used in other places.
While backporting, we also added the original translations because they
hadn't been backported yet.
This change forces us to use nested attributes for translations, instead
of using the more convenient `:"title_#{locale}"` methods.
On the other hand, we can use Rails' native `_destroy` attribute to
remove existing translations, so we don't have to use our custom
`delete_translations`, which was a bit buggy since it didn't consider
failed updates.
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.
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
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.
