Contentstack Localization
Description
Advise developers on Contentstack localization: language setup, fallback chains, localized vs unlocalized entries, non-localizable fields, and multi-locale publishing.
When to Use
Use when developers ask about languages, fallback chains, localizing entries, non-localizable fields, or multi-locale publishing. Clarify whether the question concerns the CMS editorial experience or CDA delivery behavior.
User Problem
Developers need to design multilingual content delivery with correct fallback behavior, efficient editorial workflows, and minimal redundancy.
Success Criteria
Language hierarchy is correct and master language constraints are stated.
Fallback behavior is explained clearly, including chain traversal.
Field-level localization choices are practical and consistent.
Multi-locale publishing guidance is accurate and actionable.
Advice distinguishes editorial UI behavior from CDA behavior.
Expected Inputs
- Target languages and markets
- Fallback requirements
- Editorial workflow for translations
- Content shared across locales
Expected Outputs
- Language hierarchy recommendations
- Fallback chain design
- Non-localizable field guidance
- Publishing strategy for multiple locales
- CDA locale query guidance
Example User Requests
- How do I set up languages with fallback in Contentstack?
- What is the difference between a localized and unlocalized entry?
- Which fields should I mark as non-localizable?
- How do I publish content in multiple languages at once?
- What happens if a locale has no content?
Workflow Summary
Confirm target locales, markets, and whether the question is about CMS or CDA behavior.
Explain master language constraints and design the fallback chain.
Recommend which fields should remain non-localizable.
Describe localized vs unlocalized entry behavior and editorial impact.
Give CDA locale query guidance and multi-locale publishing strategy.
Instructions
[{"heading":"Master language","content":"State upfront that the master language is permanent, set at stack creation, and ends every fallback chain."},{"heading":"Fallback chain design","content":"Explain that each language can have one fallback language. Describe inheritance as a chain such as fr-ca -> fr-fr -> en-us (master). Warn that changing fallback relationships later affects existing content inheritance."},{"heading":"Localized vs unlocalized entries","content":"Clarify that a localized entry is an independent copy with its own version history, publishing status, and workflow state. An unlocalized entry inherits from its fallback chain. Localizing is a one-way operation per locale and entry."},{"heading":"Non-localizable fields","content":"Recommend marking structural or shared data as non-localizable, such as SKUs, prices, dates, coordinates, boolean flags, shared assets, and identifiers. Keep human-readable text fields localizable."},{"heading":"CDA locale queries","content":"Tell developers to pass locale explicitly in CDA requests. Use include_fallback=true when they want the full fallback chain to apply; without it, only the exact locale is checked."},{"heading":"Multi-locale publishing","content":"Explain that editors can publish multiple locale versions from the master language entry, subject to plan limits. Note that only the latest version of each localized entry is published, and localized entry versions can be deleted only from the master language entry's delete modal."}],
Security
Defaults
- Never expose secrets, tokens, or API keys in output or logs.
- Always use environment variables for credentials.
- Never hardcode secrets in scripts, examples, or instructions.
- Do not claim access to tools or connectors that are not explicitly available.
- Clearly separate verified facts from assumptions.
Destructive Actions
- Require explicit user confirmation before any destructive action.
- List exactly what will be changed or deleted before proceeding.
- Never auto-execute delete, overwrite, or publish operations.
Secrets
- Treat all tokens, passwords, and API keys as sensitive.
- Never echo or log secret values.
- Mask secrets in any output shown to users.
- Use environment variables exclusively for credential storage.
Environment Variables
- Document every required environment variable.
- Provide example values without real credentials.
- Validate presence of required env vars before execution.
- Never use default fallback values for secrets.
Product Context
-
- Description: Contentstack headless CMS: content types, entries, assets, environments, publishing, workflows, webhooks, and the Content Management API (CMA).
- Product safety rules: - Never expose management tokens or API keys.
- Always use environment variables for credentials.
- Route all CMA calls through server-side proxies in browser apps.
- Never hardcode stack API keys in client-side code.
- Default tools: ["CMA API", "Content Types", "Entries", "Assets", "Workflows", "Webhooks", "Environments", "Releases", "Publish Queue"]
- Default connectors: ["CMA Proxy", "Webhooks"]
1---2name: cms-localization-23description: Advise developers on Contentstack localization: language setup, fallback chains, localized vs unlocalized entries, non-localizable fields, and multi-locale publishing.4---56# Contentstack Localization78## Description910Advise developers on Contentstack localization: language setup, fallback chains, localized vs unlocalized entries, non-localizable fields, and multi-locale publishing.1112## When to Use1314Use when developers ask about languages, fallback chains, localizing entries, non-localizable fields, or multi-locale publishing. Clarify whether the question concerns the CMS editorial experience or CDA delivery behavior.1516## User Problem1718Developers need to design multilingual content delivery with correct fallback behavior, efficient editorial workflows, and minimal redundancy.1920## Success Criteria2122Language hierarchy is correct and master language constraints are stated.23Fallback behavior is explained clearly, including chain traversal.24Field-level localization choices are practical and consistent.25Multi-locale publishing guidance is accurate and actionable.26Advice distinguishes editorial UI behavior from CDA behavior.2728## Expected Inputs2930- Target languages and markets31- Fallback requirements32- Editorial workflow for translations33- Content shared across locales3435## Expected Outputs3637- Language hierarchy recommendations38- Fallback chain design39- Non-localizable field guidance40- Publishing strategy for multiple locales41- CDA locale query guidance4243## Example User Requests4445- How do I set up languages with fallback in Contentstack?46- What is the difference between a localized and unlocalized entry?47- Which fields should I mark as non-localizable?48- How do I publish content in multiple languages at once?49- What happens if a locale has no content?5051## Workflow Summary5253Confirm target locales, markets, and whether the question is about CMS or CDA behavior.54Explain master language constraints and design the fallback chain.55Recommend which fields should remain non-localizable.56Describe localized vs unlocalized entry behavior and editorial impact.57Give CDA locale query guidance and multi-locale publishing strategy.5859## Instructions6061[{"heading":"Master language","content":"State upfront that the master language is permanent, set at stack creation, and ends every fallback chain."},{"heading":"Fallback chain design","content":"Explain that each language can have one fallback language. Describe inheritance as a chain such as fr-ca -> fr-fr -> en-us (master). Warn that changing fallback relationships later affects existing content inheritance."},{"heading":"Localized vs unlocalized entries","content":"Clarify that a localized entry is an independent copy with its own version history, publishing status, and workflow state. An unlocalized entry inherits from its fallback chain. Localizing is a one-way operation per locale and entry."},{"heading":"Non-localizable fields","content":"Recommend marking structural or shared data as non-localizable, such as SKUs, prices, dates, coordinates, boolean flags, shared assets, and identifiers. Keep human-readable text fields localizable."},{"heading":"CDA locale queries","content":"Tell developers to pass locale explicitly in CDA requests. Use include_fallback=true when they want the full fallback chain to apply; without it, only the exact locale is checked."},{"heading":"Multi-locale publishing","content":"Explain that editors can publish multiple locale versions from the master language entry, subject to plan limits. Note that only the latest version of each localized entry is published, and localized entry versions can be deleted only from the master language entry's delete modal."}],6263## Security6465### Defaults6667- Never expose secrets, tokens, or API keys in output or logs.68- Always use environment variables for credentials.69- Never hardcode secrets in scripts, examples, or instructions.70- Do not claim access to tools or connectors that are not explicitly available.71- Clearly separate verified facts from assumptions.7273### Destructive Actions7475- Require explicit user confirmation before any destructive action.76- List exactly what will be changed or deleted before proceeding.77- Never auto-execute delete, overwrite, or publish operations.7879### Secrets8081- Treat all tokens, passwords, and API keys as sensitive.82- Never echo or log secret values.83- Mask secrets in any output shown to users.84- Use environment variables exclusively for credential storage.8586### Environment Variables8788- Document every required environment variable.89- Provide example values without real credentials.90- Validate presence of required env vars before execution.91- Never use default fallback values for secrets.9293## Product Context9495- - Product: CMS96- - Description: Contentstack headless CMS: content types, entries, assets, environments, publishing, workflows, webhooks, and the Content Management API (CMA).97- - Product safety rules: - Never expose management tokens or API keys.98- Always use environment variables for credentials.99- Route all CMA calls through server-side proxies in browser apps.100- Never hardcode stack API keys in client-side code.101- - Default tools: ["CMA API", "Content Types", "Entries", "Assets", "Workflows", "Webhooks", "Environments", "Releases", "Publish Queue"]102- - Default connectors: ["CMA Proxy", "Webhooks"]
contentstack