LG-459 Clean up localizations

[monfresh]

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

• For DB changes, check for missing indexes, check to see if the changes
  affect other apps (such as the dashboard), make sure the DB columns in the
  various environments are properly populated, coordinate with devops, plan
  migrations in separate steps.

• For route changes, make sure GET requests don't change state or result in
  destructive behavior. GET requests should only result in information being
  read, not written.

• For encryption changes, make sure it is compatible with data that was
  encrypted with the old code.

• For secrets changes, make sure to update the S3 secrets bucket with the
  new configs in all environments.

• Do not disable Rubocop or Reek offenses unless you are absolutely sure
  they are false positives. If you're not sure how to fix the offense, please
  ask a teammate.

• When reading data, write tests for nil values, empty strings,
  and invalid formats.

• When calling redirect_to in a controller, use _url, not _path.

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated.

[monfresh]

This PR is best reviewed one commit at a time. The first one sorts the keys in all files alphabetically (which has been the desired state for a while but hasn't been enforced) using i18n-tasks normalize. The second one removes unused localizations and only ignores specific ones that are actually used but that i18n-tasks thinks are unused.

To keep this PR small, I will follow up with a second PR that moves all the 2FA stuff from config/locales/devise into config/locales/two_factor_authentication.

[mryenq]

LGTM, do we want to elaborate in the comments on why we tell i18n-tasks to ignore certain keys? (For example because they're referenced as string values only in view models, or similar.)

In the context of preparing an automated process for translations, I wonder if there isn't a better way to manage the above that would eliminate this manual step and help the gem identify these. (Presumably it searches for translation method calls.)

[monfresh]

I can add a comment explaining why they are being ignored. Basically, the gem is not able to detect that localizations with dynamic keys are being used: https://github.com/glebm/i18n-tasks#dynamic-keys

We are ignoring them because they are indeed used, but the gem thinks they are not, and if we didn't ignore them, the spec that makes sure that we don't have any unused translations would fail.

[jmhooper]

For some of these dynamic ones, does it make sense to use a comment to ignore them in the code where they are used? Seems easier to remember to delete a comment in the code you're looking at than a config in a file you probably aren't.

[monfresh]

I took a closer look, and there are several entries that are actually unused so this list will get smaller. I will clean them up.

[monfresh]

Sure, I can try the magic comments.

[monfresh]

This is what the difference is:

Using magic comments, we have to specify every single occurrence, like this:

  # i18n-tasks-use t('forms.piv_cac_setup.certificate.bad_html')
  # i18n-tasks-use t('forms.piv_cac_setup.certificate.expired_html')
  # i18n-tasks-use t('forms.piv_cac_setup.certificate.invalid_html')
  # i18n-tasks-use t('forms.piv_cac_setup.certificate.none_html')
  # i18n-tasks-use t('forms.piv_cac_setup.certificate.revoked_html')
  # i18n-tasks-use t('forms.piv_cac_setup.certificate.unverified_html')
  # i18n-tasks-use t('forms.piv_cac_setup.piv_cac.already_associated_html')
  # i18n-tasks-use t('forms.piv_cac_setup.token.bad_html')
  # i18n-tasks-use t('forms.piv_cac_setup.token.invalid_html')
  # i18n-tasks-use t('forms.piv_cac_setup.token.missing_html')

versus a single line in the config

 - 'forms.piv_cac_setup.*'

Which one do y'all prefer?

Also, for some reason, the gem also can't see that error messages are used. Do we really want to add a magic comment for every single validation error message (40+)?

[jmhooper]

Ah, yeah that's gross. Maybe not for now. I wonder why the gem doesn't let you put the match string in the comments.

[monfresh]

@mryenq I added comments and removed some more unused entries here: f565158

[monfresh]

Thanks, @mryenq for the thumbs up. Could I get an official approval please, if everything looks good?

[mryenq]

Sure, I thought you and @jmhooper were still discussing so held off.

LGTM.

[jmhooper]

LGTM2