Skip to content

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

Return to the regular view of this page.

OINK Case

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

Fifteen site projects, from a two-page utility to a multilingual documentation estate and three books. Open a card to read the case, then follow its site or source link. Use the Case Guide to compare examples by the kind of site you want to build.

1 - pgsty.com

PGSTY: the company behind Pigsty. A small bilingual corporate site that uses OINK primarily as a data-driven 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

PIGSTY: the Chinese home of the open-source PostgreSQL distribution. Deployed as an independent single-language site so a very large translation corpus evolves on its own.

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

PIGSTY: the English home of the open-source PostgreSQL distribution. A large site combining a distribution manual, editorial blog, extension catalogue and pricing landing pages.

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.pgsty.com

SILO: the community-maintained MinIO fork for S3-compatible object storage. A large bilingual migration whose checked manifest generates the documentation navigation.

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.

Follow the navigation data boundary

The committed data/docs_nav.json records its inputs in meta.generated_from (migration/reports/navigation.csv) and meta.manifest (migration/minio-docs-manifest.csv). The migration process owns those inputs and the generated navigation; OINK consumes the resulting tree. Those input paths describe provenance, not a generator bundled with OINK.

This trades a second, site-maintained navigation artifact for control over an imported manual’s order. Use the ordinary content tree for a small original manual; adopt generated navigation only when you also maintain its source and regeneration procedure.

→ Navigation · All OINK cases

5 - oink.pgsty.com

OINK: the Hugo theme every site in this library is built with. Public manual, design reference, component gallery and regression fixture 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 - caps.vonng.com

CapsLock: turn the most useless key on the keyboard into a fifth modifier. A two-page 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.

Keep the application at the site layer

The site’s hugo.yaml includes customizer in params.ui.shell_types. content/customizer.md selects type: customizer and layout: customizer, then invokes the site’s capslock-configurator shortcode. The configurator, JavaScript, and keyboard data are site code; OINK does not include this application.

Reuse this boundary when a small custom tool needs the documentation shell. You must maintain its interaction code yourself; a two-page site does not make that application maintenance disappear.

→ Layout configuration · All OINK cases

7 - pig.pgsty.com

PIG: the package manager that installs any PostgreSQL extension. 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.

Reuse the separation, not the product data

The Docs root selects the documentation type. Separately, data/home/metrics.yaml keeps product counters outside the prose. The site maintains those facts and the templates that consume them; OINK supplies the reading shell.

For a small product, start with ordinary Docs files and add structured home data only for facts reused elsewhere. Copy the organization, not PIG’s package counts or product-specific home implementation.

→ Docs structure · All OINK cases

8 - sow.pgsty.com

SOW: the repository manager that builds and mirrors APT and YUM software repositories. A bilingual operations manual with a download surface fed by release metadata.

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 - exp.pgsty.com

PG Exporter: the Prometheus metrics exporter for PostgreSQL and Pgbouncer. A bilingual manual combining generated navigation, a structured catalogue 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 - ddia.vonng.com

DDIA: the Chinese edition of 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 - tpme.vonng.com

TPME: the Chinese edition of The Product-Minded Engineer. A focused bilingual publication that needs 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.

Limit the site to the reading model it needs

The site’s hugo.yaml sets the relevant options under params.ui:

params:
  ui:
    typography: system
    shell_types: [book]
    docs_section: ''

This keeps the shared shell focused on a book and uses system fonts. It does not convert arbitrary pages into chapters: the site still owns its manuscript, language configuration, and Book front matter. Start from the Book root pattern and add another shell type only when a separate documentation or publishing section needs it.

→ Writing a book · DDIA case

12 - pgint.vonng.com

PG Internals: the Chinese edition of PostgreSQL Internals. A single-language 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 - PostgreSQL ecosystem library

A Hugo operations library for PostgreSQL components, with shared search and navigation across upstream manuals and partially translated language trees.

The PostgreSQL ecosystem library 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.

This case describes the Hugo component library. The PGSQL.CC public portal is a separate Django application.

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

PIGSTY PRO: the enterprise edition of Pigsty. A bilingual documentation and release archive built around reusable, structured release records.

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 - ext.pgsty.com

PGEXT: the PostgreSQL extension catalog. 2,241 extensions indexed and 576 packaged, searchable across 16 Linux platforms and 5 major versions.

ext.pgsty.com is the PostgreSQL Extension Catalog: search across extensions, package families, dependencies, and the exact PostgreSQL and operating-system combinations each one is available for. The catalogue indexes 2,241 extensions, 576 of them packaged, across 16 Linux platforms and 5 major PostgreSQL versions.

What it demonstrates

  • A queryable dataset presented as the primary object of a site, with the reading shell kept out of its way.
  • A catalogue and its prose living in one OINK site, the same arrangement PG Exporter and pigsty.io use for their own structured data.

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