Introduction
A multilingual editorial team can receive a detection result without receiving the optional explanation it expected. That is a workflow problem to investigate, not evidence that the text is human-written. Before building a rule around explanations, separate three questions: does the service document detection support for the language, does its explanation feature cover that language, and does your chosen interface expose the relevant information?
This guide is documentation-based research, not a live API test. We reviewed Copyleaks’ AI Logic and supported-language documentation. The decision matrix and review checklist are our suggested editorial process, not provider response fields or an independently tested accuracy ranking. This article may contain affiliate links.
For authentication, sandbox requests and synchronous response parsing, use our Copyleaks text API guide. Here the specific question is whether an explanation-dependent review process works across your publishing languages.
Detection vs Explanation
The AI Logic feature page describes optional explanation data in a patterns object, including statistical and text-location information. It identifies English, Spanish, French, Portuguese, German and Italian as supported explanation languages and excludes source code files. These are descriptions of the feature, not evidence that its explanations independently establish authorship.
The supported-language reference lists broader detection coverage. It distinguishes language selection from explanation availability, including zh-CN and zh-TW for the Chinese variants. It also describes different outcomes for unsupported explanations: submit-endpoint scans can include ai-insights-lang-unsupported, while the synchronous text endpoint has no alerts and simply omits explanations. The reference says that omission of language enables automatic detection.
Those differences affect application design. Do not wait for an asynchronous-style alert in a synchronous response. Conversely, do not hide a documented unsupported-language alert just because your interface was designed around an explanation-enabled English example. The feature page and language reference should be read together.
The following matrix uses examples rather than reproducing the complete language list. It is an editorial routing proposal, not an API schema. Verify the current list before implementing a production eligibility rule.
| Example or condition | Documented capability distinction | Our suggested review route |
|---|---|---|
English prose (en) |
Detection and optional AI Logic support are listed | Review available output with writing provenance; do not treat an explanation as proof |
Simplified Chinese prose (zh-CN) |
Detection is listed, but AI Logic coverage does not include it | Offer detection-context review without promising explanations |
Traditional Chinese prose (zh-TW) |
The detection list uses its own Chinese variant code | Keep the variant explicit and provide a non-explanation-dependent route |
| Source code file | AI Logic is excluded | Do not promise explanation coverage; verify other required capabilities separately |
| Missing expected explanation | More than one configuration or processing issue is possible | Investigate availability, configuration and response validity before classifying the absence |
| Synchronous integration | Unsupported explanations do not produce scan alerts there | Handle absent optional data without inventing an alert or silently granting clearance |
An explanation is generated by the same provider whose result is being interpreted. It can offer useful context, but it is not a second independent witness. A workflow that treats it as corroboration from another source would overstate the evidence available to the editor.
Language Decision Checklist
Establish the publishing context first
Inventory the languages and content types your team actually handles. Distinguish a prose document from a source code file, and record mixed-language documents rather than forcing them into an assumed single-language category. The documentation reviewed here does not establish how every mixed-language or code-containing document will behave.
If a feature is essential to your service, make that dependency explicit in the product promise. A team can reasonably offer review without AI Logic explanations, but it should not advertise identical explanation coverage to every writer. Readers should know what the review will contain before a document is submitted.
Choose an eligibility rule without pretending to know more
Use current documented support to decide whether an explanation-dependent route is eligible. Keep a separate route for cases where detection is listed but explanations are not. The local route labels should describe the process, such as “review without explanation,” rather than a conclusion about the author’s conduct.
For example, imagine an editorial service that publishes English and Chinese product descriptions. An English explanation-enabled submission and a Chinese detection-only submission should not be marked as equally complete merely because both returned a score. Equally, the Chinese submission should not be marked clean because the explanation panel is empty. Both can enter contextual review, with their different available evidence made visible.
Record configuration and check the actual response
Keep the requested language policy, whether explain was enabled and the interface used with the job record. If your application changes those settings, make the change traceable. This is our reproducibility advice, not a claim that setting a language improves detector accuracy.
Then inspect the actual response. Was the request successful? Is required data present and structurally valid? Was explanation requested? Is the language and file type eligible? If eligible, is the expected explanation available? Preserve the distinction between an unsupported feature, an unrequested feature and an unexpected missing field.
Do not make missing optional data default to a favorable authorship decision. In particular, a missing patterns object is not the same thing as a validated negative result. A parser should keep unresolved states visible and give the reviewer enough information to investigate them.
Define the alternative route before you need it
An explanation-dependent workflow needs a fallback. That could be a reviewer examining the document and its revision history, or a request for additional provenance. If the required evidence is unavailable, the process should acknowledge the gap instead of manufacturing a confident label.
Tell writers what additional materials would help. An outline, dated draft or revision history may be more relevant to a disputed authorship question than an explanation of statistical patterns. Keep those materials separate from detector output, and let a writer challenge a finding without being required to reproduce a particular score.
Recheck capabilities without rewriting editorial history
Maintain the reference date for the capability list used in your integration. If coverage changes, update eligibility and instructions for future jobs; do not silently relabel old jobs as though they had access to the new capability. Retain the configuration and evidence actually associated with each decision.
Also track operational outcomes without calling them accuracy measurements. “The explanation was unavailable” and “a reviewer requested provenance” are workflow observations. Neither establishes a false-positive rate or proves how the system performs in an untested language.
Limits
Documented language coverage is not a per-language accuracy benchmark. We have not submitted multilingual samples, measured false positives or compared explanation quality. Supported languages can still need careful review, and unsupported explanations do not establish anything about the source of a document.
The absence of explanations has several possible causes. Language or file-type eligibility may be one; configuration, an invalid response or processing problems may be another. Do not diagnose the cause from an empty panel alone. Equally, the presence of an explanation does not settle a disputed claim of AI use.
We do not provide a production rule for mixed-language documents, scanned-image extraction or embedded code here. Verify those requirements separately against the interface you intend to use. A feature list cannot replace a representative validation exercise for your own application.
Final Verdict
Treat detection support, explanation support and editorial judgment as separate layers. Build the fallback route at the same time as the explanation-enabled route, and make missing evidence a visible state rather than an automatic clearance.
For a multilingual team, that distinction is more useful than an unsupported claim that the same score means the same thing in every language. Keep configuration and provenance, consult current official documentation, and explain the limits of the available evidence to the writer and reviewer alike.