uniweb 1.22.1 → 1.22.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "1.22.1",
+  "version": "1.22.2",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,15 +41,15 @@
     "js-yaml": "^4.3.2",
     "prompts": "^2.4.2",
     "tar": "^7.5.21",
-    "@uniweb/core": "~1.4.12",
     "@uniweb/semantic-parser": "~1.13.0",
-    "@uniweb/schemas": "~1.6.5",
-    "@uniweb/content-writer": "~1.3.1"
+    "@uniweb/core": "~1.4.12",
+    "@uniweb/content-writer": "~1.3.1",
+    "@uniweb/schemas": "~1.6.6"
   },
   "peerDependencies": {
     "@uniweb/semantic-parser": "~1.13.0",
-    "@uniweb/content-reader": "~1.5.7",
-    "@uniweb/build": "~1.11.1"
+    "@uniweb/build": "~1.11.2",
+    "@uniweb/content-reader": "~1.5.7"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -952,7 +952,7 @@ The body — the value of the schema's content field, `body.content`.
 
 A path under a folder is relative to `records/`, naming one file or matching many. A record's entry can instead be `{ path, tags, label }` — what the folder says about the record: a component receives them beside it as `$tags` (in the order written) and `$label`, and a query reads them like any key (`where: { $tags: featured }`); such an entry may sit at the top level, where a bare path is refused. A `label` — a record entry's or a folder's — is one text in the site's language, or one per language (`label: { en: Launch video, fr: Vidéo de lancement }`); `$label` is the page's language, else its base language, else the site's. A folder takes `tags:` too. A query reads one folder with `scope: archive` — the folder and everything inside it. A record sits in one folder; if you want a computed subset, that is a query, not a second placement. Structure is for querying, not for navigation — and `folder.yml` never lists a record at the top level (the build refuses it: every file in `records/` is a record already).
 
-⚠️ **With a backend, `records/` is what `uniweb push` sends** — every record in it. A site with no `records/` at all leaves the backend's records alone; an *empty* `records/` removes them, and the CLI asks before it does. Records pushed to a backend are served once the site is published.
+⚠️ **With a backend, `records/` is what `uniweb push` sends** — every record in it. A site with no `records/` at all leaves the backend's records alone; an *empty* `records/` removes them, and the CLI asks before it does. Records pushed to a backend are served once the site is published: a record with a data schema reaches the published pages only when `services:` asks for `records: true`, and one with none travels as the published site's files.
 
 **`queries.yml` — how content is reached.** A bare map of name → query. A query names a schema and the site's records of that schema are its rows:
 
@@ -2948,8 +2948,9 @@ YAML, not switches — write `true` or `false`. On a site you push or publish it
 its service, `false` asks it to turn its service off, and an address asks it to leave its own off so
 yours answers. **On a site your host publishes, a service is off unless `services:` asks for it** —
 list the ones the site uses (the templates list theirs). `records: true` asks for your records to be
-delivered live to the published pages: a query whose records have a data schema shows nothing there
-without it, and `publish` says so; a static build reads records from files and ignores it. An entry
+delivered live to the published pages. Turn it on before the first publish of a page that shows
+records with a data schema: without it those records never reach the published page, and `publish`
+warns. A static build reads records from files and ignores it. An entry
 says everything about its service: a setting you remove from it is removed on the next push, and
 removing the entry switches the service off. `uniweb push` and `uniweb publish` send each service
 `site.yml` lists; a service the site has that this copy has never seen (turned on in the app since
@@ -3080,6 +3081,8 @@ These are **body only — no frontmatter**; params and config still come from th
 
 **Records translate in the same `extract` run**, into their own manifest at `locales/records/manifest.json` — keyed by the RECORD, so a record translated once is found by every query that returns it. A record whose query has a data schema translates exactly the fields the schema says are text — never an enum, a URL, a date, a number, a file, a reference or a `translatable: false` field — which are the fields a push carries in each language; mark a string that is a code or a key `translatable: false` and no translator is asked for it. An excerpt the build derives is re-derived from each language's body.
 
+**A data schema's own labels are not in `locales/`.** The schema's `label`, `plural`, `description` and its sections' and fields' labels are written once, in its `source_locale`; their other languages go in the schema's `i18n`, keyed by path: `i18n: { fr: { model.label: Séance, section.brief.field.title.label: Titre } }`. A section is named by its full path (`contributions/publications`), and a `fields:` schema's one section is `brief`. See `development/data-schemas.md`.
+
 **Component side.** Nothing to do: `content.title` arrives in the active language. The one thing a foundation builds is a switcher.
 
 ```jsx

package/src/framework-index.json

@@ -1,12 +1,12 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-10-29T02:26:03.448Z",
+  "generatedAt": "2026-10-29T14:12:43.968Z",
   "packages": {
     "@uniweb/api": {
       "version": "1.6.5"
     },
     "@uniweb/build": {
-      "version": "1.11.1"
+      "version": "1.11.2"
     },
     "@uniweb/content-reader": {
       "version": "1.5.7"
@@ -42,7 +42,7 @@
       "version": "1.0.1"
     },
     "@uniweb/schemas": {
-      "version": "1.6.5"
+      "version": "1.6.6"
     },
     "@uniweb/scholar": {
       "version": "1.1.0"