Conversation
zoracon
commented
Dec 18, 2018
zoracon
commented
- For better user clarity for when they request un-encrypted requests
- In reference to the conversation had in Rebrand "Block all unencrypted requests" feature #16985
- New UX is under development from UX Audit and Recommendations #16669, but this can be a quick fix for the release tomorrow
- For better user clarity for when they request unencrypted requests
|
This will make it so that previous translations of "Block all unecrypted requests" will now be the translation for "Encrypt All Sites Eligible." Is this the desired behavior? We may want to change the localization string variable name too, since this will clear the existing translations for this variable. Then again, since doing a release tomorrow, that will leave very little time and probably all non-English languages will have this string untranslated for the next release. Maybe immediately after release, we can switch the underlying variable name. That'll give us a lot of runway for that to be translated properly. |
| <!ENTITY https-everywhere.menu.observatory "SSL Observatory Preferences"> | ||
| <!ENTITY https-everywhere.menu.globalEnable "Enable HTTPS Everywhere"> | ||
| <!ENTITY https-everywhere.menu.blockUnencryptedRequests "Block all unencrypted requests"> | ||
| <!ENTITY https-everywhere.menu.blockUnencryptedRequests "Encrypt All Sites Eligible"> |
There was a problem hiding this comment.
I might also add " (EASE)" to this, to make it easy (no pun intended) to refer to.
I can go ahead and change that variable name. As far as the translation issue, should I change the language just in the frontend to avoid problems? Is there a way to send a directive to help "re-translate" this line I can send out prior to merging in? |
- Looks like reversion failed, removing
- ugh
3 participants
