-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
List breaches #2917
List breaches #2917
Conversation
Fixes linting issue in 84a4f62.
dda5803
to
6451c7e
Compare
locales/en/app.ftl
Outdated
@@ -79,6 +79,9 @@ compromised-accounts = Compromised accounts: | |||
# compromised-data = the kind of user data exposed to hackers in data breach. | |||
compromised-data = Compromised data: | |||
|
|||
# the kind of user data exposed to hackers in data breach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move these strings under the v2 section, together with the ones that are actually used? It might be worth checking with @toufali was his plans were.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes -- if you come across old strings that will be carried over, or add new strings it would be great to add/move them to the V2 section. Cleanup time is right around the corner and this will make our lives easier!
Going one step further, maybe all these strings should live in their own file, since this is a separate page and not pertinent to general site-wide strings, which I associate app.ftl with? all-breaches.ftl
or similar? cc @flodolo since moving strings to another file is not insignificant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved them to the V2 section in 068b0e7.
I was hesitant about moving them to a new file already, since I'm not sure if that will need alignment with the Pontoon folks, so I left that for now.
locales/en/app.ftl
Outdated
@@ -400,7 +404,8 @@ fb-comp-and-others = | |||
no-other-breaches-found = No other breaches found from a basic search. | |||
|
|||
no-results-blurb = Sorry, that breach is not in our database. | |||
all-breaches-headline = All breaches in { -product-name } | |||
all-breaches-headline-2 = All breaches detected by { -product-name } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all-breaches-headline-2 = All breaches detected by { -product-name } | |
all-breaches-headline-2 = All breaches detected by { -brand-fx-monitor } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job getting this together in rapid fashion! I noted one blocker and a few other things that are less block-y, but somewhat important to me 😊
locales/en/app.ftl
Outdated
@@ -79,6 +79,9 @@ compromised-accounts = Compromised accounts: | |||
# compromised-data = the kind of user data exposed to hackers in data breach. | |||
compromised-data = Compromised data: | |||
|
|||
# the kind of user data exposed to hackers in data breach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes -- if you come across old strings that will be carried over, or add new strings it would be great to add/move them to the V2 section. Cleanup time is right around the corner and this will make our lives easier!
Going one step further, maybe all these strings should live in their own file, since this is a separate page and not pertinent to general site-wide strings, which I associate app.ftl with? all-breaches.ftl
or similar? cc @flodolo since moving strings to another file is not insignificant.
src/client/css/global.css
Outdated
@media (max-width: 480px) { | ||
body > header menu a:not(.button) { | ||
display: none; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The app is set with a site-wide .mobile
class that we might use here, instead of a media query:
@media (max-width: 480px) { | |
body > header menu a:not(.button) { | |
display: none; | |
} | |
} | |
.mobile body > header menu a:not(.button) { | |
display: none; | |
} |
But going a step further, can we just do without the header "Breaches" link altogether?
- it's not in the UX design and looks out-of-place to me
- it seems redundant/confusing on the all-breaches index page since it just loads self
Assuming this is done to help a user back to the index after following a direct search link to a details page, it might be more intuitive to have a button (or two) on all details pages that reads something like "Go back to view all breaches" or just "View all breaches". Maybe one on top and one at the bottom?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update, I posed this question to UX in Slack, thanks to urgent prodding by @pdehaan
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per UX I removed the header "All Breaches" link – it was also a fast-solve for the user-menu bug 🙌
f1bdd6d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we use the same file naming convention as the other files in the folder, and mirror the other related files in views/partials/
and client/js/partials/
? i.e. this would become all-breaches.css
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot of indirection going on, so it's a bit hard to follow, but if I understand it correctly, we automatically load CSS files whose file name, minus .css
, matches the name of the function rendering the partial, so we can't use dashes there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you're right, and there's a bit of work I need to do to make this clearer. Unsurprisingly this will also likely land with code-splitting! I updated to better conform with existing naming conventions here: ffdcec9
With code-splitting, part of the task will be to use camelCase, so you were ahead of schedule 🚀
Partially reverts 89beb67.
They might also need to be moved to different files, but that might need coordination with Pontoon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strings look good, please tag me again if there's new content
OK, content should be final now @flodolo, with some strings changed in 7ccc4ac. That also removes the distinction between US and non-US strings for the VPN recommendation, as per Slack. |
locales/en/app.ftl
Outdated
header-nav-all-breaches = All breaches | ||
footer-nav-all-breaches = All breaches |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why same string twice? Would the header and footer ever need to be translated differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As is often the resolution between the 3 of us, let's just remove the header link altogether and pretend this never happened?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: I removed the header link per UX, so this is non-issue. f1bdd6d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a recommendation from the l10n team (or at least Peiying) to not re-use strings. It's hardly an issue for localisers, since Pontoon will suggest the same translation, but different contexts might lead to different translations (or e.g. just changes in capitalisation) in some locales, so using different strings accommodates that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Footer/Header is an edge case, but in general it's better to have different strings for different contexts.
@@ -61,6 +62,7 @@ const guestLayout = data => ` | |||
<img src='/images/moz-logo-1color-white-rgb-01.svg' width='100' height='29' loading='lazy' alt='${getMessage('mozilla')}'> | |||
</a> | |||
<menu> | |||
<li><a href='/breaches'>${getMessage('footer-nav-all-breaches')}</a></li> | |||
<li><a href='https://support.mozilla.org/kb/firefox-monitor-faq' target='_blank'>FAQ</a></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: Does FAQ
need to be translated?
git grep -n ">FAQ<" src | cat
src/views/guestLayout.js:76: <li><a href='https://support.mozilla.org/kb/firefox-monitor-faq' target='_blank'>FAQ</a></li>
src/views/mainLayout.js:110: <li><a href='https://support.mozilla.org/kb/firefox-monitor-faq' target='_blank'>FAQ</a></li>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, just noticed this while grepping for a different PR on utm_*
parameters:
git grep -n "https://support.mozilla.org/kb/firefox-monitor-faq" src | cat
src/views/emails/email-2022.js:10: faq: 'https://support.mozilla.org/kb/firefox-monitor-faq',
src/views/guestLayout.js:76: <li><a href='https://support.mozilla.org/kb/firefox-monitor-faq' target='_blank'>FAQ</a></li>
src/views/mainLayout.js:105: <li><a href='https://support.mozilla.org/kb/firefox-monitor-faq' target='_blank'>FAQ</a></li>
src/views/partials/landing.js:70: <a href='https://support.mozilla.org/kb/firefox-monitor-faq' target='_blank'>${getMessage('see-all-faq')}</a>
Where see-all-faq
string is:
git grep -n "see-all-faq" locales/en/ | cat
locales/en/landing.ftl:40:see-all-faq = See all FAQs
So looks like "FAQ" is hardcoded 2× and uses localized "See all FAQs" elsewhere.
Not necessarily a bug, but just something to confirm possibly.
But maybe that makes sense since they are used in the landing page vs footer:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh hm good catch, I'm not sure if we generally translate FAQ but I think it's a reasonable thing to do? Since this landed in 54ad4b6 and not the current PR would you mind filing a ticket for this? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(it should be translated, yes)
Co-authored-by: Peter deHaan <pdehaan@hey.com>
…ozilla/blurts-server into MNTOR-1343-breach-page-styling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rush-pushed a bunch of stuff to get this over the finish line -- comments should be inline. Thanks for the team effort! 🎉
YOLO |
References:
Jira: MNTOR-1343 and MNTOR-1344
Figma: https://www.figma.com/file/4Cw0BfI1iqu0HzGkxPmsdU/Breach-Detail-Page?node-id=1-5385&t=ulhnif4UYxXluY85-4
Description
@rhelmer Most of the changes here are yours - I'm not sure if there were final touches you wanted to do, but if so, feel free to create a PR with just your changes, and I'll rebase on that.
This adds back the breach overview and breach details page to the refresh. Note that I did not add the background image on the overview - see this Figma comment.
Screenshot (if applicable)
How to test
Click the "Breaches" link in the header or footer. Search of a breached company, then click the card.
Checklist (Definition of Done)