Back to all checks

Text quality

Text stored in an inconsistent form — Shopify catalog

Finds text that looks the same but is stored using different character combinations and can be made consistent.

Needs your reviewAbout this check

What does catalog text not normalized to unicode nfc check?

Unicode permits canonically equivalent representations: an accented character can exist as one precomposed code point or as a base letter followed by a combining mark.

NFC composes characters where defined and provides a stable canonical form for comparison; two strings can render identically before their internal difference is noticed.

NFD performs canonical decomposition, while NFKC and NFKD also apply compatibility mappings. PROVEN does not substitute NFKC for NFC because compatibility normalization can remove intentional distinctions.

Examples that require context

These are fictional educational examples. They illustrate situations where review is useful and do not represent real merchant data.

Example A — canonically equivalent Unicode representation that differs from NFC[correction candidate after review]

The case illustrates a possible pattern; verify NFC versus NFD, distinction from NFKC, and byte-level comparison before any change.

Example B — legitimate context for catalog text not normalized to unicode nfcPreserve when intent is confirmed

The same class of character can have a legitimate role. NFC is canonical normalization; the detector does not substitute NFKC or treat compatibility normalization as equivalent.

Example C — value without this findingPreserve the value

Absence of this issue does not prove overall text quality; other detectors remain independent.

01

What does PROVEN check?

Checks text that does not use the canonical normalized form for character combinations.

02

Why does it matter?

Two values can look identical while being stored differently and compared as distinct text.

Why can this matter for catalog maintenance?

The condition can arise from typing on different systems, copy/paste, macOS-originated data, transliteration, language processing, or merging sources with different normalization policies.

Byte-level comparison, hashes, deduplication, and external keys may see distinct values even when a font renders them alike, so the check concerns code-point sequences rather than glyph appearance.

NFC normalization does not correct spelling, add missing diacritics, or repair U+FFFD. It preserves canonical equivalence and remains separate from semantic remediation.

03

What can PROVEN do?

PROVEN can prepare normalization to the canonical form; the change requires your review.

How PROVEN handles the finding

The workflow preserves evidence and separates detection from the remediation decision to avoid speculative normalization.

  1. Locate the evidencePROVEN locates canonically equivalent Unicode representation that differs from NFC and preserves surrounding characters so the merchant can review position and effect.
  2. Check the semanticsThe merchant verifies NFC versus NFD, distinction from NFKC, and byte-level comparison. Context determines whether the finding is residue, a valid convention, or a case that should remain unchanged.
  3. Prepare the changeOnly after confirmation can PROVEN prepare a targeted edit. The proposal preserves unrelated text and remains reviewable before application.

What should be reviewed before application?

Before apply, confirm the normalized value remains canonically equivalent and that compatibility normalization is not being used to transform symbols, ligatures, or meaningful formatting.

For identifiers or external integrations, even canonically equivalent rewriting can alter hashes or signatures, so those fields require coordination with the data consumer.

Post-normalization testing can compare `value === value.normalize("NFC")`, inspect code-point length, and exercise systems that use the value as a key.

Limits and abstention cases

  • The intended benefit is representational consistency and predictable comparison, without promising automatic SEO, ranking, traffic, or commercial outcomes.
  • It does not ignore context: NFC versus NFD, distinction from NFKC, and byte-level comparison must be checked before remediation.
  • NFC is canonical normalization; the detector does not substitute NFKC or treat compatibility normalization as equivalent.
  • The result should be interpreted in the context of the field and product; a finding is not an automatic verdict.
  • It does not invent copy, missing characters, data provenance, or merchant intent.
  • It does not guarantee SEO, ranking, traffic, or conversion benefits after remediation.

Frequently asked questions

Is catalog text not normalized to unicode nfc always an error?

No. NFC is canonical normalization; the detector does not substitute NFKC or treat compatibility normalization as equivalent. The finding identifies a review case, and the decision depends on field, language, format, and evidence.

Does PROVEN apply the change automatically?

Not from the finding alone. This check requires review, and the proposal must be checked before application.

Is this an official Shopify limit?

No. Shopify sources provide content-editing context; the exact criterion remains PROVEN detector-specific.

Why are Unicode sources used?

They provide context about text representation and processing and help interpret the finding.

Sources and independent context

The sources explain the relevant standard or content editor. They provide context for interpretation but do not by themselves show that a store has this finding.