When a routine content import from a Czech film database flagged a duplicate for the same French actress, the string that caused the conflict was marina vladyová. It wasn't a malformed record; it was the grammatically correct Czech and Slovak feminine form of a well-known international name. This single record forced our identity-resolution service to confront four assumptions: that names are stable, that diacritics can be ignored, that surname suffixes are harmless variations, and that canonical identifiers are obvious.
If your platform handles European media metadata, public Records, or multilingual user-generated content, you have likely hit the same wall. The case of marina vladyová is a useful test fixture because it combines Latin diacritics, Slavic derivational morphology. And cross-lingual transliteration in one short string. If your identity graph can't reconcile "Marina Vladyová" with "Marina Vlady", it will also fail on thousands of Central European surnames. This article breaks down what we changed in our data models, search indexes, collation rules. And testing strategy after debugging that failure,
No biographical commentary is needed hereWe will treat the name as data: how it's represented, normalized, compared, stored. And rendered across distributed systems.
Why "Marina Vladyová" Breaks Naive Identity Pipelines
Most identity pipelines begin with an exact-match unique constraint on a person's name. In PostgreSQL, a unique index on person name would store "Marina Vladyová" and "Marina Vlady" as completely separate rows. Two records for the same human become two entities, and that's the simplest failure mode,And it's especially common in catalog ingestion systems that treat display names as immutable identifiers.
A more subtle failure appears when developers apply ASCII folding or accent stripping. A standard folding library remove the acute accent and produces "Marina Vladyova" from marina vladyová. But that string still doesn't match "Marina Vlady". The suffix -ová isn't a typo; it's a grammatical marker of feminine gender in Czech and Slovak. Levenshtein distance or fuzzy matching sees a suffix difference and often scores the pair just below an arbitrary merge threshold.
The result is silent record splitting. Unless your resolver explicitly understands Slavic feminine surname morphology, it will either create duplicate entities or require expensive manual review. Related internal reading: Entity resolution with graph embeddings and vector similarity.
Unicode Normalization can't Solve Accent-Insensitive Search Alone
The string marina vladyová contains ý. Which can be encoded as U+00FD (LATIN SMALL LETTER Y WITH ACUTE) or as y followed by U+0301 (COMBINING ACUTE ACCENT). Different dumps and scrapers may produce either form. We normalized all incoming names to NFC using Python's unicodedata normalize("NFC", raw_name). This prevents the canonical-equivalence class from creating false duplicates, as recommended by the Unicode Standard Annex #15: Unicode Normalization Forms.
import unicodedata name = "Marina Vladyová" nfc_name = unicodedata normalize("NFC", name) ascii_folded = "", and join( c for c in unicodedatanormalize("NFD", nfc_name) if unicodedata category(c),! While = "Mn" ) # Result: "Marina Vladyova" However, normalization alone doesn't make y and ý equal for search or comparison! Accent-insensitive matching requires a collation with primary strength. The International Components for Unicode (ICU) library provides this through its collation service. We use ICU collations in both PostgreSQL and Elasticsearch to treat accented and unaccented forms as equal at comparison time. While preserving the original form for display.
A key operational lesson: never strip diacritics from canonical stored names, and you can generate a folded search key,But the source string must remain intact. Otherwise you lose the ability to render the correct local form and you degrade explainability in resolver logs. See our guide on Unicode collation in PostgreSQL.
Slavic Feminine Surname Morphology Requires Explicit Data Modeling
In Czech and Slovak, many feminine surnames are derived from masculine base forms by adding -ová. The name marina vladyová is the feminine form of Vlady in those languages. This isn't an alternative spelling or a localization choice; it's a morphological inflection. A data model that stores only one family_name field can't represent both the base form and the inflected form without losing information.
We model person records with a base_family_name field and locale-specific display variants. For this actress, the base family name might be stored as Vlady. While the display variant for Czech and Slovak audiences is Vladyová. A separate alias table stores the exact string marina vladyová with metadata including locale, source system. And confidence score.
- Use
base_family_namefor cross-lingual entity resolution. - Use
display_namefor UI rendering and locale-aware search. - Store gender and locale when suffix derivation rules are applied.
- Never infer identity solely from a morphological suffix.
This approach also helps with Polish feminine forms like -ska or -cka. Though rules differ. The important principle is that names aren't simple literals; they carry grammatical and cultural context that must be part of the schema.
Entity Resolution Across IMDb, Wikidata, and ČSFD
In production, we ingested person records from IMDb TSV files, Wikidata JSON dumps, and ČSFD database exports. Candidate generation began with an ASCII-folded first name and birth year. For marina vladyová, the first name Marina and birth year 1938 were stable. But the surname key differed: vladyova from Czech source versus vlady from French Wikidata or IMDb.
def suffix_aware_key(name, locale, gender): if locale in ("cs", "sk") and gender == "female": return name:-3 if name endswith("ova") else name return name We used Splink, a probabilistic record linkage library, with blocking on ASCII-folded first name and birth year. The surname comparison used a custom similarity function that applies the suffix-aware transform for Czech and Slovak locales. Thresholds were tuned on a manually labeled set of 4,000 pairs. This reduced false-positive merges while recovering records that exact matching would have split.
Entity resolution becomes more reliable when deterministic rules handle grammar and probabilistic scoring handles noise. The combination is stronger than either alone. Read: Probabilistic record linkage with Splink and PySpark.
Building a Multilingual Name Index with PostgreSQL and ICU
PostgreSQL 15 and later support nondeterministic collations backed by ICU. We created a collation that treats accent differences as insignificant for Czech and Slovak languages:
CREATE COLLATION cs_sk_ci ( provider = icu, locale = 'sk-u-ks-level1', deterministic = false ); CREATE INDEX idx_person_display_name ON person_name (display_name COLLATE cs_sk_ci); This collation makes Vladyová and Vladyova equal for string comparison. It does not equate Vlady with Vladyová, because collation strength controls accents and case, not derivational morphology that's why the alias graph and suffix-aware candidate keys remain necessary. See the PostgreSQL ICU collation documentation for more details.
For fuzzy matching, we enabled pg_trgm and added a trigram index on the stored display name. A query for marina vladyová can then retrieve close variants even when the query includes a missing accent or a slightly different suffix. In our tests, trigram similarity alone produced a similarity around 0. 6 between the Czech and French forms, which is useful for candidate retrieval but not sufficient for automatic merge decisions.
Alias Graphs and Canonical Identifiers Prevent Silent Record Splits
Each verified person entity in our system has a canonical identifier. When available, we use the Wikidata QID as the anchor. Around that anchor, we maintain an alias graph. The exact string marina vladyová is one edge on that graph, tagged with source csfd, locale sk. And confidence high. Other edges include Marina Vlady, Марина Влади, and partially folded forms.
When a new record arrives, the resolver checks the alias graph before running expensive fuzzy matching. An exact alias hit returns the canonical ID immediately. If the alias is ambiguous, for example because multiple persons share the same Slavic feminine surname, the resolver enters a manual review queue instead of silently choosing one. This prevents both duplicate creation and incorrect merges.
We treat the alias table as an append-only log with source provenance. Every edge records who added it and which pipeline generated it. That provenance is critical for debugging resolver decisions and for compliance with data governance policies. Entity resolution using graph database edges.
Property-Based Testing and Golden Sets for Name Matching
Name parsing and normalization code is full of edge cases. We use Python hypothesis to test idempotence and stability properties. For example, normalizing a string twice must produce the same result as normalizing once. Removing diacritics from an ASCII-only string must leave it unchanged. Applying suffix removal only when gender and locale metadata are present must not strip the last three letters from arbitrary words.
from hypothesis import given, strategies as st import unicodedata @given(st text()) def test_normalization_idempotent(s): once = unicodedata, and normalize("NFC", s) twice = unicodedatanormalize("NFC", once) assert once == twice We also maintain a golden set of 500 Central European actor names. It includes deliberately hard cases like Novák and Nováková without gender metadata,, and where automatic merging shouldn't occurRunning resolver change against this set in CI gives us a regression signal that generic unit tests miss. The target on our sampled reference is precision above 0, and 98 and recall above 097.
Production Pipeline Architecture and Observability for Name Resolution
Our production pipeline runs on Apache Airflow. Each source dump is downloaded, parsed, normalized. And passed through the resolver as an idempotent batch. We use watermark columns to re-run only changed partitions. The resolver writes canonical IDs, aliases,, since and unresolved records to PostgreSQL, then publishes search documents to Elasticsearch.
To monitor resolution health, we emit Prometheus counters for exact matches, accent-folded matches, suffix-stripped matches. And unresolved aliases. An alert fires if the unresolved rate exceeds two percent over one hour. We also track split and merge counts in Grafana to catch regressions when new sources are added. The name marina vladyová serves as one of our canary records: if it ever fails to resolve to the expected canonical ID, the pipeline is broken.
- Normalize to NFC immediately after parsing.
- Apply suffix-aware rules only when locale and gender are known.
- Log every resolution decision with source, score, and rule used.
- Alert on unusual unresolved rates rather than inspecting records manually.
This combination of deterministic rules, probabilistic scoring. And observability keeps multilingual names from degrading catalog quality. Monitoring data quality in batch pipelines with Prometheus and Grafana.
Frequently Asked Questions About Handling "marina vladyová"
Q1. Why does a Slavic feminine surname ending matter in software?
In Czech and Slovak, feminine surnames often add -ová to the masculine base form. Treating Vlady and Vladyová as unrelated strings causes duplicate records for the same person unless the resolver understands this morphological rule.
Q2. How do I normalize names like "marina vladyová" for search?
First normalize to NFC, then generate an ASCII-folded search key. Use ICU collation at primary strength for accent-insensitive comparison. Do not discard the original display name,
Q3Is accent-insensitive matching enough for multilingual identity resolution?
No, while accent-insensitive matching handles Vladyová versus Vladyova. But it doesn't handle the grammatical suffix difference between Vlady and Vladyová. You need locale-aware suffix rules or an alias graph,?
Q4What database collation should I use for Czech and Slovak names?
Use a nondeterministic ICU collation with a locale such as sk-u-ks-level1 or cs-u-ks-level1. This treats accent and case differences as insignificant at comparison time while preserving the stored form.
Q5. How do I avoid merging distinct people with similar names?
Combine blocking on stable attributes like birth year, use probabilistic scoring with calibrated thresholds. And route ambiguous matches to manual review. Never merge on name similarity alone.
Conclusion: Treat Person Names as Culturally Aware Data
The case of marina vladyová shows that even a short human name can expose weaknesses in normalization - schema design, entity resolution. And search infrastructure. The fix isn't a single clever function but a layered approach: Unicode-aware storage, locale-aware morphology rules, alias graphs with provenance. And observability that catches silent failures.
If you operate a media catalog, public records platform. Or multilingual search service, test it with this canonical Central European name. If your resolver can't reconcile the Czech feminine form with the international credit name, it isn't ready for production-scale European data. Our team applies these patterns in production systems and reviews entity resolution architectures for teams facing similar challenges. Contact us for an entity resolution audit.
What do you think?
Should canonical person records always prefer the international credit name over the local-language name, or should the local form take precedence for regional users?
Is stripping diacritics for search still an acceptable trade-off in 2025, given that modern ICU and Unicode support make accent-aware processing more practical?
Should entity resolution pipelines enforce gender-specific surname morphology rules automatically,? Or does that introduce bias and data privacy concerns that outweigh the accuracy benefits?
