Excluding WPML translation sets cut a duplicate-image scan from hundreds of groups to 29

The first heuristic was filenames. The developer expected duplicates to look like photo.jpg and photo-1.jpg. That pattern covers some of them and misses most ^[17]. On their own site the same dashboard screenshot existed under three names, uploaded in July, August and September by three different people, with three different titles and three different alt texts, and nothing in the WordPress admin connects them ^[16]. So identity comes from the contents of the file ^[20].

A fingerprint answers a narrower question than the feature needs. WPML Media Translation, Polylang's media translation and Bogo each create one attachment per language pointing at the same physical file ^[4]. The bytes match, so the fingerprints match ^[4]. Delete one of those copies and the Spanish version of the page loses its image ^[5].

Identity therefore takes a second input: which attachments belong to the same translation set. Each plugin keeps that link somewhere queryable, WPML in its own table, Polylang in a hidden taxonomy, Bogo in a post meta, and the whole map loads in one query per request instead of one call per image ^[8]. On this library that is one query in place of 3,099 lookups ^[2]. With the map loaded, a group of identical files collapses to one entry per set, and a group that shrinks to a single entry is no longer a group ^[9]. The fix is "a rule, not a hack: a translation set is one image", the author wrote ^[7]. The alt audit inherits the same rule: an alt counts as duplicated only when it sits on two genuinely distinct images ^[10].

The exclusion is per plugin. Weglot, GTranslate and TranslatePress translate on the fly and never create a second attachment, WPGlobus keeps every language in one post, and MultilingualPress runs one site per language ^[11]. Three link stores need reading, and five products need declaring out of scope in the documentation ^[4].

Which bytes to hash is its own decision. Since WordPress 5.3 a large upload is scaled down and the attachment points at the scaled file while the original stays on disk ^[13]. Two uploads of the same photo usually produce identical scaled files, but a site that changed image library between the two uploads gets different bytes, so the fingerprint is taken from the original whenever WordPress kept one ^[13]. The stored value also goes stale: scaling, optimisers, the built-in editor, replacement plugins and thumbnail regeneration all rewrite the file behind an attachment, and all of them finish by saving the attachment metadata ^[14]. That save is where the recompute goes ^[14]. Resized and re-encoded variants stay out of scope, because exact copies are the only ones the plugin can act on with confidence ^[15].

Thirty deletable files in a 3,099-image library is about one percent ^[1]. The attachments with no file on disk outnumber them by roughly eight to one ^[3]. The scan had filed those under "still waiting" ^[18]. They now have their own tab, listing the expected path and the page each attachment is used on ^[19].