Every Webedia market already produces stories worth sharing. The problem is not a lack of content. It is the friction between finding a useful article on another brand, understanding it in another language, adapting it for a local audience, and moving it safely into the destination website.

Today, that journey often involves several open websites, chat messages, machine-translation tabs, manual copy and paste, and a final clean-up inside a CMS. The original formatting may be damaged, the source can become difficult to trace, and every step depends on somebody remembering what comes next.

Polaris is our working proof of concept for turning that journey into one editorial workflow. It aggregates articles from Webedia websites into a common pool, helps editors decide what is worth reusing, creates a localized draft for each destination, and delivers the result with its provenance intact.

It does not replace a website’s CMS, and it does not replace writers. The source website remains where the original article is written and published. The target website remains in control of its final publication. Polaris is the exchange layer between them.

The problem Polaris solves

Our websites do not share one stack, one content model, or one language. A recipe, a game guide, and a film review may all be “articles”, but their CMSs store titles, authors, categories, media, and body components differently.

That creates four practical problems.

  • Discovery is fragmented. Editors need to know which sites to visit and which articles are performing well before they can even build a shortlist.
  • Language blocks editorial judgment. A title can be translated quickly, but deciding whether a foreign-language article is relevant requires understanding its lead and body too.
  • Localization is more than translation. The same source needs a different locale, vocabulary, tone, and sometimes a different treatment of links or media for each destination brand.
  • Every CMS integration is different. Copying by hand is slow; building a unique point-to-point integration between every pair of sites does not scale.

A naive central platform could copy every complete article and every image as soon as it is published. That would move and process a great deal of content that nobody ever selects. Polaris uses a metadata-first model instead: index the lightweight information early, then fetch and localize the full article only when an editor chooses it.

Polaris high-level architecture Source websites send lightweight metadata to the Polaris content pool. When an editor selects an article, Polaris requests the complete content, localizes it, sends it through an optional review gate, and delivers it to the destination CMS or inbox. One shared editorial exchange Websites keep their CMS. Polaris handles discovery, transformation, and delivery between them. SOURCE WEBSITES POLARIS DESTINATIONS Article CMS PHP or TypeScript Legacy CMS Adapter at the boundary RSS bridge Low-effort onboarding Metadata first; content on request Polaris content pool Searchable metadata catalogue Editorial selection Choose source + destinations Localize One draft / site Route Review or auto Queue makes failures visible, retryable, and auditable. Review inbox Compare + accept Copy rich content Webhook article.upserted Idempotent delivery Destination CMS Creates a local draft metadata request content review route CANONICAL SCHEMA stable identity revision structured blocks provenance

Source sites keep their CMS; Polaris connects discovery, localization, review, and delivery to the destination.

The important boundary is the editorial decision in the middle. Polaris can automate transport and transformation; a person still decides which story should travel to which audience.

How Polaris helps writers and editors

One place to find the right story

The Polaris pool is a shared catalogue of article metadata from connected sources. An editor can narrow it by vertical, website, locale, category, tag, date, or editorial flags, and can hide their own site while looking for material from elsewhere.

Recency is not the only signal. When Marfeel data is available, the pool can be ranked by page views or RFV loyalty (Recency · Frequency · Volume) over realtime, 24-hour, and seven-day windows. That does not make the routing decision automatically; it puts useful evidence next to the article so an editor can spend attention where it is most valuable.

Filters live in the URL, so a carefully scoped view can be bookmarked or shared with another editor instead of being rebuilt from memory.

Read first, decide second

Polaris separates reading translation from publication localization. They sound similar but have different jobs.

The reading layer gives an editor a faithful, neutral view of foreign-language content in their preferred language. In the pool it translates the title and lead; after the full content has been requested it can translate the body while preserving its structure. The original is always one toggle away, and the view is explicitly marked as decision support—not publishable copy.

Only after an editor understands the source and assigns a destination does the publication localization run. That second transformation targets the website’s locale and brand voice. It can also apply source-specific rules, such as reformulation guidance or removing media and source links where rights require it.

This separation matters: a neutral translation helps a person judge the source; a localized draft helps a brand publish it.

Turn one source into several brand-ready drafts

An editor can assign one article to one or more permitted websites. Each selection creates an independent routing because every destination can have its own:

  • target locale;
  • tone and brand-voice prompt;
  • localization model;
  • review policy; and
  • delivery endpoint.

The result is not one generic translation copied everywhere. It is one derived draft per target website, with a link back to the source article, the source revision used, and the editor who routed it.

Keep a human checkpoint where it matters

A website can require review or opt into automatic routing. In the review flow, Polaris shows the source and localized fields side by side and highlights what changed. An authorized editor can accept and ship the draft, or reject it with a note that can guide a later attempt.

The routing queue also exposes the operational state—ordered, translating, waiting for review, routed, rejected, or failed—rather than hiding work in a background job. A failed localization or delivery stays visible and retryable.

Fit the destination team’s current workflow

Automation does not need to be a condition for joining. A localized article is available in the destination inbox and can be copied as rich HTML, Markdown, or plain text. Rich HTML keeps paragraphs, headings, emphasis, and links intact when pasted into a WYSIWYG editor.

When a website is ready for a deeper integration, Polaris can POST the same canonical article to its webhook. The manual and automated paths therefore carry the same content; a team can start with the inbox and automate later.

How a website connects to Polaris

A website can play either—or both—of two roles:

  1. a source, which makes its own articles discoverable; and
  2. a destination, which receives localized articles selected for it.

The CMS does not need to adopt Polaris’s internal architecture. It only needs an adapter at each boundary.

Source side: publish metadata, provide content on request

On every article edit, the source maps its local model into a small ArticleMetadataPayload and sends an idempotent upsert to Polaris. The stable identity is the triple (source, sourceId, locale), and a monotonically increasing revision tells Polaris which version is newer.

{
  "schemaVersion": "1.2",
  "source": "example-food",
  "sourceId": "article-42",
  "locale": "fr_FR",
  "title": "La tarte aux pommes de notre enfance",
  "url": "https://example.com/tarte-aux-pommes",
  "status": "published",
  "revision": 7,
  "contentRequestUrl": "https://internal.example.com/polaris/content/example-food/fr_FR/article-42"
}

There are no body blocks or media uploads at this stage. If an editor selects the article, Polaris sends an article.content_requested order to the advertised URL. The source acknowledges quickly, loads the current article asynchronously, maps its body into the canonical block types, and pushes the full ArticlePayload back with the same identity, revision, and request id.

Common content maps to paragraph, media, embed, and quote blocks. A generic block carries site-specific components that the common contract does not model yet, so connecting to Polaris does not require flattening every CMS into lowest-common-denominator HTML.

Source teams have three practical onboarding paths:

  • PHP/Symfony: webedia/polaris-bundle provides the publishing port, content-request receiver, schema validation, and Messenger integration.
  • TypeScript: @webediagroup/polaris-client provides the same contract and ports for Node or Bun applications.
  • RSS: the Polaris RSS producer polls a feed for metadata and scrapes the full page only after an order. This is the low-effort bridge when changing the CMS is not yet possible.

Destination side: configure, receive, import

Polaris stores a small configuration for each destination: its target locale, brand-voice prompt, review policy, network zone, and egressTarget webhook. After localization and any required approval, it sends an article.upserted event containing the derived ArticlePayload.

The destination handler has a short list of responsibilities:

  1. authenticate the request according to its network boundary;
  2. decode the event and acknowledge it quickly with a 2xx response;
  3. deduplicate and upsert on (source, sourceId, locale) plus revision;
  4. map the canonical blocks into its own CMS model;
  5. rehost media in its own storage or CDN; and
  6. usually create a local draft for the destination editors to publish.

The delivery is deliberately idempotent. Retries and deliberate re-routes must not create duplicate articles. Polaris metadata travels in its own polaris object, preserving when the article was routed, who routed it, and which source article and revision the localized version came from.

Here is the complete exchange as a sequence:

Polaris article exchange sequence A ten-step sequence between a writer, source CMS, Polaris, editor, and destination CMS: publish, index metadata, assign, request and return content, localize, review, accept, deliver, and acknowledge. From source article to local draft Ten contract-safe steps; one editorial decision at the centre. Writer Source CMS Polaris Editor Destination CMS PUBLISH & DISCOVER 01 Save / publish 02 Upsert metadata 03 Browse + assign FETCH ON DEMAND 04 Request content 05 Push full article 06 Localize One draft per target REVIEW & DELIVER 07 Review draft 08 Accept / route 09 Deliver article.upserted 10 2xx acknowledge command or delivery request, decision, or acknowledgement

Every arrow crosses a stable contract boundary; retries are safe because the source and destination operations are idempotent.

Why the contract matters more than the transport

HTTP, Pub/Sub, Messenger, RSS, and a future transport can all carry the same article contract. That is intentional. Sites should depend on a small publishing port and a versioned schema, not on the implementation details of the Polaris console.

The schema is strict enough to make integrations predictable, but designed for different CMSs:

  • stable international identity through (source, sourceId, locale);
  • explicit revisions for ordering and cache invalidation;
  • a structured body with a generic escape hatch;
  • normalized status, author, SEO, taxonomy, and media fields;
  • source-scoped metadata for local information; and
  • explicit Polaris provenance on derived content.

This is also why the two-stage flow is useful. Metadata keeps the pool current and searchable. Full content, media work, and publication-grade localization are paid only for the small part of the catalogue that an editor chooses.

What Polaris changes—and what it leaves alone

Polaris changes the space between websites. It gives editorial teams a common place to discover stories, understand them, make a routing decision, review the localized result, and see whether delivery succeeded.

It leaves the important ownership boundaries in place:

  • writers still create and update the original in their own CMS;
  • source teams still control their data model and publishing lifecycle;
  • editors still decide what is appropriate for each audience;
  • destination teams still control the final draft and publication; and
  • websites can connect incrementally instead of migrating to a new CMS.

That is the core bet behind Polaris: international reuse should feel like one editorial workflow, even when the websites underneath it remain completely different.