Skip to content

This is the multi-page printable view of this section. .

Return to the regular view of this page.

OINK Cases

Fifteen real sites show how OINK scales from a two-page utility to a multilingual documentation estate and three books.

OINK is used by large distribution manuals, focused product documentation, books, corporate landing pages, and tiny interactive tools. These fifteen cases describe the content model and theme capabilities behind each site—not just how its home page looks. One of them, pgext.cloud, is here as the boundary: it is a bespoke data application rather than an OINK site.

Every card below opens the live site in a new tab. To read the case behind a site instead, follow the links in this page or search for it by name. Each entry is a page bundle and inherits the Case visual until it receives a site-specific featured image of its own.

1 - pgsty.com

A small bilingual corporate site that uses OINK primarily as a landing-page system.

pgsty.com is the bilingual corporate site behind Pigsty. It has only about ten pages: a type: home front page assembled from data/home/{en,zh}.yaml, followed by focused pages for solutions, company information, and pricing.

What it demonstrates

  • Using OINK as a landing-page theme with almost no documentation tree.
  • Maintaining compact English and Chinese marketing pages as peers.
  • Building the home-page narrative from reusable data sections.

This pattern is appropriate when a project wants OINK’s brand, navigation, search, and multilingual conventions but primarily needs a small public-facing site rather than a manual.

→ Home and landing pages · All OINK cases

2 - pigsty.cc

A Chinese-first Pigsty site that keeps a very large translation corpus independent from its English peer.

pigsty.cc publishes Pigsty in Simplified Chinese. The case snapshot counted more than 1,490 content files and over 300 blog posts, with its own data-driven pricing page and Chinese as the default content language.

What it demonstrates

  • Splitting a very large bilingual corpus into two independently deployed, single-language sites.
  • Connecting the pair through the alternate-site control and version menu.
  • Letting each language keep its own publishing cadence and landing-page data.

This pattern trades same-domain language switching for clearer ownership and smaller builds. It is useful when both languages are already substantial products rather than occasional translations.

→ Multilingual configuration · pigsty.io case

3 - pigsty.io

A large English documentation, blog, extension-catalogue, and pricing site for the Pigsty distribution.

pigsty.io is the English home of Pigsty, the open-source PostgreSQL distribution. At the snapshot used for this case, it contained more than 1,400 Markdown files, over 200 blog posts, an extension catalogue, and a data-driven pricing page.

What it demonstrates

  • A large documentation tree and editorial blog living in one Hugo site.
  • Structured catalogues whose content and data are maintained separately.
  • A layout: landing pricing page assembled from data/landing.
  • Taxonomies and a version menu that also link to sibling and historical sites.

Choose this pattern when one English-first site must serve reference material, news, catalogues, and commercial landing pages without splitting the toolchain.

→ Home and landing pages · All OINK cases

4 - SILO

A large bilingual migration whose generated navigation preserves the structure of hundreds of upstream pages.

silo.pgsty.com documents SILO, an S3-compatible object store. The case snapshot counted 411 pages per language. A migration manifest covering 387 upstream pages generates data/docs_nav.json, which then drives the documentation sidebar. The site also has module taxonomy and a download page.

What it demonstrates

  • Migrating a large upstream manual without flattening its information design.
  • Generating navigation from a checked manifest instead of hand-maintaining it.
  • Layering local bilingual content, taxonomy, and downloads around imported docs.

Use this pattern when the upstream corpus remains authoritative but the local site needs its own navigation, language peers, and product surfaces.

→ Navigation · All OINK cases

5 - oink.pgsty.com

OINK’s public manual, design reference, component gallery, and regression site in one repository.

oink.pgsty.com is the site you are reading. It is the theme’s public manual and a real consumer used for regression coverage. Its component pages render live examples; the same repository also carries design contracts, Book fixtures, download data, and home and landing-page data.

What it demonstrates

  • Documentation examples that are executable regression fixtures, not screenshots.
  • One site serving users, content authors, theme developers, and reviewers.
  • Component, Docs, Blog, Book, Case, download, and landing surfaces together.
  • Bilingual content checked against a pinned Hugo Module dependency.

Use this repository as the broad reference implementation; use the narrower cases when starting a site that needs only one or two OINK content models.

→ Component gallery · Design contracts · All cases

6 - Capslock

A two-page bilingual project site whose second page is a data-driven interactive configurator.

caps.vonng.com is a two-page-per-language site for the Capslock keyboard enhancement: a home page and an interactive configuration generator. The generator reads data/capslock-v3.json and uses a custom customizer shell type alongside the regular documentation shell.

What it demonstrates

  • The practical lower bound of an OINK site: a tiny project needs no front-end application just to publish a tool and its introduction.
  • Extending the shell registry for one purpose-built interactive page.
  • Keeping generator data separate from its presentation and bilingual prose.

Use this pattern when documentation is small but one interactive tool deserves the same navigation, theme, and language controls as the rest of the site.

→ Layout configuration · All OINK cases

7 - PIG

A compact bilingual product manual with a data-driven home page and an active companion blog.

pig.pgsty.com documents PIG, the PostgreSQL extension package manager. Its core manual is deliberately compact—18 pages per language in the case snapshot—while a 50-post bilingual blog carries updates and deeper explanations. The home page is assembled from data/home.

What it demonstrates

  • A shallow, mostly single-file documentation tree for a focused CLI product.
  • English and Chinese peers without duplicating navigation design.
  • A data-driven home page paired with a larger stream of blog content.

Choose this pattern when the reference manual is small and stable but product news, tutorials, and release context need room to grow.

→ Docs structure · All OINK cases

8 - SOW

Bilingual repository-manager documentation with a release-data-powered download surface.

sow.pgsty.com documents SOW, an APT and YUM repository manager. The case snapshot contained 55 pages per language and a dedicated download page whose versions, tags, and release artifacts are generated from structured release data.

What it demonstrates

  • Keeping operational documentation bilingual at a moderate scale.
  • Giving downloads their own content type instead of embedding links in prose.
  • Reusing release data so package metadata has one source of truth.

This pattern fits software that distributes many platform-specific artifacts and needs installation instructions, repositories, and downloads to evolve together.

→ Releases and downloads · All OINK cases

9 - PG Exporter

A bilingual metrics manual combining generated navigation, structured catalogues, and system typography.

exp.pgsty.com documents PG Exporter, a Prometheus metrics collector for PostgreSQL. The case snapshot counted 15 pages per language and 37 bilingual blog posts. Generated navigation, home-page data, and a structured metric catalogue do most of the organizational work.

What it demonstrates

  • Using data/docs_nav.json for a small but deliberately ordered manual.
  • Rendering a domain catalogue from structured data rather than repeated prose.
  • Selecting typography: system when a site should make no brand-font request.

This pattern suits technical products whose reference data is as important as their narrative documentation, especially where a lightweight font stack is preferred.

→ Typography and brand · All OINK cases

10 - Designing Data-Intensive Applications

A multilingual book site and the largest proving ground for OINK numbering, cross-references, and indexes.

ddia.vonng.com publishes Designing Data-Intensive Applications as a multilingual book. The case snapshot includes 24 chapters each in Simplified and Traditional Chinese, 23 chapters of the English second edition, and two 21-chapter first-edition sets.

What it demonstrates

  • A complete type: book reading shell with chapter-level navigation.
  • More than 130 numbered figure, table, equation, and example targets.
  • Stable cross-references and generated book indexes across several editions.
  • Multiple written-language variants inside one publication.

Use this pattern for long-form works where numbering, citations, and movement between chapters matter more than documentation-style sidebars.

→ Writing a book · All OINK cases

11 - The Product-Minded Engineer

A focused bilingual book that uses only OINK’s book shell.

tpme.vonng.com publishes The Product-Minded Engineer in English and Chinese, with 18 chapters per language in the case snapshot. Its configuration narrows the supported shell types to [book].

What it demonstrates

  • A publication with exactly one content model and no documentation shell.
  • Bilingual chapter peers with a shared visual and navigational system.
  • A smaller Book implementation than the multi-edition DDIA site.

This is the clearer starting point for a single-title tutorial or translated book: keep the site architecture narrow, then add numbering and indexes only as the manuscript needs them.

→ Writing a book · DDIA case

12 - PG Internal

A single-language Chinese book site that runs the Book shell on its own, with no documentation tree beside it.

pgint.vonng.com publishes PG 技术内幕, the 2018 Chinese translation of Hironobu Suzuki’s The Internals of PostgreSQL. The site carries two prefaces, eleven chapters, a generated table of contents, and a licensing page — all in Simplified Chinese, with no English peer.

What it demonstrates

  • A deliberately monolingual OINK site: one language tree, and a language switcher that stays out of the way because there is nothing to switch to.
  • The Book shell carrying a finished translation rather than a living manual — chapter navigation, whole-book print output, and a landing page in one site.
  • A landing page that credits an upstream author alongside the translators, and links outward to the continuously updated English original.

Use this pattern for a completed translation or a stable published text: the content will not grow, so the site’s job is orientation, reading comfort, and honest attribution rather than change management.

→ Writing a book · TPME case · DDIA case

13 - pgsql.cc

An aggregate PostgreSQL operations library with independently evolving English and Chinese coverage.

pgsql.cc brings the operating manuals for Patroni, HAProxy, etcd, PgBouncer, pgBackRest, and pgBadger into one PostgreSQL-focused library. The case snapshot counted 217 English pages and 80 Chinese pages.

What it demonstrates

  • Giving several upstream products a consistent local information architecture.
  • Publishing English first while Chinese coverage grows over time.
  • Keeping partial translation useful instead of blocking publication on parity.
  • Using subtrees to preserve clear product boundaries inside an aggregate site.

Choose this pattern for a curated technical library where sources and translation maturity vary, but readers benefit from one search and one visual system.

→ Multilingual configuration · All OINK cases

14 - pgsty.pro

A bilingual Pigsty v5 documentation and release archive built around reusable release cards.

pgsty.pro documents Pigsty v5 in English and Chinese. The case snapshot counted 343 documentation pages per language and 67 bilingual blog posts. Its release archive is the distinctive part: 128 localized pages render version data through the reusable release-card component.

What it demonstrates

  • Keeping a long product history navigable without hand-building every card.
  • Sharing structured release data between download, archive, and detail pages.
  • Maintaining documentation and editorial posts as bilingual peers.

Use this pattern for products with many supported or historical versions where release metadata must stay consistent across several surfaces.

→ Releases and downloads · All OINK cases

15 - pgext.cloud

The PostgreSQL Extension Catalog — the one site in this family that is a bespoke data application rather than an OINK site.

pgext.cloud is the PostgreSQL Extension Catalog: search across extensions, package families, dependencies, and the exact PostgreSQL and operating-system combinations each one is available for. It is the boundary case in this library, because it does not run OINK. The catalogue is a hand-written single-page application served as static files, with its own query interface over the extension dataset.

What it demonstrates

  • Where a documentation theme stops being the right tool. The primary object here is a queryable dataset, not a tree of pages, so page-per-topic navigation, a sidebar, and a reading shell would all be in the way.
  • The counter-example to PG Exporter and pigsty.io, where structured catalogues live inside an OINK site because prose surrounds them.

Use OINK when readers arrive to read; reach for a purpose-built application when they arrive to query. The two can sit side by side in one project and link to each other, as they do here.

→ PG Exporter case · pigsty.io case · All OINK cases