How People Translate Quickly | COUNTER 5.1.1 Library Usage Translation QA: Explain Reports Without Changing Metric Definitions

To translate COUNTER 5.1.1 library usage reports quickly, localize the explanations, dashboard labels, column-help text and decision guidance while preserving the report identifiers, metric tokens, filters, periods and underlying counts exactly. A librarian comparing digital resources needs more than familiar words: the translated display must continue to distinguish total requests from unique requests, searches from investigations, and the access conditions that produced a number. Begin with a canonical report, define a translation mapping for human readers, and reconcile every displayed figure against its source.

COUNTER Release 5.1.1 is the current Code of Practice, published on 30 June 2026. It standardizes usage reports so libraries can compare online resources more credibly. The code defines report families, standard views, metric types, filters, attributes and a delivery API. These are data contracts, not paragraphs to rewrite. A translation that changes a machine token or silently merges unlike metrics can make a library appear to have gained or lost usage even though its provider reported exactly the same activity.

This guide follows a fictional school and public-library consortium preparing English and Malay usage dashboards for acquisition meetings. The workflow covers a preserved source report, a safe localization layer, explicit examples, arithmetic checks, error diagnosis, a changed-context exercise and an approval checklist. It does not purport to certify a provider’s COUNTER compliance: that requires the appropriate standard-based validation and audit. It teaches how to translate the reader-facing explanation without damaging the evidence that supports spending and access decisions.

Begin with the decision a librarian needs to make

Imagine two electronic journal collections. The first costs less but attracts many repeated item requests; the second costs more and serves a smaller set of distinct reading sessions. A library officer asks whether the subscription is still worthwhile. If a dashboard translates both Total_Item_Requests and Unique_Item_Requests as the same general phrase for downloads, the officer loses a distinction needed to interpret the comparison. A translation error therefore affects budget evidence rather than merely the visual appearance of an interface.

Write the job in one sentence: the reader must identify the correct period, institution, resource, access conditions and metric before drawing a conclusion about value. Acceptance requires both comprehension and fidelity. A bilingual reviewer should be able to read the Malay interface and recover the original COUNTER report identifier, filter settings and source figures. If the display hides a necessary distinction, a reassuring but vague translation has not met the task.

Identify the correct Code of Practice release

A report can resemble COUNTER data while belonging to an older release or a custom vendor format. Before creating terminology, inspect the report’s declared release, report ID and metadata. Release 5.1.1 was published on 30 June 2026 and is the currently documented 5.1 Code of Practice. Avoid treating the number as merely a design version. Some rule and reporting details differ between Release 5 and Release 5.1, so a glossary built for an earlier report should not be assumed valid for a newer file without a version comparison.

Store the exact source release in the job ledger alongside the provider name, platform, reporting period and retrieval timestamp. In the current 5.1.1 code documentation, standard report header examples still show the Release value as 5.1; do not mechanically replace the schema release with the patch revision 5.1.1. Keep the code revision and actual report release as separate provenance fields when necessary. The localized explanatory prose may say that the data follow COUNTER 5.1.1, but this sentence must be earned by actual source metadata and relevant conformity evidence. If the provider supplies Release 5.1 reports under an earlier patch-level revision, explain that honestly rather than silently altering the release field. An editor cannot upgrade data by changing its description.

Separate four different surfaces in a reporting workflow

First comes the source COUNTER report, potentially provided as JSON or a tabular export. Second comes the ingestion layer that reads identifiers, metrics, dates and filters. Third comes the presentation model, which assigns human-readable descriptions to fields and values. Fourth comes the displayed dashboard, spreadsheet or PDF delivered to readers. Translation should ordinarily operate in the third and fourth layers, not in the source report or parsing contract.

This separation makes defects easier to isolate. If a Malay label is missing but the numeric query remains correct, repair the presentation mapping. If the underlying query has accidentally excluded a month, rewriting the explanatory sentence will not restore the data. Keep a copy of the original report and the transformation version for every release. A localization test that checks only what appears in a screenshot can miss a wrong filter upstream; a parser test that checks only schema validity can miss a misleading Malay caption downstream.

Read the report families as different analytical questions

COUNTER 5.1 defines four principal report families: PR for Platform Report, DR for Database Report, TR for Title Report and IR for Item Report. Their machine identifiers should remain unchanged in stored data and technical exports. Translate their visible descriptions according to the intended audience: a platform-level overview is not the same question as requests for individual journal articles. A dashboard that collapses all four into a generic usage report label deprives the reader of the aggregation level.

When building navigation, show the canonical code alongside the translated name at least where analysts need to compare outputs across systems. A user selecting TR should know they are looking at title-level grouping rather than a complete list of every article. The context may justify a short help tooltip or definition rather than a longer menu label. Test whether librarians can answer the question of what a row represents before they compare any quantities. Accurate aggregation is part of the translation’s meaning.

Respect the difference between master reports and standard views

A master report offers configurable filters and attributes; a standard view presets choices for a particular reader task. The standard view ID, such as PR_P1 for platform usage, is not decorative text. It identifies an intended configuration whose meaning depends on the Code of Practice. Translating a view name is useful, but replacing its ID with a local nickname in a machine export destroys a traceable way to recognize the preset.

A translated dashboard should explain the filters that define a standard view. A title-level request view may not include every item, search event or access-denied event that another report can show. If two views differ in their filters, do not place their totals side by side with an unqualified heading inviting a false comparison. Include the source view ID, selected metric types and period in the explanatory panel. Where the interface supports custom views, mark custom selections separately from standardized presets.

Protect metric tokens as controlled data

COUNTER metric tokens such as Total_Item_Requests, Unique_Item_Requests, Total_Item_Investigations and Unique_Item_Investigations should remain intact in files and API interactions. They carry defined measurement meaning. A localized label can explain a token in plain language, but it cannot redefine what event is counted. A glossary should store the canonical token, a target-language label, a precise definition, permitted contexts and a reviewer who understands collection statistics.

Keep translation mappings explicitly one-to-one where a distinction matters. A vague target phrase for all four metrics may be shorter, but it makes a comparison impossible. Conversely, a phrase implying that each request is made by a unique human visitor is likely wrong: unique-item metrics use specific session-and-item counting principles rather than proving unique persons. Explain the scope of uniqueness in the help text. Test an analyst’s interpretation with concrete examples before approving a short label for daily use.

Explain total item requests without inventing people

A total item request represents a recorded request for full content within the applicable COUNTER processing rules. It should not automatically be called a unique download, a unique student, or a confirmed complete reading. A patron may access the same article more than once, and a platform may serve content through more than one format. The standardized counting rules are designed to reduce distortions, but the event is still a usage event rather than a verified educational outcome.

A careful display pairs a translated phrase meaning total item requests with a brief definition visible on demand. When a teacher sees 120 requests for a journal, they should not conclude that 120 different students read it. A pie chart title that silently says people reached would make that unsupported inference even if the source value is untouched. The narrative translation must be held to the same discipline as the numbers: say what the metric establishes, and also what it cannot establish.

Explain unique item requests within their session rule

Unique item requests reduce repeat counting according to the COUNTER item and session rules. They are not an estimate of unique people across a year and should not be presented as such. The Code of Practice describes an item as the recognizable unit of content, such as an article or chapter, independent of delivery format. A student who opens HTML and PDF versions of the same article may interact with more than one technical representation without necessarily representing two distinct content items.

For translation QA, ask a bilingual reviewer to distinguish a sentence saying an item was requested in a session from a sentence saying one patron requested it. These statements are not interchangeable. The localized dashboard should avoid unqualified labels such as individual users unless the data actually support that claim. Where a graph compares total and unique requests, add explanatory text about repeated activity and verify that the values come from equivalent time ranges and report filters.

Separate investigations from full-content requests

An investigation concerns access to a content item or information about it under the applicable COUNTER definition; a request concerns delivery or viewing of the full content. A reader viewing a record or abstract can contribute to an investigation without necessarily obtaining the whole article. A translation that calls both downloads could inflate the perceived amount of substantive reading. For a school library deciding whether discovery tools work well, the difference may be as meaningful as the count itself.

Use an example to check the glossary. A parent searches a database, reads the metadata of an article and leaves without opening its full text. A reviewer must not describe that experience as a confirmed full-text request. Translate the metric definitions first, then choose concise screen labels that retain the distinction. If the target language forces an awkward short label, supply a nearby description rather than suppressing the concept. Accuracy can coexist with a compact interface when supplementary help is well designed.

Distinguish searching from reading

Database reports may include search metrics such as Searches_Regular and other defined search categories. A search activity does not directly mean that an article was accessed, and a result list is not equivalent to a successful full-text request. When a dashboard shows a database with many searches but relatively few requests, librarians may investigate discovery quality, access barriers or collection fit. They should not interpret the search count as the number of documents read.

A localized help panel should identify what the search metric actually represents, its relevant report and how it was collected. The exact permitted search categories and host types must be checked against the current specification rather than inferred from everyday vocabulary. Do not turn a search metric into an engagement score or assign it educational value without separate evidence. A transparent translation enables interpretation; it does not invent causal explanations for observed usage patterns.

Keep access-denied outcomes distinct from successful requests

COUNTER reporting can describe access denied because a license is unavailable or a limit has been exceeded. Defined values such as No_License and Limit_Exceeded are not synonyms for a user choosing not to read. They capture different possible barriers, and they may support different decisions about subscriptions or simultaneous-user capacity. If both are translated into a generic error label, the acquiring librarian loses the information needed to respond appropriately.

A dashboard should make the difference visible. For example, an access-denied count due to a concurrent-user limit might lead to a capacity review, while a lack of licensing could lead to a different negotiation. However, do not translate the metric name into an assertion that a particular institution has a particular contract without verifying that the report applies to that institution and period. The machine code stays stable; the explanatory text should clarify the conditional meaning and avoid speculating beyond the evidence.

Protect the access-type category and its platform context

Release 5.1 uses access-type values including Controlled, Open and Free_To_Read in applicable reports. These are controlled classifications of how an item was accessible on the reporting platform. They do not automatically describe a publisher’s entire rights policy, the reader’s legal reuse permission or a separate platform hosting the same work. Translating Open as universally free for all purposes would overstate the data and could misinform an acquisitions committee.

Document the glossary for access types with a note that the classification is contextual to the platform and activity. When an item appears open on one platform and controlled on another, the difference may be legitimate rather than a data error. Compare like with like before aggregating. If a graph uses access type as a filter, show the active selection and whether excluded categories are hidden. A user should never infer that a filtered number describes all access simply because the chart title omits the restriction.

Keep access method and text-and-data mining visible

COUNTER uses access-method classifications such as Regular and TDM, where TDM concerns text and data mining activity. Some standard views preset regular access. A translation that describes a filtered figure as all usage can mislead researchers whose automated analysis contributes to a different category. Neither label should be treated as a casual adjective; each has a defined processing role that affects what is included in the report.

When translating a dashboard toggle, preserve the underlying selection and record which values enter a calculation. A bilingual analyst must be able to verify the same inclusion rules regardless of the interface language. If the source provider did not report a particular access method, do not create a zero row merely to make the table symmetrical unless the applicable reporting rules actually justify that interpretation. The proper display may be absence or an explicit unavailable-data warning, not an invented count.

Preserve year-of-publication distinctions

Title and item reports can use a year-of-publication attribute, often abbreviated YOP. A library examining older journal collections may use it to see whether backfile content receives attention. The year is a structured field, not an invitation to translate numerals into a different arbitrary notation that a downstream parser cannot interpret. A report may also use special representations for unknown or in-press years under the specification. A dashboard should explain those cases rather than silently interpreting them as ordinary historic publication years.

A useful localized chart labels the year clearly and distinguishes publication year from usage month. These dates answer different questions: one says when the content was published, the other says when activity occurred. A translation that merges them into one date concept can make a backfile analysis nonsensical. Include the reporting period in the graph caption and preserve the canonical year values in exported data. A student reading old material in 2026 does not make the article a 2026 publication.

Treat the reporting period as a reproducible filter

Every usage chart should carry an explicit reporting period. Monthly data spanning a year cannot be compared fairly with three months of activity unless the difference is acknowledged. Store the requested beginning and ending dates and the reporting provider’s applicable period convention. Translate surrounding month names or explanatory phrases as needed, but do not change the machine dates, their ordering or their coverage. An attractive localized chart with the wrong period can lead directly to a poor renewal decision.

Test a boundary case around the transition from December to January. The Malay interface must not flip the years or omit a month when it formats a date range. Check whether the export uses month-level intervals and whether the dashboard rolls them up in the same way as the source. If a report was retrieved later than the activity period, keep that retrieval timestamp separate. The date of data collection, the date of content publication and the date on which a chart was generated are three different facts.

Build a translation map instead of editing source JSON

Use a small translation map where each machine token is a key and each human label is a value. For example, the source token Total_Item_Requests can point to an approved explanatory Malay label, while Unique_Item_Requests points to a distinct label. The source metric tokens remain stable. Version the mapping separately from the report so a revised wording can be deployed without rewriting historical usage counts or replaying ingestion pipelines.

Do not assume that every JSON string is presentation text. A report may contain identifier fields, machine-readable categories, institution names, publisher-provided resource titles and human messages with different ownership rules. Classify the fields before translating. The application can render an approved label while retaining the original source value in an audit detail or download. This separation also allows a bilingual view in which a reviewer can compare target wording to canonical codes without navigating two unrelated reports.

Work a small JSON presentation example

The following JSON is an illustrative dashboard view model, not a COUNTER 5.1.1 report, API response or validation specimen. It shows how an application can preserve a canonical metric token and count while changing only the displayed label. The synthetic example deliberately separates source identity from presentation so a reviewer can parse the sample without mistaking the localized text for a new metric name.

{
  "code_of_practice_revision": "5.1.1",
  "source_report_release": "5.1",
  "source_report_id": "TR",
  "reporting_period": {"begin": "2026-01", "end": "2026-03"},
  "source_metric_type": "Total_Item_Requests",
  "metric_count": 120,
  "display_locale": "ms",
  "display_label": "Jumlah permintaan item",
  "is_synthetic_view_model": true
}

A parser can check that the numeric value is 120 and that the canonical metric token has not changed. The label is an example to be reviewed by a qualified translator and library professional; it is not an officially sanctioned COUNTER translation. The source report’s actual structure is more detailed and must be validated against the correct schema. The important lesson is ownership: a localized view is allowed to say what a metric means, but it should not impersonate a report produced by the original provider.

Use arithmetic only after checking metric comparability

A dashboard can compute differences, proportions or cost-per-use indicators, but only after confirming that the underlying measures are suitable for comparison. It is tempting to divide a subscription price by total requests and call the result cost per reader. That is usually an unsupported interpretation: requests are not necessarily distinct people, may be influenced by repeated activity and are subject to the report’s filters and collection rules. If the calculation is included, name it in terms of the metric actually used.

Create a computation ledger that records inputs, their units, source report IDs, filters, period and rounding decisions. Test the calculation in both languages and ensure translated decimal separators do not alter stored numeric values. If a user switches from total to unique requests, recompute and relabel the indicator, rather than merely changing a legend. A small difference between metrics can substantially change a procurement discussion. The QA question is whether a reader can reproduce the calculation from canonical source data, not whether the localized chart looks consistent.

Use reconciled totals rather than screenshot plausibility

Set up a test row with a known source count, a known period and an explicit filter combination. Record its canonical identifier and check that the exported localized dashboard displays the same number. Then test a second row with different access conditions, a zero value and a missing value. The distinction between zero and missing is important: zero means a measured value of none under relevant conditions, whereas missing can mean a report was not provided or was filtered out.

A screenshot cannot reveal whether a displayed total was joined to the wrong resource or drawn from the previous quarter. Compare source row keys and aggregation parameters programmatically where possible. For any discrepancy, log the original value, displayed value, expected interpretation, query or transformation version and responsible owner. A localized dashboard can be perfectly grammatical while using the wrong join. When that happens, fixing a label is not enough; the data pipeline must be reviewed and rechecked.

Make terminology review a joint technical and language task

Ask translators to propose clear target expressions, but include a librarian or usage-statistics analyst in approval. A word like investigation has an everyday sense that may differ from its COUNTER measurement definition. The technically correct translation may need a tooltip or explanatory clause to avoid suggesting a disciplinary inquiry or police investigation. A bilingual specialist can keep the prose natural, while the analyst ensures that each expression maps to the correct recorded activity.

Use glossary entries that include the metric code, source definition, intended label length, approved long explanation, examples of correct and incorrect interpretation, and the sign-off date. Version the glossary whenever the source Code of Practice changes or a substantial misunderstanding is discovered. Do not silently redefine an old label in archived reports without recording that the underlying metrics did not change. Consistent translation improves comparability only when the consistency is anchored in the actual measurement contract.

Review charts as arguments rather than decorations

A chart title often makes an implicit claim. A line graph labelled readership growth might be built from total item requests, which can increase because of repeated accesses rather than a larger audience. A translated title should reflect the measured variable and a defensible interpretation, not turn a broad marketing phrase into a stronger factual claim. Confirm what each axis shows, how totals were calculated and whether the legend omits filtered categories.

Test the display with long Malay and English labels, small screens and exported PDFs. A clipped legend can hide whether a curve represents searches or requests; a tooltip may disappear when the chart becomes a static image. Include a readable data table or accessible description where needed. Verify screen-reader order for headings, filters and values, and avoid using colour as the only distinction between metric types. A translated dashboard must remain interpretable when the visual presentation changes, not only when its author uses a large monitor.

Diagnose a false increase before translating its headline

Suppose an English dashboard announces a dramatic increase in journal use after a software migration. Before translating the headline into Malay, compare the new and old report periods, provider platforms, access methods, selected metrics, and release versions. The rise may be real, but it may also reflect a broadened filter or a switch from unique to total requests. Translating a confident headline without testing its evidence amplifies an analytical mistake. The translator should flag unsupported claims instead of treating them as immutable source facts.

Build a diagnostic table of candidate explanations, the data that would confirm each one, and the responsible reviewer. If different reporting systems aggregate different institutions, do not compensate by changing the text to say all schools when only some are represented. Correct the data or narrow the claim. When the comparison remains uncertain, use a cautious explanatory note that describes the difference in observed counts without asserting a cause. The translation team can protect readers by making the scope explicit, even when it cannot determine the origin of the variance.

Diagnose a seemingly empty report

An empty translated dashboard can mean no recorded usage, a selected filter with no matching rows, a failed API request, an unreported metric, an expired authorization or a rendering defect. These conditions require different remedies. A blank table should not automatically be labelled no one used the collection. Read the raw provider response, its metadata and any exceptions before choosing a human-facing explanation. The status of the data pipeline must be distinguished from the observed activity itself.

For one test, set a period known to contain usage and retrieve the report directly from the provider. Check the same report ID and filters used by the localized dashboard. If the canonical report has data but the local display does not, inspect transformation mappings and field names. If the provider returned an exception, preserve its technical code and translate the plain-language explanation without inventing successful delivery. If the period genuinely has zero counts under a supported metric, label that fact precisely. An honest unavailable state is a useful result, not a translation failure.

Keep API collection separate from language presentation

The COUNTER API, formerly called SUSHI, supports machine-to-machine retrieval of usage reports. It is not a translation engine. A report harvester uses defined report paths, identifiers, request parameters and response conventions. Changing API keys or metric names to translated phrases can make a perfectly good source unreachable. Localize the librarian’s interface for choosing reports and reading results while keeping network requests and schema values faithful to the official API contract.

Test retrieval in two layers. First establish that the harvester can request a canonical report and that the received response passes applicable structural checks. Then test that the translated interface shows the correct provider, dates, filters and metric descriptions. Never hide a failed response behind a previously cached chart without signalling the stale state. If a colleague uses a downloadable JSON report for their own analysis, export the provider-compatible form rather than the localized view model unless the export is clearly labelled as a derived, non-COUNTER artifact.

Validate report structure and then examine semantics

COUNTER provides a validator for reports and API setups. It checks rule-based problems such as missing elements or impossible metric relationships. Run the appropriate tool on the exact source artifact when validating a provider’s data, and retain the result with the report version. Yet validation is not a substitute for asking whether the translation tells readers the truth. A JSON file can be structurally correct while a chart calls requests readers, or while a report period has been misstated in a caption.

Separate findings into structural, numerical, linguistic and contextual categories. Structural defects go to the provider or ingestion engineer; numerical mismatches go to the data analyst; terminology defects go to bilingual review; unsupported management claims go to the report owner. This routing prevents teams from fixing the wrong layer. After any correction, rerun the relevant tests and inspect the exported form, not just the editing screen. A complete acceptance record links each resolved defect to the artifact that actually changed.

Compare providers without implying perfect comparability

COUNTER aims for consistent reporting, but figures from different publishers and platforms still require contextual care. One database might be used for assignment reading, another for occasional reference, and a third for advanced research projects. A translated report that calls the largest number the best resource makes a value judgement unsupported by the metric alone. Collection relevance, course use, content quality, access conditions and cost can all matter alongside standardized counts.

Present cross-provider comparisons with the same metric type, compatible periods, relevant filters and an explanation of scope. If one vendor only offers a certain standard view for its host type, do not fabricate a missing view to make the dashboard symmetrical. Show unavailable where the evidence does not exist. A librarian may legitimately decide to retain a low-usage specialist database; that is a governance decision informed by COUNTER statistics, not a contradiction the translator should resolve through persuasive wording.

Preserve resource titles and institution identity deliberately

Publisher names, platform names, ISSNs, ISBNs, institutional identifiers and formal database titles are not all ordinary translatable prose. Some are exact-match keys used for joins or reconciliation. A translated dashboard can add a local explanation for a resource, but it should preserve a reference to the canonical identifier. Avoid translating a formal institution name into a colloquial equivalent that resembles a different entity, particularly in consortium reports where several schools have similar names.

Build a display rule per field: preserve a formal title when it serves as a citation or key, use an approved alternate name when the institution owns one, and translate surrounding explanatory language freely. Test a search and sorting interaction in each language. If two resources acquire identical short translated labels, disambiguate them with a publisher or identifier rather than merging their rows. Ownership of the official name is a distinct question from the clarity of the interface, and both must be respected.

Practice a changed-context transfer exercise

Transfer the method from journal usage to an e-book collection used by a teacher-training institution. The English dashboard shows 240 total item requests, 125 unique item requests and an access-type filter. A Malay reviewer proposes a heading meaning 240 teachers downloaded e-books. Another analyst says the acquisition report should combine these counts with a platform-wide search metric. Explain which claims are defensible, which machine fields remain protected, and which checks are required before the display can support a purchase recommendation.

Do not answer the exercise by translating the numbers into words. First identify the source report family, item granularity, metric definition, active filter and period; then ask whether the user category is supported by the data. A teacher-training institution may have students, faculty and external authorized users, and COUNTER request counts do not automatically identify their roles. The proposed heading asserts both unique people and occupational identity that the given measures cannot establish. The correct repair must improve the explanation without changing the observed source counts.

Transfer exercise answer and review reasoning

The defensible view states that the collection recorded 240 total item requests and 125 unique item requests for the specified period and filter, provided those numbers were genuinely supplied by compatible source reports. It does not claim 240 different teachers, 240 e-books or 240 completed downloads. Keep Total_Item_Requests, Unique_Item_Requests, source report ID, date range and access-type token unchanged. Give the two metrics separate Malay labels with definitions, and show the chosen access condition near the figures.

A platform-wide search metric answers a different question and should not simply be added to item request counts. If the institution wants a broader picture of discovery and content delivery, present separate measures with their report IDs and definitions. Before advising renewal, review cost, curricular value, licensing conditions and comparison periods alongside usage. Reconcile the localized values to the source, test the glossary with a librarian and obtain editorial approval. The better translation improves the decision’s evidence; it does not substitute a new narrative for the measurement system.

Make the release checklist a real decision gate

Before a bilingual dashboard is approved, the release owner should verify source version, report IDs, retrieval date, institution, platform, reporting period, filters, data completeness, metric tokens, displayed totals and approved translations. Verify that exported JSON remains canonical where promised, and that localized reports are clearly described as derived views. Recheck number formatting, accessible labels, sort order, missing-value states, tooltip definitions and mobile or printed layouts. Retain the glossary version and the reviewer decision next to the release artifact.

A failed source reconciliation must stop release even if the translation reads elegantly. A failed term-definition test must also stop release even when every count matches. If the underlying provider changes a report definition or a new COUNTER release is adopted, run a targeted re-review rather than assuming previous labels remain accurate forever. This checklist is not bureaucracy for its own sake: each item connects a machine contract, a human interpretation and a reproducible decision record.

Limits and the principle to carry forward

COUNTER statistics cannot establish individual learning, the quality of a research paper, the identity of every reader or the educational benefit of a resource by themselves. A localized dashboard should make such limits visible when someone is likely to infer more than the data show. Some publishers and host types legitimately provide different applicable reports; no single interface can demand unavailable metrics. Differences between published release requirements, provider implementation and local analytical choices require separate review.

The reliable shortcut is to preserve source data and translate the understanding layer. Protect report codes, metric values, dates and filters; make the language clearer where readers interpret them; then test the claims that the interface invites people to make. This gives librarians more useful evidence without pretending that words can convert requests into people or usage into outcomes. A fast translation process succeeds when the next analyst can reproduce the same answer from the same canonical report.

Frequently asked questions

Is COUNTER 5.1.1 the current reporting code in October 2026?

Yes. The official COUNTER documentation states that Release 5.1.1 was published on 30 June 2026 and is the current Code of Practice. Check the source release recorded in the actual report rather than assuming all providers have already changed their outputs.

May a translated dashboard replace `Total_Item_Requests` inside JSON?

Not in a COUNTER-compatible report or API field. Keep the canonical metric token and provide a separately maintained localized display label. A custom view model may include both fields but must not masquerade as the original COUNTER report.

Does `Unique_Item_Requests` count unique students?

No. It uses defined unique-item and session-related counting rules; it is not a verified headcount. The label and help text must avoid implying distinct people unless another defensible data source supports that claim.

How is an investigation different from a request?

An investigation covers access to content or information about an item under COUNTER rules, while a request concerns accessing full content. A localized glossary should retain the distinction instead of calling both downloads.

Do `PR`, `DR`, `TR` and `IR` mean the same level of detail?

No. They are different report families: platform, database, title and item. Keep their identifiers and explain the grouping level in the interface so viewers know what each row represents.

Can I sum search counts and requests to report total readers?

No. Searches and item requests represent different event types; neither establishes unique people. They can be shown as separate indicators with definitions, not casually added into an audience figure.

Is `Open` the same thing as unlimited reuse permission?

No. In COUNTER reporting it is an access-type classification on a particular platform. Copyright, licensing and permitted reuse require separate evidence and should not be inferred from an access-type label.

What is the COUNTER API’s role in translation?

The COUNTER API, formerly SUSHI, retrieves reports in a machine-readable way. It does not translate them. The interface and explanatory layer may be localized without changing the API’s recognized parameters and tokens.

Why might a chart be empty when the source report contains data?

Possible causes include filter mismatch, report-family mismatch, failed ingestion, changed field mappings or rendering errors. Compare the exact provider response and query selections before describing the state as zero usage.

Can a validator approve the accuracy of the Malay prose?

No. A report validator checks structural and rule-based data issues. A bilingual library specialist must separately review terminology, inferred claims and reader comprehension.