@redsift/products 12.5.16-alpha.1 → 12.6.1

package/_internal/SignalCardSpfDomain.js

@@ -598,6 +598,8 @@ var EXTRACTOR_STRINGS = {
     "investigate:card.dmarc.summary-domain-quarantine-partial-sp-weak": "The domain only quarantines {pct}% of unauthorized email, and subdomains use a weaker policy, leaving them vulnerable to spoofing.",
     // Summary box strings for email compliance results
     "investigate:card.dmarc.summary-email-pass": "The email is DMARC compliant. It passed both DKIM and SPF.",
+    "investigate:card.dmarc.summary-email-pass-dkim-only": "The email is DMARC compliant. DKIM passed, but SPF did not.",
+    "investigate:card.dmarc.summary-email-pass-spf-only": "The email is DMARC compliant. SPF passed, but DKIM did not.",
     "investigate:card.dmarc.summary-email-fail-both": "The email is not DMARC compliant. Neither DKIM nor SPF passed.",
     "investigate:card.dmarc.summary-email-fail-dkim": "The email is not DMARC compliant. DKIM did not pass.",
     "investigate:card.dmarc.summary-email-fail-spf": "The email is not DMARC compliant. SPF did not pass.",
@@ -1086,6 +1088,8 @@ var EXTRACTOR_STRINGS = {
     "investigate:card.dmarc.summary-domain-quarantine-partial-sp-weak": "Le domaine ne met en quarantaine que {pct} % des e-mails non autoris\xE9s, et les sous-domaines utilisent une politique plus faible, les rendant vuln\xE9rables \xE0 l'usurpation.",
     // Summary box strings for email compliance results
     "investigate:card.dmarc.summary-email-pass": "L'e-mail est conforme \xE0 DMARC. Il a pass\xE9 \xE0 la fois DKIM et SPF.",
+    "investigate:card.dmarc.summary-email-pass-dkim-only": "L'e-mail est conforme \xE0 DMARC. DKIM a pass\xE9, mais pas SPF.",
+    "investigate:card.dmarc.summary-email-pass-spf-only": "L'e-mail est conforme \xE0 DMARC. SPF a pass\xE9, mais pas DKIM.",
     "investigate:card.dmarc.summary-email-fail-both": "L'e-mail n'est pas conforme \xE0 DMARC. Ni DKIM ni SPF n'ont pass\xE9.",
     "investigate:card.dmarc.summary-email-fail-dkim": "L'e-mail n'est pas conforme \xE0 DMARC. DKIM n'a pas pass\xE9.",
     "investigate:card.dmarc.summary-email-fail-spf": "L'e-mail n'est pas conforme \xE0 DMARC. SPF n'a pas pass\xE9.",
@@ -2700,18 +2704,65 @@ var frFR = {
 };
 
 /**
- * Add the 'investigate.' namespace prefix to all extractor string keys
- * so they align with the DS translation key convention.
+ * Merging `@redsift/signal-logic`'s extractor strings into the DS signal-card catalogue.
+ *
+ * Pure (no JSON or package imports) so the `yarn verify:intl-drift` check can run the exact merge
+ * the runtime uses, rather than a re-implementation that could agree with itself while the real
+ * one is broken.
  */
-function prefixKeys(strings) {
-  const result = {};
-  for (const [key, value] of Object.entries(strings)) {
-    result[`investigate.${key}`] = value;
+
+/** A translation value, mirroring `ExtractorStringValue` from `@redsift/signal-logic/i18n`. */
+
+/** The DS catalogue namespace every signal-card key lives under. */
+const NAMESPACE = 'investigate';
+
+/** Upstream's colon form of the same namespace, e.g. `investigate:extracted-email`. */
+const UPSTREAM_NAMESPACE = `${NAMESPACE}:`;
+
+/**
+ * The catalogue key an upstream extractor-string key is stored under.
+ *
+ * Upstream keys come in two forms: namespace-less (`card.amp.spf-passed_md`) and colon-namespaced
+ * (`investigate:card.spf.passed_md`). `useSignalCardTranslation` maps `t('investigate:foo')` to
+ * `investigate.foo`, so a colon-namespaced key must drop its namespace before the dot prefix is
+ * added. Prefixing it as-is (DS-116) stored it under `investigate.investigate:foo`, which nothing
+ * ever looks up, so the key rendered as its own name.
+ */
+function toCatalogueKey(upstreamKey) {
+  const key = upstreamKey.startsWith(UPSTREAM_NAMESPACE) ? upstreamKey.slice(UPSTREAM_NAMESPACE.length) : upstreamKey;
+  return `${NAMESPACE}.${key}`;
+}
+
+/**
+ * Merge upstream extractor strings over one locale's DS JSON.
+ *
+ * Upstream wins where both sides carry a key: signal-logic is the source of truth for these
+ * strings, and the DS JSON is only a mirror of them.
+ *
+ * Upstream can carry the same key in both forms (`investigate:extracted-dns-short` and bare
+ * `extracted-dns-short`), sometimes with different copy. Upstream resolves them as distinct keys,
+ * but here both land on `investigate.extracted-dns-short`, so one must win. The colon-namespaced
+ * form does, whatever order upstream lists them in: it is the key callers ask for by name with
+ * `t('investigate:…')`.
+ */
+function mergeCatalogue(dsStrings, upstreamStrings) {
+  // `T` is left unconstrained: the DS JSON is not only strings (`glossary.label.*.link_UNKNOWN` is
+  // a boolean), and it passes through untouched.
+  const merged = _objectSpread2({}, dsStrings);
+  const entries = Object.entries(upstreamStrings);
+  const isNamespaced = _ref => {
+    let [key] = _ref;
+    return key.startsWith(UPSTREAM_NAMESPACE);
+  };
+  for (const [key, value] of [...entries.filter(e => !isNamespaced(e)), ...entries.filter(isNamespaced)]) {
+    merged[toCatalogueKey(key)] = value;
   }
-  return result;
+  return merged;
 }
-const mergedEnUS = _objectSpread2(_objectSpread2({}, enUS), prefixKeys(EXTRACTOR_STRINGS['en-US']));
-const mergedFrFR = _objectSpread2(_objectSpread2({}, frFR), prefixKeys(EXTRACTOR_STRINGS['fr-FR']));
+
+/* istanbul ignore file */
+const mergedEnUS = mergeCatalogue(enUS, EXTRACTOR_STRINGS['en-US']);
+const mergedFrFR = mergeCatalogue(frFR, EXTRACTOR_STRINGS['fr-FR']);
 var intlMessages = {
   'en-US': mergedEnUS,
   'fr-FR': mergedFrFR