Always use explicit question specific options in i18n YAML #2005
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Looks good to me. |
I want to use explicit question-specific options instead of relying on the fallback to flow-level options or the fallback to the option key name. When running the regression tests the change in this commit will display missing i18n option keys.
The following options were not used anywhere and have been removed:
"5-days": "5 days per week"
"6-days": "6 days per week"
"6-or-7-days": "6 or 7 days per week"
"7-days": "7 days per week"
The options for `what_particular_day_of_the_month_is_the_employee_paid?` were provided by the fallback to the option keys, which in this case happen to be capitalised day names. Since I want to remove this fallback, I've listed the options explicitly.
I want to add options to this question, so it needs to have an explicit key.
Even though the `claimed_expenses_for_current_business?` question had some options specified, these were not being found, because `yes` and `no` are *boolean* values [1] in YAML. The options for this question is falling back to the flow-level options, so there's no point in having the question-specific ones. [1]: http://yaml.org/type/bool.html
This reverts commit bb6f7516a4491128029fb3f14b74e513f2ed5784.
floehopper
force-pushed
the
always-use-explicit-question-specific-options-in-i18n-yaml
branch
from
d31b386 to
c623582
Compare
|
I've rebased this against master and force-pushed in preparation for merging. |
floehopper
added a commit
that referenced
this pull request
Oct 14, 2015
…pecific-options-in-i18n-yaml Always use explicit question specific options in i18n YAML
floehopper
deleted the
always-use-explicit-question-specific-options-in-i18n-yaml
branch
floehopper
added a commit
that referenced
this pull request
Oct 15, 2015
This has been a problem since #2005, but it only came to light after a production deployment. Checkbox questions have an implicit 'none' response if the user doesn't select any of the checkboxes. `CheckboxQuestionPresenter#response_labels` translates the options for display in the 'Previous answers' section at the bottom of the page. When the translation fallbacks were removed in #2005, a `I18n::MissingTranslationData` was being raised when the user did not select any checkboxes. Unfortunately, this commit [1] added a translation for the 'none' option even though the `CheckboxSampleFlow` [2] didn't have an explicit `:none` option. Note also that the `assert_page_has_content` was changed to check for 'None' instead of 'none'. In this commit, I've removed the translation for the 'none' option which gave me a failing test which replicated the problem we'd seen in production. I've fixed the failing test by adding an `if/else` statement to `CheckboxQuestionPresenter#response_labels` which effectively reintroduces the translation fallback in this very specific case. I'm not totally happy with this solution, but hopefully it'll do for now. [1]: f50ec82 [2]: https://github.com/alphagov/smart-answers/blob/master/test/fixtures/smart_answer_flows/checkbox-sample.rb
floehopper
added a commit
that referenced
this pull request
Oct 18, 2015
This flow was relying on the fallback to the option key which was removed in #2005. The following exception has just occurred in production [1]: I18n::MissingTranslationData: translation missing: en-GB.flow.part-year-profit-tax-credits.have_you_stopped_trading?.options.yes This commit adds unit tests which would've picked up the problem and adds the missing translations. [1]: https://errbit.publishing.service.gov.uk/apps/533c35ae0da1159384044f5f/problems/56233f4b6578634c6c971600
floehopper
added a commit
that referenced
this pull request
Oct 18, 2015
This flow was relying on the fallback to the option key which was removed in #2005. The following exception has just occurred in production [1]: I18n::MissingTranslationData: translation missing: en-GB.flow.part-year-profit-tax-credits.have_you_stopped_trading?.options.yes This commit adds unit tests which would've picked up the problem and adds the missing translations. [1]: https://errbit.publishing.service.gov.uk/apps/533c35ae0da1159384044f5f/problems/56233f4b6578634c6c971600
floehopper
added a commit
that referenced
this pull request
Nov 12, 2015
Since #2005, flow-level options are no longer used as a fallback, so we can safely remove these.
floehopper
added a commit
that referenced
this pull request
Nov 13, 2015
Since #2005, flow-level options are no longer used as a fallback, so we can safely remove these.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously if an option for a question was not specified at the question-level in the YAML file, the code would first fallback to flow-level options and, failing that, to the string version of the option key.
The first fallback seems to have been used to DRY up the YAML files, but I think the way it works is a bit surprising and definitely confusing in places e.g. when some options are defined at the question level, but others are defined at the flow level. The reduction in duplication is minimal and I think there are probably better ways to DRY up the code (if it's even a good idea).
The second fallback is hardly used and strikes me as being a bit dangerous. Where it's done intentionally, it leaks presentation details into non-presentation code. And where it's done accidentally (i.e. because someone forgot to define the option text), the page will render without error, but probably with unexpected option text.
I seems a lot better and simpler to require that all question options are defined explicitly at the question level and if one is not then to fail fast with an exception. This PR makes that change and updates all the question option definitions accordingly.
Another advantage of this change is that it makes the content for each question more self-contained, which should make it easier if we decide to split the content for each question into its own file.
Although this includes a lot of commits, they are all small and many of the are very similar.
Expected user-visible changes