jats-fundamentals

JATS 1.4 and Multilingual Articles: Beyond the Bilingual PDF

EditorialXML5 min read
  • jats
  • multilingual
  • scholarly-journals

A bilingual PDF is not a multilingual article. One is two presentations stapled together; the other is a single structured record that machines can index without guessing which title belongs to which language. JATS 1.4 (ANSI/NISO Z39.96-2024) pushed the standard further in that second direction — especially for articles that carry substantial text in more than one language inside one XML file.

That sounds like a free win for Spanish- and Portuguese-language journals that already publish English abstracts. It is not free. The standard opens modeling options; your editorial policy still has to decide what "the article" is, and your destination (SciELO, PMC, a university repository) may still expect an older packaging habit.

What 1.4 unlocked for multilingual content

NISO's 1.4 revision is best known, among practitioners, for better support of articles that include substantial portions in two or more languages — not only a translated abstract bolted onto a monolingual body. The Tag Libraries and change notes on jats.nlm.nih.gov document the technical deltas; you do not need to memorize every element rename to make an editorial decision.

What matters on the ground:

  • You can represent parallel linguistic content with clearer language attribution (xml:lang and related structures), instead of relying on informal conventions that break in harvest.
  • Downstream systems that actually implement 1.4 can preserve both languages without treating one as "decoration."
  • Authoring and Archiving/Publishing Tag Sets all move together; you still pick the Tag Set your workflow needs.

If your team only ever marks xml:lang on <abstract> and leaves the body unmarked, you are not using 1.4's multilingual story — you are still shipping a monolingual article with a courtesy translation of the summary.

What remains editorial work (the part XML will not decide)

Standards do not choose your product. Before anyone rewrites templates, answer these in a one-page policy:

  1. Is the second language a full translation or a summary? Full body translation often means <sub-article> (or destination-specific patterns). A translated abstract alone is a different, cheaper product.
  2. Which language is canonical for citation? Crossref and Google Scholar hate ambiguous titles. Pick a primary xml:lang on <article> and be consistent issue after issue.
  3. Who owns translation quality? XML producers should not be rewriting science in English at 11 p.m. the night before SciELO delivery.
  4. Do figures and table captions get both languages? Half-translated captions look polished in InDesign and messy in XML validation.

Journals that skip this conversation end up with three incompatible XMLs: one for the website HTML, one for SciELO, and one "experimental 1.4" that never ships.

Why SciELO can still sit on Publishing 1.1 while you care about 1.4

Here is the friction Latin American editors feel first: SciELO SPS is still built on JATS Journal Publishing 1.1, with dtd-version="1.1" and specific-use="sps-1.10" (or whatever your collection currently requires). That is not a bug in your reading of NISO. Destinations adopt Tag Set versions on their own schedule.

So:

LayerTypical version todayRole
NISO JATS standard1.4 (Z39.96-2024)Industry vocabulary and future-proof modeling
EditorialXML free validator1.4 ArchivingStructural / schema scrub
SciELO SPS packagesPublishing 1.1 + SPS rulesWhat the national collection accepts
PMCJournal Publishing + PMC guidelinesBiomedical archive rules

Producing "perfect 1.4 multilingual XML" does not auto-pass SciELO. Conversely, a clean SPS 1.10 package may not exercise every 1.4 multilingual construct. Plan for the destination first; use 1.4 where your own HTML/PDF pipeline or long-term archive benefits.

A pragmatic path for bilingual journals

Phase A — metadata honesty (do this now). Titles, abstracts, and keywords with correct xml:lang. ORCID and affiliations that survive Crossref. No invented second titles.

Phase B — translation as structured product. If you publish full translations, mark them as such (sub-article / related-article patterns your destination documents), with their own DOI policy decided up front.

Phase C — adopt 1.4 constructs where your stack supports them. Internal archive, modern HTML site, or a partner that already validates 1.4. Keep the SciELO export mapped to Publishing 1.1 + SPS until the network moves.

That phasing sounds slow. It is faster than rewriting every template twice because someone confused "NISO published 1.4" with "SciELO accepts 1.4 tomorrow."

Concrete checks before you announce "we are multilingual XML"

  • Every abstract and title group that exists in two languages has matching xml:lang values — not comments in the Word file.
  • The article root language matches the primary full text, not the language of the marketing blurb.
  • Translators deliver structured text (headings, paragraphs), not a second PDF for someone to OCR.
  • You have tested one pilot through the JATS validator and through your SciELO checklist. Passing only one of those is how bilingual projects stall.

For the broader standard picture, the complete JATS XML guide and What is JATS XML stay the reference. If production capacity is the bottleneck, JATS XML production exists for a reason.

Bottom line

JATS 1.4 gives bilingual and multilingual journals a cleaner way to say "this intellectual content lives in more than one language." It does not replace editorial policy, and it does not override SciELO's Publishing 1.1 + SPS reality. Treat 1.4 as the horizon for your own systems; treat SPS as the gate for the packages that leave for the national collection. Journals that keep those two maps on the same desk stop promising "multilingual XML" when they still mean "English abstract in a Spanish PDF."

Sources consulted

Related articles