Spaces, Collections & Articles

Spaces, Collections & Articles

Zingasolve organizes documentation into three levels. Understanding them is the
key to structuring any site you build.

Spaces

A Space is one documentation site — a single help center, knowledge base, or
manual. It owns everything inside it: its chapter tree, its pages, its
annexures, and its publishing settings.

Each Space has:

• A name and optional description shown at the top of the site.
• A slug used in its URLs (unique within your account).
• A site slug — the globally unique locator for the default docs address,
  https://docs.zingasuite.com/<site-slug>.
• A default locale and a list of enabled locales (for example English and
  Hindi).
• A visibility setting (public, authenticated, or restricted) that acts as
  the baseline for everything inside it.

You can run several Spaces at once — for example a customer-facing "Help Center"
and an internal "Operations Manual" — each published independently.

Collections

A Collection is a chapter or folder inside a Space. Collections form a
tree: a collection can contain sub-collections, so you can build a nested
structure like Part → Chapter → Section. Each collection has a display name (per
locale), an optional icon, and a sort order that controls where it appears in
the sidebar.

Collection slugs are sibling-scoped — they must be unique among the
collections that share the same parent, but the same slug can be reused under a
different parent. This lets you write natural, repeatable paths (for example
installation/overview under more than one product area).

Articles

An Article is a single page. Every article belongs to a Space and, usually,
to a collection (its chapter). Article slugs are unique within their Space.

Articles are language-agnostic identities. The page itself doesn't hold the
text — instead, each enabled locale gets:

• An editable head — the working copy you edit in the portal, with its own
  title and body.
• An immutable version history — each time you publish that locale, its
  content is frozen as a numbered version that never changes.

The live site and the AI assistant always read a published version, never your
in-progress draft, so what readers see is exactly what you published.

Source locale and translations

One locale is the source (the article's default locale). When you publish a
non-source locale, Zingasolve records which source version it was written
against. If you later publish a newer source version, the lagging translations
are automatically flagged outdated in the editor so you know they need
attention. Each locale still publishes on its own schedule.

An article's per-locale state is one of:

Slugs and the URL model

Every published page resolves through a single per-(space, locale, slug)
lookup, so URLs stay clean and fast. Two behaviors matter when you reorganize:

• Rename safely — when you change a slug, the old URL is kept as a permanent
  (301) redirect to the new one, so inbound links and bookmarks keep working.
• Nested paths — collections contribute to the path, so a page reads as a
  readable hierarchy rather than a flat list.

On a single-manual site, pages sit directly under the site address. On an
entity hub that lists several manuals, each manual is served under its own
slug (for example .../help-center/… and .../api-docs/…).

Putting it together

Start by creating a Space, add collections to outline your chapters, then add
articles inside them. Set each level's visibility, author each locale, and
publish. The next article covers writing article content in detail.