Fix email change confirmation

[raulrpearson]

Fixes #170.

The PR also includes an update of the translation files; I wanted to tweak the email change confirmation email and noticed all these unrelated changes, so decided to split into two different commits.

Gettext went a bit too far with the fuzzy matching so the new "Confirm email change" will appear as "Apstiprināt e-pastu" in Latvian, which was originally translating "Confirm email". It's now less accurate but I suppose better than no translation at all. Maybe something to refine in a future PR.

Feel free to merge or let me know if you'd like me to change anything about the PR.

[raulrpearson]

@alxlion, one potential problem with the current email change flow is that a user might open the link in a browser where they don't have a session open, so they'd be prompted to sign in. This will only work with the old email, as the email change is still not confirmed, which might create some confusion.

We could modify the confirmation flow with a view that only takes the password (and the one time token in the search param), to avoid the user having to guess or get confused about which email to use. Maybe we could merge this current PR as is and add this to the backlog as a further improvement.

[alxlion]

@alxlion, one potential problem with the current email change flow is that a user might open the link in a browser where they don't have a session open, so they'd be prompted to sign in. This will only work with the old email, as the email change is still not confirmed, which might create some confusion.

So, the problem is that the confirmation page is guarded by an authentication plug? Sure, this could confuse the user.

We could modify the confirmation flow with a view that only takes the password (and the one time token in the search param)

Do you think a simple unauthenticated page with the token in the url is enough for this use case ?

[raulrpearson]

Do you think a simple unauthenticated page with the token in the url is enough for this use case ?

No, definitely authenticated. Otherwise, let's say you make a mistake when submitting the new email address, someone else gets the email and now that person would be able to take control of your account unless you issue a second change request and beat them to the confirmation (I tried to issue two changes in a row, to different emails and the first to be confirmed gets done, the second one gets an expired flash message). It's a bit of an edge case, but worth taking into account, I think.

So visiting the confirmation link with an active session should be part of the flow, I think that's not a problem, but visiting the link without an active session should prompt for authentication with just the password, so users don't get confused/frustrated not being sure if they need to sign in with the old email or the new one (I did not find this confusing myself, but a chat with a friend surfaced this as a potential issue).

IMO, we can merge this PR as it already represents an improvement over sending the confirmation to the old email. After that, we can open up a PR to improve the flow to only ask for the password (not the email) when visiting the confirmation URL without an active session.

I can amend right in this PR if you prefer to get it done in one go, but I'll likely only be able to revisit this by next weekend.

[alxlion]

OK, I understand. I'll create a separate issue for this case.

I let you format your code to make the CI pass (use either ./dev.sh format or mix format).

Thanks! 😉

[raulrpearson]

I let you format your code to make the CI pass (use either ./dev.sh format or mix format).

Done! Sorry for that, my editor might not be formatting on save 🤔