ワンクリックでManusで任意のスキルを実行

blocks-localization-configuration

スター0

フォーク3

更新日2026年7月14日 19:06

Configure app localization on a SELISE Blocks project via the localization API (`https://api.seliseblocks.com/localization/v4`): manage languages (`/Language/Gets|Save|Delete|SetDefault`), feature modules that group translation keys (`/Module/Gets|Save`), and translation keys with per-language values (`/Key/Save`, `/Key/SaveKeys`, `/Key/Gets`, `/Key/GetsByKeyNames`) — then generate the runtime language files (`/Key/GenerateUilmFile`) so the translations actually reach the app. Use whenever the user wants to set up translations/i18n for static UI content (page titles, labels, button text, descriptions), add or edit a language, create a translation module, add/translate keys, translate a batch of keys into multiple languages, or 'generate the language files' on Blocks. This is the admin/config side (translations are authored here); the frontend that loads and switches languages is blocks-localization-implementation. Requires impersonating into the project first.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

SELISEdigitalplatforms

SELISEdigitalplatforms/blocks-skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Blocks Localization — Configuration

Author the translations an app uses for its static content — page titles, labels, button text, descriptions — so it can render in multiple languages. The pipeline is: languages → modules → keys (with a value per language) → generate the runtime files. The frontend that consumes the result (a language switcher that loads and applies translations) is blocks-localization-implementation.

Base: https://api.seliseblocks.com/localization/v4 — PascalCase controllers (/Language/*, /Module/*, /Key/*). No /api/ prefix (the swagger's /api is not served).

Auth & keys — start here

Prerequisites: a Blocks account, at least one project, and a .env with BLOCKS_API_URL, BLOCKS_USERNAME, BLOCKS_PASSWORD. Missing or unknown — no .env, auth-login 401, empty Project/Gets — run the blocks-onboarding skill first.

Localization authoring is project configuration, so it runs inside a project/tenant — do the shared initial steps first: flows/get-into-project.md (login → list projects → impersonate). It yields:

ACCOUNT_TENANT — root/account tenant id. Used as x-blocks-key on every localization configuration call after impersonation.
PTENANT — the target project's tenant id → projectKey body field / ProjectKey query param. Not x-blocks-key on configuration calls.
PTOK — the impersonated access token valid for the project → Authorization: Bearer.

Strict rule: configuring localization uses x-blocks-key: ACCOUNT_TENANT + Authorization: Bearer PTOK + projectKey/ProjectKey: PTENANT. Never send PTENANT as x-blocks-key on /Language, /Module, or /Key calls.

⚠️ Do not swap the keys. Authoring happens after impersonation — PTOK carries project scope, but the header stays the root tenant. On PTOK expiry, renew with POST /iam/v4/auth-token then re-impersonate (get-into-project).

The pipeline

Step	Do	Flow
0	Get an impersonated project token	flows/get-into-project.md
1	Ensure the languages exist and pick the default	flows/languages-and-modules.md
2	Ensure the feature module(s) exist	flows/languages-and-modules.md
3	Create keys, fill a value per language (the translation), save	flows/translate-and-generate.md
4	Generate the runtime files — nothing reaches the app without this	flows/translate-and-generate.md

Full request/response contracts: endpoints.md.

Key concepts (from the live swagger)

Language — { itemId, languageName, languageCode, isDefault, projectKey }. languageCode is a culture like en-US, de-DE, bn-BD — the same value that appears as a resource's culture and as the Language query param at runtime. One language is the default (isDefault / /Language/SetDefault).
Module — a named group of keys for a feature area (e.g. common, login, dashboard): { itemId, moduleName, projectKey }. Keys belong to a module by moduleId; the runtime fetches translations per module (ModuleName). Keep a common module for shared strings.
Key — one translatable string: { keyName, moduleId, resources[], … }. keyName is the stable token the app references (e.g. LOGIN, SAVE_BUTTON). resources is the list of per-language values: [{ value, culture }] — one entry per language, where value is the translated text for that culture.
You (the agent) produce the translations. For each key, translate keyName (or the source-language value / context) into every configured language and put the result in the matching resources[].value. isPartiallyTranslated: true flags a key that doesn't yet cover all languages. (The platform also offers AI translation via /Key/TranslateKeys — optional; see endpoints.md — but the default here is that you fill the values.)
Generate or it didn't happen. Saved keys are staged; the app only sees them after POST /Key/GenerateUilmFile produces the runtime UILM language files. This is the localization equivalent of the data gateway's "reload".

Gotchas

GenerateUilmFile is mandatory after any key change, per module — skip it and the frontend's /Key/GetUilmFile won't reflect your edits.
Bulk over single. Use POST /Key/SaveKeys (an array) when saving more than one key; POST /Key/Save is for a single key.
culture must match a configured language's languageCode exactly (de-DE, not de), or the value won't map at runtime.
x-blocks-key = ACCOUNT_TENANT on configuration calls; projectKey/ProjectKey = PTENANT. Never send PTENANT as x-blocks-key when authoring translations.
Responses are { success, errorMessage, validationErrors[] } for saves (not the data-service envelope); check success and read validationErrors on failure.
New key? Set isNewKey: true and leave itemId: ""; editing? pass the existing itemId.

このリポジトリの他の Skills

同じリポジトリ

blocks-onboarding

SELISEdigitalplatforms/blocks-skills

Onboard a user into SELISE Blocks before any other Blocks skill can run — detect their current state and get them to a working setup: no Blocks account yet (guide signup at https://os.seliseblocks.com), account but no project (ask what they want to build and create the project via API — suggest a dev-only default), project but no credentials file (have the user create the `.env`), or everything present (verify and hand off). Also covers adding more environments (test/stg/uat/prod/…) to an existing project and deleting environments, via API. Use whenever a user is new to Blocks, asks how to get started / sign up / create a project / add or remove an environment, or when a prerequisite fails in another skill — missing `.env` or `BLOCKS_USERNAME`, `auth-login` returns 401/invalid credentials, or `Project/Gets` returns no projects. Only SIGNUP is portal-only (browser, not API); project and environment management is scriptable. Run the preflight here whenever the user's account/project state is unknown.

2026-07-140

blocks-data-gateway-configuration

SELISEdigitalplatforms/blocks-skills

Configure the data model of a SELISE Blocks project through the data service REST admin API (`https://api.seliseblocks.com/data/v4`): create and edit schemas/collections, add or remove properties/fields, add field validation rules (incl. the AI regex assistant), set schema/field access levels and data-access policies, and RELOAD so changes go live in the runtime gateway. Also covers mock/sample data inventory + deletion and schema-exchange (export/import a data model between projects). Use whenever the user wants to define, edit, secure, validate, reload, copy, or reset the DATA MODEL of a Blocks project — 'add a field to my schema', 'make this collection public', 'validate the email field', 'reload the schema', 'clone my schemas to staging', 'wipe the demo data'. This is the admin/portal side; for running GraphQL create/read/update/delete against the resulting schemas use blocks-data-gateway-crud, and for file/DMS storage use blocks-data-storage.

2026-07-140

blocks-data-gateway-crud

SELISEdigitalplatforms/blocks-skills

Implement GraphQL create/read/update/delete against a SELISE Blocks project's runtime data gateway (`POST https://api.seliseblocks.com/data/v4/gateway`). Covers discovering a schema's auto-generated operation names, writing the query (`get<Collection>` with where/paging/order), insert/update/delete mutations (and insertMany/updateMany/deleteMany), the result + ActionResponse shapes, and wiring it all into a frontend (React 19 / TanStack Query hooks). Use whenever the user wants to READ or WRITE actual data/records through a Blocks schema from an app or script — 'fetch products from my Blocks collection', 'insert a record via the gateway', 'write the update mutation', 'CRUD hooks for my schema', 'why does getOrders not exist on Query'. The schema must already be created + reloaded via blocks-data-gateway-configuration; for file storage use blocks-data-storage.

2026-07-140

blocks-data-storage

SELISEdigitalplatforms/blocks-skills

Store and serve files on a SELISE Blocks project via the data service's DMS (document management system) — the `/data/v4/Files/*` API. Covers the pre-signed-URL upload (get upload URL → PUT the file binary to storage, with the Azure `x-ms-blob-type` header when needed → get download URL), downloading/listing files, folders (create/list/delete), tags/metadata/versions, and deleting files. Use whenever the user wants to upload, download, browse, organize, or delete FILES/attachments/documents/images on Blocks — 'upload a PDF and get a link', 'attach an image to a record', 'let users download this file', 'create a folder and list its contents', 'get a presigned upload URL'. This is separate from the data model: to define schemas use blocks-data-gateway-configuration, and to CRUD records use blocks-data-gateway-crud (store a file here, keep its fileId in a schema field there).

2026-07-140

blocks-frontend-local-https

SELISEdigitalplatforms/blocks-skills

Run a frontend React app locally over HTTPS on its real project domain, using a locally-generated SSL certificate — required so SELISE Blocks SSO/OIDC login works, because the auth callback sets a Secure, domain-scoped session cookie that the browser rejects on plain http://localhost. The skill: discovers the project's domain from /os/v4/Project/Gets (projects[].applications[].domain, filtered by environment) or asks the user, adds a hosts entry mapping that domain to 127.0.0.1, generates a self-signed local cert for it with openssl (and trusts it), configures the dev server (Vite/CRA/Next) to serve https on that domain + port, and runs it at https://your.domain.com:PORT. Use whenever the user needs to run/test a Blocks app locally over HTTPS, fix 'SSO cookie not set / session lost on localhost', set up a local dev cert, serve a custom domain locally, or make the OIDC redirect work in local dev. A real/owned domain name is required to issue the cert — you cannot make one without a domain.

2026-07-140

blocks-iam-sso-oidc-configuration

SELISEdigitalplatforms/blocks-skills

Configure SSO / OIDC login for a SELISE Blocks project via the IAM admin API (`https://api.seliseblocks.com/iam/v4`): ensure a `blocks-oidc` identity provider exists, creating the OIDC client (`/oidc-clients`) and the identity provider (`/auth/identity-providers`) if they don't. Use whenever the user wants to SET UP / enable / configure single sign-on, OIDC, or an identity provider for their Blocks app — 'enable SSO for my project', 'configure OIDC login', 'register an OIDC client', 'add a blocks-oidc identity provider', 'set up authorization-code login on Blocks'. This is the admin/portal side and requires impersonating into the project first; once configured, wire the login into the app with blocks-iam-sso-oidc-implementation. If the app invites users via the portal or API, also wire an optional /activate page (blocks-iam-account) — not required for SSO login itself.

2026-07-140

name

blocks-localization-configuration

description

Blocks Localization — Configuration

Base: https://api.seliseblocks.com/localization/v4 — PascalCase controllers (/Language/*, /Module/*, /Key/*). No /api/ prefix (the swagger's /api is not served).

Auth & keys — start here

Prerequisites: a Blocks account, at least one project, and a .env with BLOCKS_API_URL, BLOCKS_USERNAME, BLOCKS_PASSWORD. Missing or unknown — no .env, auth-login 401, empty Project/Gets — run the blocks-onboarding skill first.

ACCOUNT_TENANT — root/account tenant id. Used as x-blocks-key on every localization configuration call after impersonation.
PTENANT — the target project's tenant id → projectKey body field / ProjectKey query param. Not x-blocks-key on configuration calls.
PTOK — the impersonated access token valid for the project → Authorization: Bearer.

⚠️ Do not swap the keys. Authoring happens after impersonation — PTOK carries project scope, but the header stays the root tenant. On PTOK expiry, renew with POST /iam/v4/auth-token then re-impersonate (get-into-project).

The pipeline

Step	Do	Flow
0	Get an impersonated project token	flows/get-into-project.md
1	Ensure the languages exist and pick the default	flows/languages-and-modules.md
2	Ensure the feature module(s) exist	flows/languages-and-modules.md
3	Create keys, fill a value per language (the translation), save	flows/translate-and-generate.md
4	Generate the runtime files — nothing reaches the app without this	flows/translate-and-generate.md

Full request/response contracts: endpoints.md.

Key concepts (from the live swagger)

Language — { itemId, languageName, languageCode, isDefault, projectKey }. languageCode is a culture like en-US, de-DE, bn-BD — the same value that appears as a resource's culture and as the Language query param at runtime. One language is the default (isDefault / /Language/SetDefault).
Module — a named group of keys for a feature area (e.g. common, login, dashboard): { itemId, moduleName, projectKey }. Keys belong to a module by moduleId; the runtime fetches translations per module (ModuleName). Keep a common module for shared strings.
Key — one translatable string: { keyName, moduleId, resources[], … }. keyName is the stable token the app references (e.g. LOGIN, SAVE_BUTTON). resources is the list of per-language values: [{ value, culture }] — one entry per language, where value is the translated text for that culture.
You (the agent) produce the translations. For each key, translate keyName (or the source-language value / context) into every configured language and put the result in the matching resources[].value. isPartiallyTranslated: true flags a key that doesn't yet cover all languages. (The platform also offers AI translation via /Key/TranslateKeys — optional; see endpoints.md — but the default here is that you fill the values.)
Generate or it didn't happen. Saved keys are staged; the app only sees them after POST /Key/GenerateUilmFile produces the runtime UILM language files. This is the localization equivalent of the data gateway's "reload".

Gotchas

GenerateUilmFile is mandatory after any key change, per module — skip it and the frontend's /Key/GetUilmFile won't reflect your edits.
Bulk over single. Use POST /Key/SaveKeys (an array) when saving more than one key; POST /Key/Save is for a single key.
culture must match a configured language's languageCode exactly (de-DE, not de), or the value won't map at runtime.
x-blocks-key = ACCOUNT_TENANT on configuration calls; projectKey/ProjectKey = PTENANT. Never send PTENANT as x-blocks-key when authoring translations.
Responses are { success, errorMessage, validationErrors[] } for saves (not the data-service envelope); check success and read validationErrors on failure.
New key? Set isNewKey: true and leave itemId: ""; editing? pass the existing itemId.