Skip to main content
Publishing Platform for Four Peer-Reviewed Journals
Case study

A scholarly publisher bringing English and Arabic journals into one publishing platform

Sector
Scholarly Publishing
Work
Custom Software
Duration
14 weeks
Capability

14 functions

editorial work unified in one workspace

Capability

4 roles

author, reviewer, editor and coordinator, each with their own view of one record

Outcome

60 of 71

documented capabilities the publisher can change without a developer

Outcome

Publication proceeds

when a DOI deposit, an archive copy or a notification fails

Fig. 1

One record from submission to publication

Every step a manuscript goes through, from submission to publication, happens on a single record.

  1. 1. The manuscript enters as one record. Review, decision, issue and scheduling all happen to that record.
  2. 2. Author, reviewer, editor and coordinator each work on it, and each sees only the part that belongs to their role.
  3. 3. Publishing sends the article, its DOI deposit, the preservation copy and the author email together.
  4. 4. If one of those fails, the article still goes live and the failure is noted on the record for follow-up.

01The starting point

Four journals, one publishing operation.

A scholarly journal is not a document pipeline. It is a queue of manuscripts, each sitting at a different point in a process that involves people who must not see each other's work. A reviewer must see what they were assigned and nothing else. An editor needs the whole picture. An author needs to know where theirs has got to, without being shown the parts of the process outside their role.

Two languages run through all of it. An Arabic paper and an English paper sit in the same issue of the same journal, and a bibliography can mix both scripts inside a single entry list.

Fig. 2

Editors and authors see different histories

The editors and the author follow the same manuscript, but the author is shown a shorter, plainer history.

  1. 1. The editors see every state the manuscript passes through, in their own working terms.
  2. 2. A rejection reaches the author worded differently, as “Not Accepted for Publication”.
  3. 3. The scheduling step has no row on the author’s side at all.

02What we built

A bilingual platform for academic publishing.

One system carries a manuscript from a public submission form, through reviewer assignment and peer review, to an editorial decision, into an issue, and out as a published article with its citation metadata attached. Four roles work in it (author, reviewer, editor and special-issue coordinator) and each sees a different, legitimate view of the same manuscript.

The author-facing history is deliberately not the editorial one. A rejection reaches the author as “Not Accepted for Publication”, and the internal scheduling state is folded into “Accepted”, because an author waiting on an issue does not need to watch it being built. The list of states is not frozen in code either: editors add their own, and retiring one leaves it standing on every manuscript that already passed through it, so a history is never rewritten underneath a reader.

Direction is decided per line rather than per page, so a bibliography mixing Arabic and English sets each entry in its own. A Crossref 5.3.1 deposit pipeline and Zenodo preservation are built and wired, and the deposit host is fixed so local tests or stray configuration cannot register a test document with Crossref. Publication does not depend on any of it: if the deposit, the archive copy or the notification email fails, the article still publishes and the failure is written onto the manuscript.

Of 71 capabilities documented for the publisher, 60 are standard or configurable, changeable without a developer. That flexibility keeps the ongoing cost of running the platform down, and it was engineered deliberately.

Fig. 3

Reviewers see only what they are assigned

Access follows assignment. Nothing else in the queue is visible to a reviewer.

  1. 1. The one manuscript this reviewer was assigned.
  2. 2. Everything else in the queue stays locked to them.
  3. 3. They read the file in place and return the review.

03How the platform works

One manuscript record from submission to publication.

Fig. 4

Editors define their own workflow states

The editors can add and retire the states a manuscript moves through, without a developer.

  1. 1. The states the platform ships with.
  2. 2. States the editors add for their own process, with no developer and no release.
  3. 3. A state they retire stays on every manuscript that already passed through it.

Fig. 5

Arabic and English in the same list

Each bibliography entry is set in its own direction, so Arabic and English references sit in one list.

  1. 1. An English entry runs left to right.
  2. 2. The Arabic entry beside it runs right to left, on the same page, in the same list.

04What became possible

Journal publishing that can keep moving.

People the system carries, each with their own view of it

4 roles

Author, reviewer, editor, coordinator

Documented capabilities needing no developer to change

60 of 71, no developer

States a manuscript can be in

Editors add their own, without a release

9 in code → As many as the editors need

When DOI registration, archiving or the email fails

Publication proceeds

The article still publishes, and the failure is recorded

Built with

Next.jsReactTypeScriptFirebaseFirestoreCrossrefZenodoTailwind CSS

Building a publishing platform?

Bring us the publishing process, constraints and systems you are starting with. We will help work out what the platform needs to make possible.

More work

Keep reading.

From Incoming CVs to Client-Safe Candidate Profiles
Custom Software

Staffing & Recruitment

From Incoming CVs to Client-Safe Candidate Profiles

Manlytic Group’s recruiters work from their phones. CVs reach them on WhatsApp as scans, photos and two-column tables, passport details have to be exact, and anything sent to an employer has to leave the agency as the only route to the candidate.

  • Every file made for an employer is built without the candidate’s contact details, then searched again before it can be shared.
  • CVs are read without guessing: gaps stay visible, and anything unsure waits for a person to confirm.
  • A likely duplicate is reported and held for a recruiter, never merged on its own.
Building an AI Assistant You Can Control
Applied AI

Regulated Services

Building an AI Assistant You Can Control

How a private AI product company turned difficult regulatory material into a controlled assistant for professional firms.

  • Your own material, not a public model's: administrators decide what is in the knowledge base and what is not
  • Add a new regulation yourself: upload the PDF and the system cleans, splits and indexes it without a developer
  • Provision a company, invite named people into it, and cut their access server-side when it ends
Making Interior Products Easier to Find
Applied AI

Commerce

Making Interior Products Easier to Find

How a MENA AI studio turned an interior photograph into searchable product language, UAE results and a shortlist customers could export.

  • Photograph something you saw and get back things you can buy nearby, without typing a word
  • Keep what you like, set quantities against it, and export the shortlist as a PDF you can hand to someone else
  • Hand it a photograph of something that is not an interior item and it stops, rather than confidently returning the wrong furniture