Context
The packages/demo package exists to showcase components in a realistic environment, but many demo components still contain hardcoded strings directly embedded in JSX such as button labels, headings, placeholder text, empty states, and helper messages.
While hardcoded text makes it faster to build an initial prototype, it creates friction once localization, customization, or white-label support becomes a requirement. Every hardcoded string becomes a hidden dependency that translators cannot access and consumers cannot override.
Moving these strings into props or i18n keys improves flexibility without changing the visual appearance of the demos. Consumers can customize wording, localization systems can provide translations, and future contributors avoid modifying component internals just to change text.
This task focuses purely on extracting display text while preserving the exact current behavior and appearance of the demo package.
Every string removed from component internals is one fewer future migration waiting to happen.
Before you start
Pull the latest main branch before creating your branch:
git checkout main
git pull --rebase origin main
git checkout -b chore/demo-localize
What needs doing
Search through the packages/demo directory for any user-facing text that is directly hardcoded inside components.
Examples include:
- Button labels
- Section headings
- Card titles
- Placeholder text
- Empty states
- Helper text
- Loading states
- Success and error messages
- Tooltip content
- Badge labels
- Table headers
- Demo descriptions
For every hardcoded string, determine whether it should become:
- A component prop, if the value is expected to vary between consumers.
- An i18n translation key, if the project already uses an existing localization framework or translation layer.
Examples:
Before
<Button>Get Started</Button>
After (prop-based)
<Button>{ctaLabel}</Button>interface DemoProps {
ctaLabel?: string;
}
export function Demo({
ctaLabel = "Get Started",
}: DemoProps) {
return <Button>{ctaLabel}</Button>;
}
Before
After (i18n-based)
<h2>{t("demo.welcomeBack")}</h2>
When using props, preserve existing behavior by providing sensible default values that match the current demo output exactly.
The goal is not to redesign demos or improve copywriting. The rendered UI before and after this change should be visually indistinguishable.
Do not:
- Change layouts
- Rename components unnecessarily
- Modify styling
- Refactor unrelated logic
- Introduce new dependencies solely for localization
- Replace dynamic strings that are already configurable
Focus only on extracting text that is currently fixed inside the component implementation.
If the repository already has an established localization convention, follow it consistently rather than introducing a new pattern.
Acceptance criteria
How to verify
Run the demo application locally and compare the affected components before and after the change.
Verify that:
- All labels render exactly as before.
- No text is missing or replaced with translation keys.
- Components behave correctly when custom prop values are supplied.
- Localization keys resolve correctly if using the project's i18n system.
If visual regression tooling exists in the repository, run it as part of verification.
pnpm test
pnpm lint
pnpm typecheck
If Storybook or demo snapshots exist:
Confirm that screenshots or snapshots remain unchanged apart from expected internal implementation differences.
Commit guidelines
git add packages/demo
git commit -m "chore(demo): replace hardcoded labels with props and i18n keys"
git push origin chore/demo-localize
A single commit is sufficient unless the repository maintainers prefer separating prop extraction from i18n changes.
Branch / Commit
Suggested branch
Commit example
chore(demo): replace hardcoded label with prop
Pull Request notes
Include a short summary of:
- Which demo components were updated.
- Whether props or i18n keys were used for each change.
- Any strings intentionally left hardcoded and the reasoning behind that decision.
Before pushing your branch, always rebase on the latest main branch:
git pull --rebase origin main
Resolve conflicts locally before opening the pull request.
Resources
Context
The
packages/demopackage exists to showcase components in a realistic environment, but many demo components still contain hardcoded strings directly embedded in JSX such as button labels, headings, placeholder text, empty states, and helper messages.While hardcoded text makes it faster to build an initial prototype, it creates friction once localization, customization, or white-label support becomes a requirement. Every hardcoded string becomes a hidden dependency that translators cannot access and consumers cannot override.
Moving these strings into props or i18n keys improves flexibility without changing the visual appearance of the demos. Consumers can customize wording, localization systems can provide translations, and future contributors avoid modifying component internals just to change text.
This task focuses purely on extracting display text while preserving the exact current behavior and appearance of the demo package.
Every string removed from component internals is one fewer future migration waiting to happen.
Before you start
Pull the latest
mainbranch before creating your branch:What needs doing
Search through the
packages/demodirectory for any user-facing text that is directly hardcoded inside components.Examples include:
For every hardcoded string, determine whether it should become:
Examples:
Before
After (prop-based)
Before
After (i18n-based)
When using props, preserve existing behavior by providing sensible default values that match the current demo output exactly.
The goal is not to redesign demos or improve copywriting. The rendered UI before and after this change should be visually indistinguishable.
Do not:
Focus only on extracting text that is currently fixed inside the component implementation.
If the repository already has an established localization convention, follow it consistently rather than introducing a new pattern.
Acceptance criteria
packages/demohave been reviewedHow to verify
Run the demo application locally and compare the affected components before and after the change.
Verify that:
If visual regression tooling exists in the repository, run it as part of verification.
pnpm test pnpm lint pnpm typecheckIf Storybook or demo snapshots exist:
Confirm that screenshots or snapshots remain unchanged apart from expected internal implementation differences.
Commit guidelines
git add packages/demo git commit -m "chore(demo): replace hardcoded labels with props and i18n keys" git push origin chore/demo-localizeA single commit is sufficient unless the repository maintainers prefer separating prop extraction from i18n changes.
Branch / Commit
Suggested branch
Commit example
Pull Request notes
Include a short summary of:
Before pushing your branch, always rebase on the latest
mainbranch:Resolve conflicts locally before opening the pull request.
Resources