If you need to translate IIIF Content Search API 2.0 results, the challenge is not simply making a search box appear in another language. A useful multilingual IIIF search experience must connect words in a transcription, edition, caption or translation to the correct Annotation, Canvas region or moment in a recording. Searches for IIIF Content Search API 2.0 localization, multilingual OCR search, IIIF annotation search results and IIIF autocomplete translation are really questions about keeping that connection trustworthy.
A reader searching an old newspaper for a family name expects to reach the right page, not just receive a familiar-looking word. A student searching the translation of a speech expects the matching subtitle to lead to the relevant moment. A scholar looking for a historical place name needs to know whether the match came from the original printed text, a later transcription, a translation or a curator’s note. Search makes language navigable, but it can also hide important differences if the interface treats every text as equivalent.
This guide explains what IIIF Content Search API 2.0 actually searches, what its service descriptions and AnnotationPage responses mean, and how to localize query interfaces, hits, snippets and autocomplete responsibly. It stays focused on annotation-content retrieval rather than general catalogue search or the broader Manifest structure. The discussion includes practical examples, validation exercises, language-specific search problems and an explanation of why finding a word and proving that the word appears in the original source are different tasks.
Search is a promise to take the reader somewhere
The most useful way to understand content search is to imagine a reader’s action. They type a phrase, choose a result and expect the viewer to show the place where that phrase occurs. For a digitized book, the place may be a region of a Canvas corresponding to a line of print. For an oral-history recording, it may be a time in an audio Canvas. For an annotated artwork, it may be a piece of commentary linked to an image. The result matters because it leads back to evidence.
In a multilingual setting, the promise becomes more complicated. The words typed by the reader may not appear in the source language at all. A translated annotation might contain their query, while the original manuscript uses another expression. The interface should make that relationship clear. A match in a modern translation is still useful, but it is not a claim that the historical scribe wrote those target-language words.
Consider a French visitor searching for a term in an Arabic manuscript. The system may search French scholarly translations and return a corresponding Canvas. That is meaningful only if the hit indicates the translated text layer and the annotation’s target remains intact. Search quality depends on a chain of claims from query to text to location. A localized interface must preserve that chain.
What the Content Search API does and does not cover
IIIF Content Search API 2.0 specifies a way to search annotation content associated with an IIIF resource such as a Manifest, Canvas, Range or Collection. It is designed for text and other annotation content appearing around a displayed resource. It is not a general standard for searching every piece of descriptive catalogue metadata. This scope distinction prevents a common misunderstanding.
A museum website can have a site-wide catalogue search that looks through titles, creators and subject headings. It can also have a Content Search service inside a viewer that finds words in a scanned diary’s transcript. A user may call both ‘search’, yet their results have different meanings. The first finds objects; the second finds annotated content within the relevant IIIF scope. Localization should use interface language that tells people which kind of search they are operating.
A Manifest-level service can search annotations associated with the Manifest and its subordinate Canvases. A service attached to a particular Range narrows the available content to that section. This is valuable for a visitor exploring one chapter rather than the entire volume. The service’s attachment determines scope; translation of a label should not change that scope silently.
Search services must remain machine-readable
The Presentation resource declares a Content Search service through its service property. The service description uses an identifier for the endpoint and a fixed type, SearchService2. These fields tell a client which remote service to call. They are not strings for a translator to rephrase. Replacing SearchService2 with its translation would turn a readable word into an invalid protocol term.
A search request typically supplies a q parameter with the user-entered query. The exact matching semantics depend on the server and the documented options. A translator should not promise universal phrase matching, stemming or language recognition merely because a search field appears in several languages. Translating ‘Search this book’ in the user interface is straightforward; deciding how the back-end understands the words entered is a distinct retrieval problem.
Autocomplete can be advertised as a related service, using AutoCompleteService2 as its type. This is another part of the protocol, not a menu caption. The visitor sees suggestions; the client sees service descriptions and query parameters. Responsible localization addresses both without confusing their roles.
The result is an annotation, not a disconnected quotation
Search responses include AnnotationPages containing matching Annotations. Each result can carry a target that tells a viewer where to go. A text search hit might point to a Canvas region, a time interval or a related annotation. The returned text is valuable because it stays attached to that target. Without the target, a list of matching words becomes a detached concordance rather than a navigable reading experience.
An institution may be tempted to replace the returned text of a source-language Annotation with a target-language paraphrase. That can corrupt the evidence, especially when the same Annotation ID and target are retained. A better approach is to preserve the source content and, where available, associate a distinct translation or edition that visitors can identify. The search result can then state which textual stream produced the match.
For example, a word in an OCR layer can point to a rectangular region of a scanned page using a spatial fragment. That region should not move when the user interface language changes. The word displayed in a translated snippet may be different, but the basis for highlighting must be the content that actually matched. Translators can explain the relationship; they should not fabricate a visual occurrence of a word that is absent from the image.
A match is not the same as a highlighted span
A service may return a matching Annotation in an AnnotationPage and provide additional annotations that explain which exact portion of text matched. The specification uses motivations such as contextualizing and highlighting for these supporting annotations. TextQuoteSelector can identify an exact text span and surrounding prefix or suffix in a way that helps a client render the intended match.
This matters when a long line contains the same short word several times. Merely returning the line does not tell a viewer which occurrence to emphasize. It also matters when the displayed string is an inflected or plural form of the query. A highlighted span is a claim about a specific segment of underlying text, not just a decorative color in a search interface.
Localization introduces an additional challenge: the translated sentence may reorder words, so the character positions or quote selectors for the original text cannot automatically be reused for the translation. The correct target may remain the same Canvas, while the precise highlighted substring differs by textual layer. Reviewers should check each linguistic layer’s own selectors instead of copying source-language offsets.
OCR text has a different status from corrected transcription
Optical character recognition produces a machine-estimated reading of an image. In newspapers, manuscripts, faded type or ornate print, it can contain errors. Search can help users explore it, but an OCR hit is not proof that the underlying image definitely contains that exact word. A digitized page with a broken character may produce a plausible-looking but incorrect string.
A corrected transcription is another layer of interpretation. It may be more reliable, but it may also normalize spelling, expand abbreviations or resolve uncertain readings. A translation adds further editorial decisions. When a search result comes from one of these sources, the interface should make the source understandable. A user comparing a quotation with the scan needs to know whether they are seeing OCR, a diplomatic transcript or a translated edition.
Suppose an English OCR system reads the word ‘modern’ where the page actually says ‘modem’. If a multilingual index automatically treats the OCR output as authoritative, it may populate translated searches with a claim not supported by the image. Good systems allow correction and preserve the ability to inspect the page. Localization should not conceal uncertainty in the name of smooth browsing.
Search languages are not simply country settings
A collection in a Spanish-speaking institution may contain French, Latin, Arabic and indigenous-language records. Its user interface might be configured for Spanish, while its textual annotations are multilingual. The locale of the interface does not determine which language the annotations use. A search filter labelled ‘Spanish’ should reflect the actual indexed Spanish text or translations, not merely the visitor’s browser setting.
Language identification can be complex for short strings, historic spelling and mixed-script documents. Reviewers should not assume an automatic classifier is correct on every title, short caption or single line of handwritten text. When the record carries reliable language information, use that evidence. When it does not, represent uncertainty honestly rather than manufacturing precision.
A multilingual search system may offer a mode for each textual stream: original, transcription, translation or all available layers. Those are editorial interface choices beyond the API’s core vocabulary. They can dramatically improve clarity because a user knows what a result signifies. The best labels name the searchable content, not an imagined universal translation of every source object.
Different scripts change retrieval behavior
Arabic, Japanese, Chinese, Hindi, Russian and English do not have identical writing systems. Tokenization, punctuation, normalization, diacritics and word boundaries may vary. An English-oriented search engine that splits only on spaces may perform poorly on texts that do not mark words in the same way. This is not a failure of the translator’s phrase choice. It is a retrieval-design problem that becomes visible through localization.
Unicode normalization also deserves attention. Two visually similar strings may have different underlying code-point sequences. A system can choose a documented normalization policy, but it should avoid changes that merge distinctions important to the language or the source. Historical text adds further complexity: older orthography, ligatures, variants and scribal abbreviations can defeat simplistic matching rules.
The user-facing explanation should distinguish exact matches from flexible matches where that difference matters. If the system can search variant spellings, say so clearly. If it cannot, suggest useful forms without promising comprehensive recall. A user who fails to find a term should not automatically conclude the term is absent from the collection.
Query translation can improve recall and introduce false certainty
A common design idea is to translate every user query into several languages before searching. Sometimes this helps: a researcher entering an English modern place name may discover a German-language annotation. But automatic query expansion can also change the user’s meaning. One term may have several senses, and the historically relevant spelling may not equal a modern equivalent.
Consider ‘bank’ in an oral-history interview. The source may concern a river bank, a financial institution or a community savings group. Query expansion based only on the English string can create unrelated matches. A better interface may let the user inspect suggested translations or choose a sense. That extra moment of interpretation is useful; it protects the reader from believing an algorithm has found an exact equivalent.
In specialist domains, terminology varies by era and community. An old botanical name, an indigenous place name and a legal title each need different treatment. Query translation should therefore be a transparent retrieval aid, not a hidden rewrite of the original evidence. Record which query was submitted and which expansions contributed hits when that information is essential to research.
Search snippets are evidence excerpts, not marketing blurbs
A good snippet helps readers decide whether to open a hit. It should show enough context to reveal the word’s role and enough source information to prevent confusion. For an OCR result, the snippet may include neighboring words. For a transcript, it may include a sentence and speaker. For a translated edition, it should make the translation’s status evident. A result that looks elegant but conceals its origin is less useful to serious readers.
Snippet length changes across languages. A source-language phrase may translate into a much longer string, or one target-language word may contain more meaning than several source-language words. Do not simply reuse character counts as if they represented comparable semantic context. Design for legibility and a meaningful excerpt. A viewer may need to expand a line or show a larger context window.
The distinction between a matched term and its surrounding context is especially important in quotations. If an excerpt begins in the middle of a negation or omits a qualification, a reader may infer the opposite meaning. A search result does not need to reproduce an entire paragraph, but it should not distort the passage through selective clipping. Reviewers should test context-sensitive queries, not only isolated nouns.
Contextualizing and highlighting serve different needs
Contextualizing annotations help explain the matching content and its neighbors. Highlighting annotations help a viewer identify a precise occurrence. These jobs often appear together in user experience, but they are not interchangeable. A snippet can be accurate while the viewer highlights the wrong instance of a repeated term; a highlight can be precisely located while the excerpt omits a crucial word.
This distinction becomes clearer in multilingual documents. Imagine a Japanese transcription with an English translation. A user searches an English phrase and opens the translated passage. The correct English snippet may indicate the appropriate Canvas, but the original Japanese text cannot necessarily highlight a word-by-word equivalent. A careful viewer can navigate to the page and identify the translation’s matched span without pretending that the visual source uses English words.
Teams should test repeated words, punctuation at boundaries, line breaks and annotations that span large blocks of text. They should also check that contextualizing or highlighting Annotations are not mistaken for primary content. Preserving these relationships keeps the search result useful for close reading.
Pagination is part of the meaning of results
A long search can return several pages of matching Annotations. Pagination makes it possible to load them progressively and navigate through the result set. References to an AnnotationCollection can provide context such as the total number of matching annotations. A user interface should not imply that the first page contains every result.
A translator may need to localize strings such as ‘show more matches’, ‘results on this page’ or ‘next search results’. Those phrases should distinguish counts of matches from counts of documents or pages. Ten Annotation hits may all occur on one Canvas. A visitor should not be told that ten different books have been found if the actual result contains ten passages from the same book.
Changes to annotations or search indexing can alter pagination over time. A stable source resource ID remains the best long-term reference for scholarly citation. A numbered search-result position is not a robust substitute. Encourage users to cite the underlying item and location rather than the order in a transient list of search hits.
Autocomplete offers suggestions, not proof of relevance
AutoCompleteService2 supports suggestions for queries. These may be based on terms indexed in the relevant content or another documented source. A response can include terms, counts and display labels. A user should understand that a suggestion is a possible search, not evidence that a desired historical concept appears in the original document.
The difference matters for translations. An English label might make a suggested term understandable, while the actual query value could be a source-language term or structured identifier. The display label and search value do not need to be identical. This allows a system to offer multilingual guidance without breaking the query required by its search service.
Test suggestions against real retrieval results. If a visitor selects an Arabic display term and the system submits a malformed query, autocomplete has not helped. If counts refer to the wrong source or include unsupported languages, the interface may mislead users. Suggestions need their own review, distinct from search result snippets and result navigation.
Filters, ignored parameters and transparent limitations
Content Search API 2.0 provides several query options, and implementations can differ in which they support. The specification includes a way for a response to name parameters the server ignored. This is important because a client should not quietly claim that a filter worked when the server did not apply it. A multilingual user interface should not promise a narrower result set than the service actually returned.
Imagine a visitor filters to annotations made by a particular contributor. If that parameter is ignored and results from all contributors appear, an unqualified ‘filtered results’ heading would be misleading. The problem is not linguistic fluency but operational truth. The interface should communicate that the requested restriction was unavailable and invite the user to refine or interpret the search accordingly.
Filtering by motivation, date or other supported dimensions can also affect how snippets are interpreted. A tagging annotation is not the same as a transcription. Translators should choose labels that make these differences visible. Good localization tells the user what the service did, not only what they asked it to do.
Worked example: searching an old newspaper across two languages
A national library has digitized a century of newspapers. The page images are served through IIIF Canvases; OCR text is attached in Annotations. A later project adds corrected transcripts and English translations for a small selection of articles. A researcher searches for a historic occupation that has changed names over time.
The search interface should distinguish whether the hit came from OCR, corrected text or an English translation. If an OCR line points to a region of the page, selecting the result should navigate to that region. If an English translation contains a modern profession name, that match should not be presented as an original printed phrase. Both results are valuable, but they answer different questions.
A useful test starts with one known article and searches an exact spelling, a variant and a translated concept. Reviewers compare the hit counts, snippets and destination regions. They also inspect one false OCR match to see whether readers can verify it against the page image. The goal is not merely more results. It is better evidence navigation.
Worked example: a manuscript with uncertain letters
A university archive has a handwritten letter with an erased word. The diplomatic transcription marks the uncertainty, while an edited transcription supplies a tentative reading. A translated English version chooses a likely meaning but mentions the uncertainty in an annotation note. The same Canvas therefore supports several textual perspectives.
If an English-language search finds the translated phrase, the viewer should navigate to the appropriate Canvas or region and identify the translation layer. It should not display the tentative word as if it were unquestionably visible in the original ink. A context snippet can carry the editorial qualifier, and a reader should be able to inspect the manuscript image.
The most revealing QA query uses a word that appears only in the edited reading, not the diplomatic transcription. Does the result state its layer? Is a direct citation to the Canvas possible? Is the uncertain status still discoverable? This example shows how search can improve scholarship while preserving the distinction between observation and interpretation.
Worked example: a multilingual oral-history recording
An archive records a conversation in which several speakers alternate between two languages. One Annotation layer contains time-aligned original-language transcripts; another contains translated captions. Visitors may search either language. A query result must point to the correct interval and, ideally, make the speaker or stream apparent.
The problem becomes visible when the translation groups two short utterances into one sentence. An English phrase may correspond to a broader interval than a particular source-language word. Reusing the original word’s exact highlight timing could be misleading. The viewer may need to navigate to the translated segment while showing the relevant context without claiming perfect word-level alignment.
Reviewers should play the destination clip, inspect the first and last words, verify speaker names and test silence or overlapping speech. A result that points a few seconds late can defeat the visitor’s purpose even when the translation is beautifully written. Time is part of the source reference.
Worked example: searching a bilingual exhibition catalogue
A gallery publishes exhibition texts and object commentary through Annotations. A visitor types the name of a technique, while another visitor searches the name of an artist in a different script. The gallery wants the search interface to feel consistent across languages without making every query match every unrelated concept.
The technique term may have several accepted translations. A personal name may be transliterated differently in older catalogues. The search service can offer documented variant handling or autocomplete suggestions, but it should avoid silently merging unrelated people or techniques. Authority information can help guide the display, though that is not the same as inventing a universal equivalence in the index.
A practical test uses known objects and disputed spellings. For each query, reviewers ask which textual layer matched, whether the result jumps to the intended Canvas and whether the snippet preserves important qualifiers. Useful multilingual search is measured by the reader’s ability to understand and verify the returned evidence.
Worked example: captions for a documentary film
A documentary archive offers original subtitles and several translations aligned to a time-based IIIF resource. A user searches an English phrase about a major event. The result directs them to the translated subtitle; the source language uses a different phrase structure. Correctness requires preserving the time reference and making the language stream visible.
A common mistake is to copy the original subtitle’s matching character offsets into the translation. Word order and length differ, so the viewer may highlight the wrong text. Another mistake is to return the entire film as a hit with no useful timestamp. Both errors reduce the practical value of multilingual retrieval. Annotation targets and appropriate selectors should be reviewed for the intended layer.
Reviewers should choose a sentence near a cut or speaker change. Search, open the hit and listen. Does the sentence play at the right moment? Is the surrounding dialogue present? Does the visible snippet match the subtitle stream the user searched? When these questions are answered, the service acts as a trustworthy navigation tool.
Worked example: a scientific notebook with historical terms
A science museum has digitized specimen records made over a hundred years. OCR recognizes the printed forms, while curators have added notes about taxonomic revisions and modern place names. A student searches for the current name of an organism that once appeared under an obsolete classification.
The search may return curatorial annotations even when the original notebook uses only the historical term. That is useful as long as the interface distinguishes the annotation’s author and date from the historical observation. Otherwise the student might believe the original collector used terminology introduced later. Search snippets can preserve this distinction with source labels and contextual text.
A strong review uses queries for the old and new terms. The team compares destinations, the actual page image, and the modern explanatory annotation. Search should let the student bridge two vocabularies without erasing the historical difference between them. That is an educational benefit no simple ‘replace all terms’ strategy can provide.
Worked example: searching without a reliable language tag
A local heritage group publishes a collection of community-written captions. Some captions mix languages within a sentence and some use nonstandard spelling. An automated index marks every entry with the repository’s default locale, producing apparently precise but inaccurate language filters. Readers begin to miss relevant results when selecting their language.
The better response is not to force certainty. Reviewers can identify the dominant language where evidence is sufficient, document mixed-language cases and design a search mode that does not falsely exclude material. Suggestions can guide variant spellings while readers retain access to the original caption. Where the content is uncertain, a small note may be more honest than a strict automatic category.
This case highlights a structural truth about multilingual access: searching a collection is a way of asking questions of evidence, not a guarantee that the evidence conforms to neat language boundaries. Interfaces should help people explore that complexity rather than conceal it.
Worked example: a crowded page and repeated terms
A scanned dictionary page contains the same headword many times, perhaps in example sentences and cross-references. A user searches the headword and the search service returns an Annotation spanning a long paragraph. A viewer highlights the first occurrence even though the result intended the last one. The snippet seems plausible, so the problem can escape casual inspection.
The remedy is to check the association between matching annotations, contextualizing or highlighting annotations, and the selector specifying the exact occurrence. The client needs enough information to locate the match, not merely to render a colored box. This is especially important with language variants that change punctuation and word order.
Reviewers should test repeated occurrences deliberately. They should compare the first, middle and final hit on a crowded Canvas, and verify that selecting one does not jump to an unrelated occurrence. Precision at this level determines whether search can support close reading rather than casual browsing alone.
Worked example: a search that returns no results
A visitor searches a historical place name and sees ‘No results’. That sentence may be translated perfectly, yet its meaning remains ambiguous. The name might be absent from the indexed annotations, present only in a different script, spelled differently, contained in an unindexed scanned page or hidden by a filter the service did not support.
A more helpful interface can explain the searched scope and offer alternatives without pretending that a result exists. It may suggest variant spelling, removal of restrictions, selection of another textual stream or inspection of the source object. The difference is between ‘no match within this search’ and ‘the concept does not appear anywhere’. The first is supportable; the second often is not.
Reviewers should test zero-result messages in every target language. They should make sure the interface does not imply that the object has been exhaustively searched when only a subset of annotations was indexed. A well-translated limitation is part of a trustworthy search experience.
How to assess multilingual search quality
Start with a small set of known annotations across several content types: printed pages, handwritten material, subtitles and curator notes. For each, record a source-language term, a target-language equivalent or explanation, the expected textual layer, the Annotation ID and the Canvas region or time target. This becomes a meaningful set of reading tasks rather than an arbitrary vocabulary test.
Then test search scope. Does a Canvas-level service find only relevant material? Does a Range-level service restrict itself appropriately? Does a Manifest-level service expose the intended annotation streams? Check responses and ignored parameters before interpreting missing results. Test the service’s actual behavior rather than relying on a UI promise.
Finally, evaluate the user experience. Inspect snippets, highlighting, paging, autocomplete and zero-result messages. Ask a reader to open a hit and explain whether the word was in the original, a transcript, a translation or an annotation. When that explanation is accurate, the interface is helping readers understand evidence instead of merely making multilingual text appear.
Search quality and search completeness are different
A search may return relevant hits near the top while still missing many relevant passages. Another may return almost every possible match but overwhelm users with unrelated material. Linguistic changes affect both precision and recall. Stemming, transliteration, spelling variants and machine translation can widen search, but each can also change what counts as a match.
Evaluators should therefore compare known positive examples with known negative ones. A search for a named individual should not pull in unrelated people with similar spellings. A search for a concept translated from an older language may need to recognize several historical terms. Neither challenge is solved simply by increasing the number of supported interface languages.
It is useful to tell readers what a search covers: the text stream, language, portion of the item and major exclusions. An honest scope statement can be more valuable than a large result count. The service becomes trustworthy when people know what question it has actually answered.
Common errors to avoid
Do not translate protocol vocabulary such as SearchService2 or AutoCompleteService2. Do not remove an Annotation target when editing a snippet. Do not claim that a translated phrase occurs in the original image merely because an editorial translation matched. Do not reuse character-level highlights across languages without checking alignment. Do not confuse site-wide catalogue discovery with annotation-content search.
Avoid implying that autocomplete proves relevance, that ignored filters were applied, or that no results means the concept is absent from the source. Be cautious about punctuation, diacritics, non-Latin scripts and historically variable spellings. Take the time to test what a reader sees after clicking a search hit, since that moment is where the whole retrieval chain is tested.
Most important, do not make the interface sound more certain than the underlying data. OCR, transcription, translation and commentary each have different relationships to an original object. Clear language can help visitors appreciate those differences. It should not erase them.
Frequently asked questions
Does IIIF Content Search API 2.0 search a whole museum catalogue?
Its principal purpose is to search annotation content within an IIIF resource scope. General catalogue discovery can use other systems. Some interfaces combine them, but the distinction should remain clear to users.
Can a search match translated text?
Yes, when a translation is represented as searchable annotation content and the service indexes it. The resulting hit should make the text layer and target clear. A translation match is not proof that the source image contains the target-language words.
Why does a result need a Canvas target?
The target connects the text to the relevant visual or temporal location. Without an appropriate target, the result may be readable but cannot reliably take the visitor to the original evidence.
What is the difference between a snippet and a highlight?
A snippet supplies surrounding text for interpretation. A highlight identifies a matching passage or occurrence. One may be correct while the other is wrong, so both need review.
Is OCR reliable enough to search?
OCR is extremely useful, but its accuracy varies with print quality, handwriting, language and image conditions. Good search design lets readers inspect the scan and understand that machine text can contain errors.
Must autocomplete use the same word as the display label?
Not always. The display label can help a visitor understand a suggestion while the underlying query value follows the search service’s requirements. The relationship must remain correct when the user selects it.
Why can two languages return different numbers of results?
Available annotations, translation coverage, tokenization, spelling, morphology and index behavior can differ. Different result counts do not automatically prove a bug; they do require a clear explanation of scope and quality.
What is the most useful first test?
Choose a known phrase with a precise Canvas location. Search in the intended language, open the hit, verify the displayed text layer and inspect the original source. Then repeat with a spelling variant or translated equivalent.
A better measure of success
A multilingual search service succeeds when a visitor can move from a question to the correct evidence and understand the relationship between the query, the text that matched and the original object. This involves language, but also annotations, target references, timing, scope and honest labels for different kinds of text.
Search should make the record more accessible without making the record seem simpler or more certain than it is. When a reader can find a translated idea, inspect the original passage, see the right highlight and identify the editorial layer, the technology is doing exactly what a good educational tool should do: opening a path to understanding that remains verifiable.
Sources and further reading
International Image Interoperability Framework, Content Search API 2.0: https://iiif.io/api/search/2.0/
International Image Interoperability Framework, Presentation API 3.0: https://iiif.io/api/presentation/3.0/
W3C, Web Annotation Data Model: https://www.w3.org/TR/annotation-model/
Related eduKateSG guide, IIIF Presentation API 3.0: https://edukatesg.com/2026/10/30/translate-like-a-pro-3490-iiif-presentation-api-30-manifests-canvases-ranges-language-maps/
Related eduKateSG guide, IIIF Image API 3.0: https://edukatesg.com/2026/10/30/translate-like-a-pro-3480-iiif-image-api-3-info-json-regions-tiles-rights/