https://docs.nanako.org/changelog Nanako Docs Blog 2026-09-16T00:00:00.000Z https://github.com/jpmonette/feed Nanako Docs Blog https://docs.nanako.org/img/favicon.ico <![CDATA[Long filenames no longer stretch the translate and parse pages]]> https://docs.nanako.org/changelog/2026/09/16/long-filename-layout 2026-09-16T00:00:00.000Z On desktop, uploading a file with a very long name could stretch the two-column layout on the PDF translation and document parsing pages, pushing the task list out of view instead of shortening the name.

Fixed​

  • Long filenames are now truncated inside their column on the PDF translation and document parsing pages, so the two-column layout keeps its proportions
  • Hovering a truncated filename shows the full name as a tooltip
]]> <![CDATA[Delete translation and parsing records]]> https://docs.nanako.org/changelog/2026/07/30/delete-task-records 2026-07-30T00:00:00.000Z Finished PDF translations and document parses can now be deleted, and the files go with them. This is a real deletion from storage, not a row quietly hidden from the list.

Added​

  • A delete button on every finished task in PDF translation and Document parsing. It permanently removes the source file and every result from object storage. This cannot be undone.
  • DELETE /api/v1/translate/tasks/:id/record and DELETE /api/v1/mineru/tasks/:id/record do the same over the API. Both return 400 for a task that is still running — cancel it first, otherwise its worker may write results after the deletion and leave them stranded.
  • If storage is unreachable, the whole request fails with 503 and nothing is hidden. A record never disappears while its files are still there.

Changed​

  • Cancelling is untouched. DELETE /api/v1/translate/tasks/:id and DELETE /api/v1/mineru/tasks/:id still only cancel an in-flight task. Cancelling and deleting are separate endpoints on purpose, so the same request never means two different things depending on the task's state.
]]> <![CDATA[Notifications are live]]> https://docs.nanako.org/changelog/2026/07/30/notifications 2026-07-30T00:00:00.000Z Nanako now tells you when something finishes instead of making you check.

Status checked 2026-09-10

This entry records the P0 notification release. The checked implementation still contains the in-app inbox, live SSE updates with polling fallback, preferences, per-authorized-app mute controls, and email delivery when its worker/channel is enabled. Browser Web Push and APNs remain future channels: there are no device registration endpoints, and their preference controls are disabled as unavailable. References below to push-subscription cleanup describe reserved model/session behavior, not a currently usable push channel.

What shipped​

  • Message center — an inbox in the top bar with an unread badge. Messages arrive without a page reload.
  • Email alerts — the same events can reach your inbox. Off by default for every category; you opt in.
  • Preferences page — decide per category and per channel what you want. Third-party apps you have authorised can be muted individually without revoking their access.
  • Translation completion is the first event wired up. A PDF translation that finishes — or fails — now notifies you.

Notes​

Notifications are delivered by a separate background process. If you self-host Nanako, enabling the feature also means deploying that process; the message center will otherwise fill up with items that never leave pending. See the deployment docs.

The P0 data model also tied future push subscriptions to login sessions so a device revocation could disable those subscriptions. Push delivery itself did not ship in P0 and is still unavailable in the checked implementation.

]]> <![CDATA[OAuth 2.0 documentation for third-party developers]]> https://docs.nanako.org/changelog/2026/07/30/oauth2-developer-docs 2026-07-30T00:00:00.000Z Everything you need to let people sign in to your product with their Nanako account is now documented: the flow, every endpoint and parameter, every scope and claim, every error, and the security requirements.

Added​

  • OAuth 2.0 — overview, supported client types, token lifetimes, and what the provider does and does not implement
  • Registering an application — developer approval, application creation, redirect URI rules and credential handling
  • Authorization code flow — the complete integration with runnable requests, including PKCE, refresh and revocation
  • Scopes — the four scopes, the claims each returns, and how scope is validated
  • Endpoint reference — every parameter and response field for the four OAuth endpoints
  • Errors — every error, its cause, and whether to retry
  • Security requirements — what an integration must get right

Notes​

Two limits are worth knowing before you start: the discovery document at /.well-known/openid-configuration lists endpoint URLs that do not resolve, so configure the endpoints by hand; and a browser-only application cannot complete the token exchange without an operator allowlist entry. Both are covered in the documentation.

]]> <![CDATA[docs.nanako.org is live]]> https://docs.nanako.org/changelog/2026/07/28/docs-site-launch 2026-07-28T00:00:00.000Z The Nanako ecosystem now has a public documentation site at docs.nanako.org.

Status checked 2026-09-10

This entry records the 2026-07-28 launch event. The repository still configures docs.nanako.org, bilingual Nanako docs, changelog search and conditional Cloudflare deployment, but repository configuration does not prove the site is currently reachable. Nanako remains the only docs section; NanoStart and NanoUptime are external first-party applications and still have no sections here. No OpenAPI renderer is wired into this site.

What shipped​

  • Nanako documentation with a bilingual skeleton (English default, Simplified Chinese under /zh-CN/)
  • Changelog — this page
  • Full-text search across both languages, including CJK tokenization
  • Continuous deployment — merging a change to docs-site/ on main publishes it automatically, with no manual step

How updates work​

Documentation lives in the main site repository alongside the code it describes, so a change to an API and the change to its documentation ship in the same commit and are reviewed in the same pull request.

What's next​

At launch, the plan was to add NanoStart and NanoUptime sections and generate an API reference from NanoUptime's machine-readable description. That paragraph was a roadmap statement, not a claim about the current site; see the status note above.

]]>