Skip to content

chore(localizations): Generate missing API keys locales #6223

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jun 30, 2025

Conversation

wobsoriano
Copy link
Member

@wobsoriano wobsoriano commented Jun 30, 2025

Description

Checklist

  • pnpm test runs as expected.
  • pnpm build runs as expected.
  • (If applicable) JSDoc comments have been added or updated for any package exports
  • (If applicable) Documentation has been updated

Type of change

  • 🐛 Bug fix
  • 🌟 New feature
  • 🔨 Breaking change
  • 📖 Refactoring / dependency upgrade / documentation
  • other:

Summary by CodeRabbit

  • New Features

    • Added placeholders for API key management, billing history, payment statements, and subscription management across all supported languages.
    • Expanded localization files with new sections for API keys, payment history tables, statements, and related navigation items in organization and user profile pages.
    • Introduced new untranslated keys for form fields and UI labels related to API keys and billing.
  • Chores

    • Added a changeset entry documenting the update for localization placeholders.

Copy link

changeset-bot bot commented Jun 30, 2025

🦋 Changeset detected

Latest commit: d49bd74

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages
Name Type
@clerk/localizations Patch
@clerk/clerk-js Patch
@clerk/chrome-extension Patch
@clerk/clerk-expo Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copy link

vercel bot commented Jun 30, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
clerk-js-sandbox ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 30, 2025 5:06pm

@wobsoriano wobsoriano marked this pull request as ready for review June 30, 2025 17:02
Copy link
Contributor

coderabbitai bot commented Jun 30, 2025

📝 Walkthrough

Walkthrough

This change introduces a new changeset file documenting a patch update for the @clerk/localizations package. The update adds numerous new localization keys across many language resource files, primarily for API key management, billing, payment history, statements, and organization/user profile UI sections. The additions include new nested structures and placeholders for API key actions, form fields, confirmation dialogs, payment tables, subscription lists, and related navigation entries. Most new keys are initialized as undefined placeholders for future translations, with some actual translations provided in specific locales. No existing keys or translations are removed or altered; the changes are purely additive and structural.

Possibly related PRs

Suggested reviewers

  • tmilewski

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (2)
packages/localizations/src/vi-VN.ts (1)

245-251: Track undefined placeholders for future translation work.

The extensive billing and payment history sections have been added consistently across both profile types. While the undefined placeholders are appropriate, consider tracking these for future Vietnamese translation work to ensure complete localization coverage.

Consider adding a comment or tracking mechanism to identify which keys still need Vietnamese translations, as this represents a significant number of UI elements that will display as missing translations until completed.

Also applies to: 270-270, 275-285, 289-291, 893-899, 918-918, 923-933, 937-939

packages/localizations/src/hu-HU.ts (1)

236-238: LGTM: Systematic addition of billing and API key management keys.

The comprehensive additions for billing, payment history, statements, and API key management maintain perfect structural consistency with the Vietnamese file. This systematic approach ensures uniform localization infrastructure across languages.

The Hungarian file follows the same pattern of extensive undefined placeholders. Consider implementing a centralized tracking system for incomplete translations across all locale files to manage the translation workload effectively.

Also applies to: 244-250, 269-269, 274-284, 288-290, 358-358, 877-879, 896-902, 921-921, 926-936, 940-942, 1062-1062

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 01a0f29 and d49bd74.

📒 Files selected for processing (42)
  • .changeset/eleven-pigs-juggle.md (1 hunks)
  • packages/localizations/src/ar-SA.ts (12 hunks)
  • packages/localizations/src/be-BY.ts (12 hunks)
  • packages/localizations/src/bg-BG.ts (12 hunks)
  • packages/localizations/src/ca-ES.ts (12 hunks)
  • packages/localizations/src/cs-CZ.ts (12 hunks)
  • packages/localizations/src/da-DK.ts (12 hunks)
  • packages/localizations/src/de-DE.ts (7 hunks)
  • packages/localizations/src/el-GR.ts (12 hunks)
  • packages/localizations/src/en-GB.ts (12 hunks)
  • packages/localizations/src/en-US.ts (7 hunks)
  • packages/localizations/src/es-CR.ts (15 hunks)
  • packages/localizations/src/es-ES.ts (12 hunks)
  • packages/localizations/src/es-MX.ts (12 hunks)
  • packages/localizations/src/fi-FI.ts (12 hunks)
  • packages/localizations/src/fr-FR.ts (12 hunks)
  • packages/localizations/src/he-IL.ts (12 hunks)
  • packages/localizations/src/hr-HR.ts (12 hunks)
  • packages/localizations/src/hu-HU.ts (12 hunks)
  • packages/localizations/src/id-ID.ts (12 hunks)
  • packages/localizations/src/is-IS.ts (12 hunks)
  • packages/localizations/src/it-IT.ts (12 hunks)
  • packages/localizations/src/ja-JP.ts (12 hunks)
  • packages/localizations/src/ko-KR.ts (12 hunks)
  • packages/localizations/src/mn-MN.ts (12 hunks)
  • packages/localizations/src/nb-NO.ts (12 hunks)
  • packages/localizations/src/nl-BE.ts (12 hunks)
  • packages/localizations/src/nl-NL.ts (12 hunks)
  • packages/localizations/src/pl-PL.ts (12 hunks)
  • packages/localizations/src/pt-BR.ts (12 hunks)
  • packages/localizations/src/pt-PT.ts (12 hunks)
  • packages/localizations/src/ro-RO.ts (12 hunks)
  • packages/localizations/src/ru-RU.ts (12 hunks)
  • packages/localizations/src/sk-SK.ts (12 hunks)
  • packages/localizations/src/sr-RS.ts (12 hunks)
  • packages/localizations/src/sv-SE.ts (12 hunks)
  • packages/localizations/src/th-TH.ts (12 hunks)
  • packages/localizations/src/tr-TR.ts (12 hunks)
  • packages/localizations/src/uk-UA.ts (12 hunks)
  • packages/localizations/src/vi-VN.ts (12 hunks)
  • packages/localizations/src/zh-CN.ts (12 hunks)
  • packages/localizations/src/zh-TW.ts (12 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
`**/*.{js,jsx,ts,tsx}`: All code must pass ESLint checks with the project's conf...

**/*.{js,jsx,ts,tsx}: All code must pass ESLint checks with the project's configuration
Use Prettier for consistent code formatting
Follow established naming conventions (PascalCase for components, camelCase for variables)
Maintain comprehensive JSDoc comments for public APIs
Use dynamic imports for optional features
All public APIs must be documented with JSDoc
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Validate all inputs and sanitize outputs
Implement proper logging with different levels

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/localizations/src/pt-PT.ts
  • packages/localizations/src/nb-NO.ts
  • packages/localizations/src/is-IS.ts
  • packages/localizations/src/nl-NL.ts
  • packages/localizations/src/bg-BG.ts
  • packages/localizations/src/hr-HR.ts
  • packages/localizations/src/en-US.ts
  • packages/localizations/src/pt-BR.ts
  • packages/localizations/src/es-MX.ts
  • packages/localizations/src/sr-RS.ts
  • packages/localizations/src/da-DK.ts
  • packages/localizations/src/be-BY.ts
  • packages/localizations/src/ar-SA.ts
  • packages/localizations/src/es-ES.ts
  • packages/localizations/src/it-IT.ts
  • packages/localizations/src/he-IL.ts
  • packages/localizations/src/sv-SE.ts
  • packages/localizations/src/de-DE.ts
  • packages/localizations/src/sk-SK.ts
  • packages/localizations/src/mn-MN.ts
  • packages/localizations/src/id-ID.ts
  • packages/localizations/src/el-GR.ts
  • packages/localizations/src/ja-JP.ts
  • packages/localizations/src/pl-PL.ts
  • packages/localizations/src/ru-RU.ts
  • packages/localizations/src/tr-TR.ts
  • packages/localizations/src/th-TH.ts
  • packages/localizations/src/uk-UA.ts
  • packages/localizations/src/ko-KR.ts
  • packages/localizations/src/zh-CN.ts
  • packages/localizations/src/nl-BE.ts
  • packages/localizations/src/fi-FI.ts
  • packages/localizations/src/zh-TW.ts
  • packages/localizations/src/fr-FR.ts
  • packages/localizations/src/ro-RO.ts
  • packages/localizations/src/vi-VN.ts
  • packages/localizations/src/hu-HU.ts
  • packages/localizations/src/cs-CZ.ts
  • packages/localizations/src/ca-ES.ts
  • packages/localizations/src/en-GB.ts
  • packages/localizations/src/es-CR.ts
`packages/**/*.ts`: TypeScript is required for all packages

packages/**/*.ts: TypeScript is required for all packages

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/localizations/src/pt-PT.ts
  • packages/localizations/src/nb-NO.ts
  • packages/localizations/src/is-IS.ts
  • packages/localizations/src/nl-NL.ts
  • packages/localizations/src/bg-BG.ts
  • packages/localizations/src/hr-HR.ts
  • packages/localizations/src/en-US.ts
  • packages/localizations/src/pt-BR.ts
  • packages/localizations/src/es-MX.ts
  • packages/localizations/src/sr-RS.ts
  • packages/localizations/src/da-DK.ts
  • packages/localizations/src/be-BY.ts
  • packages/localizations/src/ar-SA.ts
  • packages/localizations/src/es-ES.ts
  • packages/localizations/src/it-IT.ts
  • packages/localizations/src/he-IL.ts
  • packages/localizations/src/sv-SE.ts
  • packages/localizations/src/de-DE.ts
  • packages/localizations/src/sk-SK.ts
  • packages/localizations/src/mn-MN.ts
  • packages/localizations/src/id-ID.ts
  • packages/localizations/src/el-GR.ts
  • packages/localizations/src/ja-JP.ts
  • packages/localizations/src/pl-PL.ts
  • packages/localizations/src/ru-RU.ts
  • packages/localizations/src/tr-TR.ts
  • packages/localizations/src/th-TH.ts
  • packages/localizations/src/uk-UA.ts
  • packages/localizations/src/ko-KR.ts
  • packages/localizations/src/zh-CN.ts
  • packages/localizations/src/nl-BE.ts
  • packages/localizations/src/fi-FI.ts
  • packages/localizations/src/zh-TW.ts
  • packages/localizations/src/fr-FR.ts
  • packages/localizations/src/ro-RO.ts
  • packages/localizations/src/vi-VN.ts
  • packages/localizations/src/hu-HU.ts
  • packages/localizations/src/cs-CZ.ts
  • packages/localizations/src/ca-ES.ts
  • packages/localizations/src/en-GB.ts
  • packages/localizations/src/es-CR.ts
`packages/**/*.{ts,tsx,d.ts}`: Packages should export TypeScript types alongside runtime code

packages/**/*.{ts,tsx,d.ts}: Packages should export TypeScript types alongside runtime code

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/localizations/src/pt-PT.ts
  • packages/localizations/src/nb-NO.ts
  • packages/localizations/src/is-IS.ts
  • packages/localizations/src/nl-NL.ts
  • packages/localizations/src/bg-BG.ts
  • packages/localizations/src/hr-HR.ts
  • packages/localizations/src/en-US.ts
  • packages/localizations/src/pt-BR.ts
  • packages/localizations/src/es-MX.ts
  • packages/localizations/src/sr-RS.ts
  • packages/localizations/src/da-DK.ts
  • packages/localizations/src/be-BY.ts
  • packages/localizations/src/ar-SA.ts
  • packages/localizations/src/es-ES.ts
  • packages/localizations/src/it-IT.ts
  • packages/localizations/src/he-IL.ts
  • packages/localizations/src/sv-SE.ts
  • packages/localizations/src/de-DE.ts
  • packages/localizations/src/sk-SK.ts
  • packages/localizations/src/mn-MN.ts
  • packages/localizations/src/id-ID.ts
  • packages/localizations/src/el-GR.ts
  • packages/localizations/src/ja-JP.ts
  • packages/localizations/src/pl-PL.ts
  • packages/localizations/src/ru-RU.ts
  • packages/localizations/src/tr-TR.ts
  • packages/localizations/src/th-TH.ts
  • packages/localizations/src/uk-UA.ts
  • packages/localizations/src/ko-KR.ts
  • packages/localizations/src/zh-CN.ts
  • packages/localizations/src/nl-BE.ts
  • packages/localizations/src/fi-FI.ts
  • packages/localizations/src/zh-TW.ts
  • packages/localizations/src/fr-FR.ts
  • packages/localizations/src/ro-RO.ts
  • packages/localizations/src/vi-VN.ts
  • packages/localizations/src/hu-HU.ts
  • packages/localizations/src/cs-CZ.ts
  • packages/localizations/src/ca-ES.ts
  • packages/localizations/src/en-GB.ts
  • packages/localizations/src/es-CR.ts
`**/*.{ts,tsx}`: Use proper TypeScript error types

**/*.{ts,tsx}: Use proper TypeScript error types

📄 Source: CodeRabbit Inference Engine (.cursor/rules/development.mdc)

List of files the instruction was applied to:

  • packages/localizations/src/pt-PT.ts
  • packages/localizations/src/nb-NO.ts
  • packages/localizations/src/is-IS.ts
  • packages/localizations/src/nl-NL.ts
  • packages/localizations/src/bg-BG.ts
  • packages/localizations/src/hr-HR.ts
  • packages/localizations/src/en-US.ts
  • packages/localizations/src/pt-BR.ts
  • packages/localizations/src/es-MX.ts
  • packages/localizations/src/sr-RS.ts
  • packages/localizations/src/da-DK.ts
  • packages/localizations/src/be-BY.ts
  • packages/localizations/src/ar-SA.ts
  • packages/localizations/src/es-ES.ts
  • packages/localizations/src/it-IT.ts
  • packages/localizations/src/he-IL.ts
  • packages/localizations/src/sv-SE.ts
  • packages/localizations/src/de-DE.ts
  • packages/localizations/src/sk-SK.ts
  • packages/localizations/src/mn-MN.ts
  • packages/localizations/src/id-ID.ts
  • packages/localizations/src/el-GR.ts
  • packages/localizations/src/ja-JP.ts
  • packages/localizations/src/pl-PL.ts
  • packages/localizations/src/ru-RU.ts
  • packages/localizations/src/tr-TR.ts
  • packages/localizations/src/th-TH.ts
  • packages/localizations/src/uk-UA.ts
  • packages/localizations/src/ko-KR.ts
  • packages/localizations/src/zh-CN.ts
  • packages/localizations/src/nl-BE.ts
  • packages/localizations/src/fi-FI.ts
  • packages/localizations/src/zh-TW.ts
  • packages/localizations/src/fr-FR.ts
  • packages/localizations/src/ro-RO.ts
  • packages/localizations/src/vi-VN.ts
  • packages/localizations/src/hu-HU.ts
  • packages/localizations/src/cs-CZ.ts
  • packages/localizations/src/ca-ES.ts
  • packages/localizations/src/en-GB.ts
  • packages/localizations/src/es-CR.ts
`packages/localizations/**/*`: Localization files must be located in 'packages/localizations/'.

packages/localizations/**/*: Localization files must be located in 'packages/localizations/'.

📄 Source: CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

List of files the instruction was applied to:

  • packages/localizations/src/pt-PT.ts
  • packages/localizations/src/nb-NO.ts
  • packages/localizations/src/is-IS.ts
  • packages/localizations/src/nl-NL.ts
  • packages/localizations/src/bg-BG.ts
  • packages/localizations/src/hr-HR.ts
  • packages/localizations/src/en-US.ts
  • packages/localizations/src/pt-BR.ts
  • packages/localizations/src/es-MX.ts
  • packages/localizations/src/sr-RS.ts
  • packages/localizations/src/da-DK.ts
  • packages/localizations/src/be-BY.ts
  • packages/localizations/src/ar-SA.ts
  • packages/localizations/src/es-ES.ts
  • packages/localizations/src/it-IT.ts
  • packages/localizations/src/he-IL.ts
  • packages/localizations/src/sv-SE.ts
  • packages/localizations/src/de-DE.ts
  • packages/localizations/src/sk-SK.ts
  • packages/localizations/src/mn-MN.ts
  • packages/localizations/src/id-ID.ts
  • packages/localizations/src/el-GR.ts
  • packages/localizations/src/ja-JP.ts
  • packages/localizations/src/pl-PL.ts
  • packages/localizations/src/ru-RU.ts
  • packages/localizations/src/tr-TR.ts
  • packages/localizations/src/th-TH.ts
  • packages/localizations/src/uk-UA.ts
  • packages/localizations/src/ko-KR.ts
  • packages/localizations/src/zh-CN.ts
  • packages/localizations/src/nl-BE.ts
  • packages/localizations/src/fi-FI.ts
  • packages/localizations/src/zh-TW.ts
  • packages/localizations/src/fr-FR.ts
  • packages/localizations/src/ro-RO.ts
  • packages/localizations/src/vi-VN.ts
  • packages/localizations/src/hu-HU.ts
  • packages/localizations/src/cs-CZ.ts
  • packages/localizations/src/ca-ES.ts
  • packages/localizations/src/en-GB.ts
  • packages/localizations/src/es-CR.ts
`**/*.{ts,tsx}`: Always define explicit return types for functions, especially p...

**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs
Use proper type annotations for variables and parameters where inference isn't clear
Avoid any type - prefer unknown when type is uncertain, then narrow with type guards
Use interface for object shapes that might be extended
Use type for unions, primitives, and computed types
Prefer readonly properties for immutable data structures
Use private for internal implementation details
Use protected for inheritance hierarchies
Use public explicitly for clarity in public APIs
Prefer readonly for properties that shouldn't change after construction
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Document public functions and APIs with JSDoc-style comments including @param, @returns, @throws, and @example
Define custom error classes for domain-specific errors
Use the Result pattern for error handling instead of throwing exceptions
Use optional chaining and nullish coalescing for safe property access
Let TypeScript infer types when types are obvious
Use const assertions for literal types: as const
Use satisfies operator for type checking without widening
Use readonly arrays and objects for immutability
Use immutable update patterns (spread, etc.) for objects and arrays
Use lazy loading for large types
Prefer unknown over any for performance
Use type-only imports: import type { ... }
Use branded types for domain safety
No any types without justification
Proper error handling with typed errors
Consistent use of readonly for immutable data
Proper generic constraints in TypeScript generics
No unused type parameters in generics
Proper use of utility types instead of manual type construction
Type-only imports where possible for performance
Proper tree-shaking friendly exports
No circular dependencies
Efficient type computations (avoid deep recursion)

📄 Source: CodeRabbit Inference Engine (.cursor/rules/typescript.mdc)

List of files the instruction was applied to:

  • packages/localizations/src/pt-PT.ts
  • packages/localizations/src/nb-NO.ts
  • packages/localizations/src/is-IS.ts
  • packages/localizations/src/nl-NL.ts
  • packages/localizations/src/bg-BG.ts
  • packages/localizations/src/hr-HR.ts
  • packages/localizations/src/en-US.ts
  • packages/localizations/src/pt-BR.ts
  • packages/localizations/src/es-MX.ts
  • packages/localizations/src/sr-RS.ts
  • packages/localizations/src/da-DK.ts
  • packages/localizations/src/be-BY.ts
  • packages/localizations/src/ar-SA.ts
  • packages/localizations/src/es-ES.ts
  • packages/localizations/src/it-IT.ts
  • packages/localizations/src/he-IL.ts
  • packages/localizations/src/sv-SE.ts
  • packages/localizations/src/de-DE.ts
  • packages/localizations/src/sk-SK.ts
  • packages/localizations/src/mn-MN.ts
  • packages/localizations/src/id-ID.ts
  • packages/localizations/src/el-GR.ts
  • packages/localizations/src/ja-JP.ts
  • packages/localizations/src/pl-PL.ts
  • packages/localizations/src/ru-RU.ts
  • packages/localizations/src/tr-TR.ts
  • packages/localizations/src/th-TH.ts
  • packages/localizations/src/uk-UA.ts
  • packages/localizations/src/ko-KR.ts
  • packages/localizations/src/zh-CN.ts
  • packages/localizations/src/nl-BE.ts
  • packages/localizations/src/fi-FI.ts
  • packages/localizations/src/zh-TW.ts
  • packages/localizations/src/fr-FR.ts
  • packages/localizations/src/ro-RO.ts
  • packages/localizations/src/vi-VN.ts
  • packages/localizations/src/hu-HU.ts
  • packages/localizations/src/cs-CZ.ts
  • packages/localizations/src/ca-ES.ts
  • packages/localizations/src/en-GB.ts
  • packages/localizations/src/es-CR.ts
🧠 Learnings (7)
📓 Common learnings
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/development.mdc:0-0
Timestamp: 2025-06-30T10:29:42.997Z
Learning: Update documentation for API changes
Learnt from: jacekradko
PR: clerk/javascript#5905
File: .changeset/six-ears-wash.md:1-3
Timestamp: 2025-06-26T03:27:05.535Z
Learning: In the Clerk JavaScript repository, changeset headers support single quotes syntax (e.g., '@clerk/backend': minor) and work fine with their current changesets integration, so there's no need to change them to double quotes.
Learnt from: wobsoriano
PR: clerk/javascript#6163
File: packages/backend/src/api/endpoints/APIKeysApi.ts:60-70
Timestamp: 2025-06-20T17:44:17.570Z
Learning: The Clerk codebase uses POST method for API key update operations instead of the typical PATCH method, as clarified by the maintainer wobsoriano.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to packages/{clerk-js,elements,themes}/**/* : Visual regression testing should be performed for UI components.
.changeset/eleven-pigs-juggle.md (2)
Learnt from: dstaley
PR: clerk/javascript#6116
File: .changeset/tangy-garlics-say.md:1-2
Timestamp: 2025-06-13T16:09:53.061Z
Learning: In the Clerk JavaScript repository, contributors create intentionally empty changeset files (containing only the YAML delimiters) when a PR touches only non-published parts of the codebase (e.g., sandbox assets). This signals that no package release is required, so such changesets should not be flagged as missing content.
Learnt from: CR
PR: clerk/javascript#0
File: .cursor/rules/monorepo.mdc:0-0
Timestamp: 2025-06-30T10:30:56.197Z
Learning: Applies to .changeset/config.json : Automated releases must be managed with Changesets.
packages/localizations/src/ar-SA.ts (1)
Learnt from: wobsoriano
PR: clerk/javascript#5858
File: packages/clerk-js/src/core/modules/apiKeys/index.ts:84-97
Timestamp: 2025-06-10T17:35:08.986Z
Learning: In the APIKeys service methods (packages/clerk-js/src/core/modules/apiKeys/index.ts), error handling is intentionally delegated to the component level rather than being implemented within the service methods themselves. This architectural pattern allows calling components to handle errors according to their specific UI needs.
packages/localizations/src/id-ID.ts (1)
Learnt from: wobsoriano
PR: clerk/javascript#5858
File: packages/clerk-js/src/core/modules/apiKeys/index.ts:84-97
Timestamp: 2025-06-10T17:35:08.986Z
Learning: In the APIKeys service methods (packages/clerk-js/src/core/modules/apiKeys/index.ts), error handling is intentionally delegated to the component level rather than being implemented within the service methods themselves. This architectural pattern allows calling components to handle errors according to their specific UI needs.
packages/localizations/src/nl-BE.ts (1)
Learnt from: wobsoriano
PR: clerk/javascript#5858
File: packages/clerk-js/src/core/modules/apiKeys/index.ts:84-97
Timestamp: 2025-06-10T17:35:08.986Z
Learning: In the APIKeys service methods (packages/clerk-js/src/core/modules/apiKeys/index.ts), error handling is intentionally delegated to the component level rather than being implemented within the service methods themselves. This architectural pattern allows calling components to handle errors according to their specific UI needs.
packages/localizations/src/cs-CZ.ts (1)
Learnt from: wobsoriano
PR: clerk/javascript#5858
File: packages/clerk-js/src/core/modules/apiKeys/index.ts:84-97
Timestamp: 2025-06-10T17:35:08.986Z
Learning: In the APIKeys service methods (packages/clerk-js/src/core/modules/apiKeys/index.ts), error handling is intentionally delegated to the component level rather than being implemented within the service methods themselves. This architectural pattern allows calling components to handle errors according to their specific UI needs.
packages/localizations/src/en-GB.ts (1)
Learnt from: wobsoriano
PR: clerk/javascript#5858
File: packages/clerk-js/src/core/modules/apiKeys/index.ts:84-97
Timestamp: 2025-06-10T17:35:08.986Z
Learning: In the APIKeys service methods (packages/clerk-js/src/core/modules/apiKeys/index.ts), error handling is intentionally delegated to the component level rather than being implemented within the service methods themselves. This architectural pattern allows calling components to handle errors according to their specific UI needs.
⏰ Context from checks skipped due to timeout of 90000ms (5)
  • GitHub Check: Build Packages
  • GitHub Check: Formatting | Dedupe | Changeset
  • GitHub Check: semgrep-cloud-platform/scan
  • GitHub Check: semgrep/ci
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (155)
packages/localizations/src/pt-PT.ts (5)

17-49: New API keys localization structure looks well-organized.

The new apiKeys section provides comprehensive coverage for API key management features including actions, form fields, expiration options, and confirmation dialogs. The nested structure for revokeConfirmation is properly organized.


172-174: API key form field placeholders and labels properly added.

The new form field placeholders and labels for API key description, expiration date, and name follow the existing naming conventions and are correctly positioned within the form field sections.

Also applies to: 189-193


93-93: Commerce section enhancements align with billing features.

The addition of pastDueNotice, credit, and totalDue keys in the commerce section supports the expanded billing functionality mentioned in the AI summary.

Also applies to: 99-99, 138-138


236-238: Organization profile billing sections properly structured.

The new billing-related sections (apiKeysPage, paymentHistorySection, statementsSection) are well-organized with appropriate table headers and empty state messages. The structure is consistent with existing profile sections.

Also applies to: 244-250, 269-269, 274-284, 288-290


357-357: User profile and navigation updates maintain consistency.

The parallel additions to userProfile mirror the organization profile structure, and the apiKeys navigation entry is properly added to both organization and user profile navbars.

Also applies to: 875-877, 895-901, 920-920, 925-935, 939-941, 1059-1059

packages/localizations/src/be-BY.ts (6)

17-49: API keys section structure matches Portuguese locale.

The apiKeys section structure is identical to the pt-PT file, which ensures consistency across locales. All keys are properly set to undefined as placeholders.


173-175: Form field additions maintain consistency.

The API key form field placeholders and labels are positioned identically to the Portuguese file and follow the established naming conventions.

Also applies to: 191-193


93-93: Commerce section updates align with other locale.

The pastDueNotice, credit, and totalDue additions match the Portuguese file structure exactly, maintaining cross-locale consistency.

Also applies to: 99-99, 138-138


238-240: Billing sections properly mirror Portuguese structure.

The organization profile billing sections (apiKeysPage, paymentHistorySection, statementsSection) have identical structure and key names as the Portuguese file, ensuring consistent feature coverage.

Also applies to: 246-252, 271-271, 276-286, 290-292


359-359: User profile sections maintain structural consistency.

The user profile additions exactly mirror both the organization profile structure within this file and the Portuguese file structure, demonstrating good consistency in the localization approach.

Also applies to: 882-884, 902-908, 927-927, 932-942, 946-948, 1068-1068


17-49: Excellent consistency with Portuguese locale changes.

The Belarusian file changes are structurally identical to the Portuguese file, which is exactly what we want to see in a multi-locale update. This ensures that:

  1. All locales will support the same features once translated
  2. The codebase can rely on consistent key structures
  3. Translation workflows can process all locales uniformly

The use of undefined placeholders is consistent and appropriate for indicating translation work needed.

Also applies to: 173-175, 191-193, 238-292, 359-359, 882-948, 1068-1068

packages/localizations/src/nb-NO.ts (6)

17-49: Well-structured API key management section.

The new apiKeys section provides comprehensive coverage for API key management features including form actions, expiration options, usage tracking, and revocation confirmation dialogs. The hierarchical structure and consistent use of undefined placeholders follows the expected pattern for community localization files.


172-174: Consistent form field additions for API keys.

The new form field placeholders and labels for API key description, expiration date, and name are properly integrated with the existing form field structure.

Also applies to: 189-191


237-238: Proper integration of API keys in organization profile.

The addition of apiKeysPage and corresponding navbar entry maintains consistency with the existing profile structure.

Also applies to: 358-358


244-250: Comprehensive billing section enhancements.

The new payment history, statements sections, and subscription table headers provide complete billing management capabilities. The structure aligns well with the existing billing page organization.

Also applies to: 269-269, 274-284, 288-290


875-877: Consistent user profile additions.

The API keys integration in user profile mirrors the organization profile structure, maintaining consistency across the application.

Also applies to: 1058-1058


93-93: Commerce section extensions.

The new commerce keys (pastDueNotice, credit, totalDue) complete the billing workflow terminology.

Also applies to: 99-99, 138-138

packages/localizations/src/nl-NL.ts (1)

17-49: Excellent consistency with Norwegian localization structure.

The Dutch localization file perfectly mirrors the structural changes made to the Norwegian file, maintaining consistency across locale implementations. The systematic addition of API key management features, billing sections, and form fields with undefined placeholders follows the established pattern for community-contributed localization files. This approach facilitates future translation work while providing a complete structural foundation.

Also applies to: 172-174, 189-191, 236-238, 244-250, 269-269, 274-284, 288-290, 358-358, 875-877, 895-901, 920-920, 925-935, 939-941, 1058-1058, 93-93, 99-99, 138-138

packages/localizations/src/is-IS.ts (5)

17-49: Well-structured API keys section with comprehensive coverage.

The new apiKeys section provides a complete set of placeholder keys for API key management functionality, including actions, form fields, expiration options, usage tracking, and revocation confirmation. The nested structure and naming conventions are consistent with the existing codebase patterns.


93-93: Billing-related commerce keys properly added.

The new billing keys (pastDueNotice, credit, totalDue) are logically placed within the commerce section and follow the established naming patterns.

Also applies to: 99-99, 138-138


237-239: Comprehensive organization profile extensions for API keys and billing.

The additions to organizationProfile provide complete coverage for API key management and billing functionality, including payment history, statements, and subscription management. The navbar integration ensures proper navigation support.

Also applies to: 245-251, 270-270, 275-285, 289-291, 359-359


173-175: Consistent user profile extensions and form field additions.

The userProfile extensions mirror the organizationProfile changes, providing consistent API key and billing management across both contexts. The form field placeholders and labels complete the UI text requirements.

Also applies to: 190-192, 879-881, 899-905, 924-924, 929-939, 943-945, 1064-1064


17-1064: Localization keys verified; translation backlog confirmed

All apiKeys.*, billingPage.paymentHistorySection.*, and billingPage.statementsSection.* keys are actively referenced in the UI—including:

  • packages/clerk-js/src/ui/components/ApiKeys (table, form, modal) and src/ui/utils/timeAgo.ts
  • packages/clerk-js/src/ui/components/PaymentAttempts (PaymentAttemptPage, PaymentAttemptsList)
  • packages/clerk-js/src/ui/components/Statements (StatementsList, StatementPage)

The use of undefined placeholders is appropriate until we supply Icelandic translations. No code changes are required; please prioritize translating these keys before shipping.

packages/localizations/src/bg-BG.ts (1)

17-1058: Excellent structural consistency with the Icelandic localization file.

The Bulgarian localization file maintains perfect structural consistency with the Icelandic file (is-IS.ts), with identical key additions in the same locations. This ensures consistent localization support across both languages for the new API key and billing features.

The comprehensive additions include:

  • Complete apiKeys section with nested structure
  • Commerce billing keys (pastDueNotice, credit, totalDue)
  • Extended organizationProfile and userProfile sections
  • Form field placeholders and labels
  • Navigation integration
packages/localizations/src/vi-VN.ts (4)

17-49: LGTM: Well-structured API keys localization section added.

The new apiKeys section follows established patterns and includes comprehensive keys for API key management functionality. Using undefined placeholders is appropriate for future Vietnamese translations.


93-93: LGTM: Commerce section extensions are consistent.

The additions of pastDueNotice, credit, and totalDue keys maintain the existing structure and naming conventions.

Also applies to: 99-99, 138-138


172-174: LGTM: API key form field additions are properly structured.

The new form field placeholders and labels for API key inputs follow the established naming pattern and are correctly placed within the existing structure.

Also applies to: 190-192


237-239: LGTM: Consistent API keys page and navigation additions.

The apiKeysPage sections and navigation entries are consistently added to both organizationProfile and userProfile, maintaining structural symmetry.

Also applies to: 358-358, 873-875, 1057-1057

packages/localizations/src/hu-HU.ts (1)

17-49: LGTM: Consistent localization structure with Vietnamese file.

The Hungarian file maintains identical structure and organization to the Vietnamese file, demonstrating good consistency in the localization key generation process. The undefined placeholders are appropriate for future Hungarian translations.

Also applies to: 93-93, 99-99, 138-138, 172-174, 190-192

packages/localizations/src/hr-HR.ts (5)

17-49: Well-structured API key management scaffolding.

The new apiKeys section provides comprehensive coverage for API key functionality including creation, expiration management, usage tracking, and revocation workflows. The nested structure and naming conventions align with established patterns in the codebase.


172-174: Consistent form field additions for API keys.

The new form field placeholders and labels follow established naming conventions and provide necessary scaffolding for API key input forms.

Also applies to: 189-191


93-93: Appropriate commerce section enhancements.

The new billing-related keys (pastDueNotice, credit, totalDue) are logically placed within the existing commerce structure and support enhanced billing functionality.

Also applies to: 99-99, 138-138


236-290: Comprehensive organization profile enhancements.

The additions to organizationProfile provide well-structured scaffolding for API key management and enhanced billing features including payment history, statements, and subscription management. The nested structure and navbar integration follow established patterns.

Also applies to: 358-358


881-947: Consistent user profile feature parity.

The userProfile enhancements mirror the organization profile changes, providing consistent API key management and billing functionality across both contexts. The structural consistency demonstrates thoughtful design.

Also applies to: 1064-1064

packages/localizations/src/sr-RS.ts (1)

17-49: Excellent structural consistency across locales.

The Serbian localization file maintains perfect structural consistency with the Croatian file, ensuring identical API key management and billing feature availability across locales. All additions follow the established scaffolding pattern with undefined placeholders for future translation work.

Also applies to: 172-174, 189-191, 93-93, 99-99, 138-138, 236-290, 358-358, 875-941, 1058-1058

packages/localizations/src/da-DK.ts (4)

17-49: Well-structured API key localization infrastructure.

The new apiKeys object provides comprehensive coverage for API key management features including creation, expiration options, usage tracking, and revocation workflows. The nested structure and consistent undefined placeholders follow the established pattern for community localization files.


172-174: Consistent form field placeholders for API key inputs.

The addition of API key-specific form field labels and input placeholders maintains consistency with existing form field naming conventions.

Also applies to: 190-192


93-93: Comprehensive billing and payment management additions.

The new billing-related keys cover payment history, statements, and subscription management sections. The structure supports both empty states and detailed table displays with appropriate headers.

Also applies to: 99-99, 138-138, 245-251, 275-285, 289-291


237-239: Navigation and page structure updates for API keys.

The additions properly integrate API key management into both organization and user profile navigation structures, maintaining consistency across the application.

Also applies to: 358-358, 873-875, 1057-1057

packages/localizations/src/es-MX.ts (4)

17-49: Consistent API key localization structure across locales.

The apiKeys object structure is identical to other locale files, ensuring consistency in the localization infrastructure for API key management features.


173-175: Proper form field placeholder integration.

The API key form field labels and placeholders are correctly positioned within the existing Spanish Mexico localization structure.

Also applies to: 191-193


93-93: Comprehensive billing feature coverage.

The billing-related additions provide complete coverage for payment history, statements, and subscription management, maintaining structural consistency with other locale files.

Also applies to: 99-99, 138-138, 246-252, 276-286, 290-292


238-240: Ensure Structural Consistency Across All Locale Files

Please verify that every file under packages/localizations/src/*.ts in this PR has the same structure for the API Keys and billing sections as the Spanish (es-MX) file:

  • Each locale’s top-level object includes an apiKeysPage entry with a title key (even if undefined).
  • Each locale defines the billing section (for example, billingPage or paymentHistorySection) alongside apiKeysPage.
  • Under each locale’s navbar object, ensure there is an apiKeys property in the same position.

Once you’ve confirmed those keys appear in every locale file with matching nesting, this can be approved.

packages/localizations/src/pt-BR.ts (5)

17-49: Well-structured API keys localization section added.

The new apiKeys object follows proper nesting conventions with a comprehensive set of keys for form elements, actions, status indicators, and nested revokeConfirmation dialog. The undefined placeholders are appropriate for this chore task.


97-97: Commerce section appropriately extended.

New keys pastDueNotice, credit, and totalDue properly added to support billing functionality with undefined placeholders consistent with the PR's purpose.

Also applies to: 103-103, 142-142


177-179: Form field placeholders and labels properly added.

API key-related form fields follow the established naming convention with formFieldInputPlaceholder__apiKey* and formFieldLabel__apiKey* patterns.

Also applies to: 194-196


241-243: Organization profile billing sections comprehensively extended.

New nested objects for apiKeysPage, paymentHistorySection, statementsSection and updated subscription headers properly mirror the UI structure. The navbar addition maintains consistency.

Also applies to: 249-255, 275-275, 280-290, 294-296, 364-364


887-889: User profile sections mirror organization profile structure.

The additions to userProfile maintain structural consistency with organizationProfile, ensuring a uniform localization approach across both profile types.

Also applies to: 907-913, 933-933, 938-948, 952-954, 1074-1074

packages/localizations/src/es-ES.ts (4)

17-49: Structural consistency maintained across locales.

The Spanish locale file properly mirrors the Portuguese structure with identical API keys section and commerce additions. All undefined placeholders are appropriate for this locale.

Also applies to: 93-93, 99-99, 138-138


172-174: Form field additions consistent with other locales.

API key form placeholders and labels follow the same naming patterns as other locale files.

Also applies to: 190-192


237-239: Organization profile updates maintain cross-locale consistency.

All billing-related sections (API keys page, payment history, statements) and navbar updates properly match the structure established in other locale files.

Also applies to: 245-251, 270-270, 275-285, 289-291, 359-359


879-881: User profile sections properly aligned.

The user profile additions maintain the same structural consistency as organization profile and other locale files, ensuring uniform localization coverage.

Also applies to: 899-905, 924-924, 929-939, 943-945, 1065-1065

packages/localizations/src/ar-SA.ts (5)

17-49: Well-structured API keys localization scaffolding.

The new apiKeys object provides comprehensive coverage for API key management functionality with proper nesting and consistent naming conventions. Using undefined placeholders is appropriate for missing locale generation.


93-93: Appropriate commerce section enhancements.

The additions of pastDueNotice, credit, and totalDue keys align with billing functionality requirements and follow the established pattern.

Also applies to: 99-99, 138-138


173-175: Consistent form field additions for API keys.

The new input placeholders and labels for API key fields follow the established naming pattern and integrate well with existing form field definitions.

Also applies to: 190-192


237-239: Comprehensive organization profile enhancements.

The systematic addition of API keys page, payment history section, statements section, and navigation entry provides complete coverage for organization-level API key and billing management.

Also applies to: 245-251, 270-270, 275-285, 289-291, 358-358


873-875: Complete user profile API key integration.

The user profile updates mirror the organization profile structure, ensuring consistent API key and billing management capabilities across both user and organization contexts.

Also applies to: 893-899, 918-918, 923-933, 937-939, 945-947, 1053-1053

packages/localizations/src/en-GB.ts (3)

17-49: Consistent API keys localization structure.

The en-GB locale additions perfectly mirror the ar-SA structure, ensuring consistent API key functionality coverage across different locales. The systematic use of undefined placeholders maintains uniformity in the missing locale generation approach.

Also applies to: 93-93, 99-99, 138-138, 172-174, 189-191


237-239: Uniform organization profile enhancements.

The organization profile additions in en-GB maintain structural consistency with the Arabic locale, ensuring feature parity across language variants for API key and billing management.

Also applies to: 245-251, 270-270, 275-285, 289-291, 359-359


881-883: Systematic user profile consistency.

The user profile changes match the Arabic locale structure exactly, demonstrating proper coordination in the missing locale generation process across different language files.

Also applies to: 901-907, 926-926, 931-941, 945-947, 1065-1065

packages/localizations/src/nl-BE.ts (5)

17-49: LGTM: Well-structured API keys localization section.

The new apiKeys section is comprehensively structured with appropriate nesting for form elements, actions, status indicators, and confirmation dialogs. Using undefined as placeholders follows the established pattern for untranslated keys.


93-93: LGTM: Commerce section additions are appropriately placed.

The new commerce-related keys (pastDueNotice, credit, totalDue) are logically positioned within the existing commerce structure and maintain consistency with the existing pattern.

Also applies to: 99-99, 138-138


172-175: LGTM: API key form field additions follow established conventions.

The new form field placeholders and labels for API key management are consistently named and properly positioned within the existing form field structure.

Also applies to: 189-193


236-238: LGTM: Organization profile billing and API key sections are well-structured.

The additions to organizationProfile maintain the existing hierarchical structure while adding comprehensive billing and API key management functionality. The nested sections for payment history, statements, and subscriptions are appropriately organized.

Also applies to: 244-250, 269-269, 274-284, 288-290, 358-358


875-877: LGTM: User profile additions mirror organization profile structure consistently.

The user profile additions follow the same structural pattern as the organization profile, ensuring UI consistency across different profile contexts.

Also applies to: 895-901, 920-920, 925-935, 939-941, 1058-1058

packages/localizations/src/it-IT.ts (5)

17-49: LGTM: API keys section maintains consistency with other locale files.

The apiKeys section structure is identical to other locale files, ensuring consistent functionality across different languages.


93-93: LGTM: Commerce additions are consistently implemented.

The commerce section additions match the pattern established in other locale files, maintaining structural consistency.

Also applies to: 99-99, 138-138


173-175: LGTM: Form field additions follow the established pattern.

API key form field placeholders and labels are consistently positioned and named according to the established conventions.

Also applies to: 191-193


238-240: LGTM: Organization profile structure is consistent and comprehensive.

The billing and API key management additions to organizationProfile maintain the same hierarchical structure across all locale files, ensuring UI consistency.

Also applies to: 246-252, 271-271, 276-286, 290-292, 359-359


877-879: LGTM: User profile additions maintain structural consistency.

The user profile modifications mirror the organization profile changes perfectly, ensuring consistent user experience across different profile contexts.

Also applies to: 897-903, 922-922, 927-937, 941-943, 1062-1062

packages/localizations/src/fi-FI.ts (6)

17-49: LGTM: Well-structured API keys localization section added.

The new apiKeys section provides comprehensive placeholder keys for API key management functionality. Using undefined values as placeholders is the correct approach for localization files when introducing new features before translations are ready.


93-99: LGTM: Commerce-related keys added for billing functionality.

The new commerce keys (pastDueNotice, credit, totalDue) are logically placed within the existing commerce section structure.

Also applies to: 138-138


173-175: LGTM: API key form field placeholders and labels added.

The form field placeholders and labels for API key management are properly structured and follow the established naming conventions.

Also applies to: 190-192


237-239: LGTM: API keys page titles added to both organization and user profiles.

The consistent addition of apiKeysPage sections in both organizationProfile and userProfile maintains structural symmetry.

Also applies to: 876-878


245-251: LGTM: Comprehensive billing page sections added.

The billing-related sections (paymentHistorySection, statementsSection, subscriptionsListSection) are well-structured with appropriate table headers and state management keys for both organization and user profiles.

Also applies to: 275-285, 289-291, 896-902, 926-936, 940-942


359-359: LGTM: Navbar API keys entries added consistently.

The apiKeys navigation entries are added consistently across both organization and user profile navbar sections.

Also applies to: 1061-1061

packages/localizations/src/sk-SK.ts (4)

17-49: LGTM: Consistent API keys section structure.

The apiKeys section in the Slovak localization matches the structure added to the Finnish file, maintaining consistency across locales.


93-99: LGTM: Commerce and form field keys added consistently.

All commerce-related keys and API key form field placeholders/labels are added in the same positions as the Finnish file, ensuring structural consistency.

Also applies to: 138-138, 172-174, 190-192


237-239: LGTM: Billing sections mirror Finnish implementation.

The billing-related sections in both organization and user profiles maintain the same comprehensive structure as implemented in the Finnish localization.

Also applies to: 245-251, 275-285, 289-291, 872-874, 892-898, 922-932, 936-938


358-358: LGTM: Navbar consistency maintained.

The apiKeys navbar entries are positioned consistently with the Finnish file implementation.

Also applies to: 1056-1056

packages/localizations/src/zh-TW.ts (4)

17-49: Well-structured API keys localization infrastructure.

The new apiKeys object provides comprehensive placeholders for API key management functionality. The nested structure and property naming are consistent with existing patterns in the codebase.


172-191: Consistent form field localization additions.

The API key form field placeholders and labels follow the established naming conventions and maintain consistency with existing form field patterns.


235-237: Systematic addition of API keys pages.

Both organization and user profile sections correctly include the new apiKeysPage with consistent structure.

Also applies to: 861-863


243-283: Comprehensive billing section infrastructure.

The payment history and statements sections provide well-organized placeholders for billing functionality across both organization and user profiles.

Also applies to: 879-919

packages/localizations/src/es-CR.ts (5)

17-49: Consistent API keys infrastructure with zh-TW.

The API keys object structure perfectly mirrors the Traditional Chinese file, ensuring consistency across locales. The placeholder approach with undefined values is appropriate for pending translations.


173-193: Form field localization follows established patterns.

The API key form field placeholders and labels maintain structural consistency with other locales and existing form field conventions.


245-302: Well-organized billing infrastructure addition.

The billing page sections (payment history, statements, subscriptions) provide comprehensive localization infrastructure. The mix of Spanish translations and undefined placeholders suggests ongoing community translation work.

Also applies to: 904-962


559-564: Systematic addition of phone code provider sections.

The alternativePhoneCodeProvider sections are consistently added across authentication flows, maintaining structural integrity with placeholder values.

Also applies to: 674-679, 693-697, 767-772


836-836: New error key addition.

The session_exists error key is appropriately placed in the unstable errors section with placeholder value for future translation.

packages/localizations/src/el-GR.ts (4)

17-49: Well-structured API keys localization scaffolding.

The new apiKeys section provides comprehensive placeholder keys for the API key management feature. The structure is logical with proper groupings for actions, form elements, expiration options, and confirmation dialogs. Using undefined placeholders follows the established pattern for community-contributed localizations.


93-93: Commerce section appropriately extended.

The new billing-related keys (pastDueNotice, credit, totalDue) are properly positioned within the existing commerce structure and follow the undefined placeholder pattern.

Also applies to: 99-99, 138-138


172-174: Form field additions follow established conventions.

The new API key form field placeholders and labels maintain consistency with existing form field naming patterns and provide complete coverage for the API key creation interface.

Also applies to: 190-192


237-239: Profile sections comprehensively extended for API keys and billing.

The additions to both organizationProfile and userProfile provide complete scaffolding for API key management and billing functionality. The mirroring between organization and user contexts ensures consistent user experience. Navigation updates appropriately include the new API keys section.

Also applies to: 245-285, 359-359, 881-941, 1067-1067

packages/localizations/src/sv-SE.ts (1)

17-49: Swedish localization properly mirrors Greek changes.

The Swedish localization file includes identical structural changes to the Greek file, providing consistent API key and billing feature scaffolding across languages. All additions follow the established undefined placeholder pattern for community-contributed localizations.

The comprehensive coverage includes:

  • Complete apiKeys section with proper nesting
  • Commerce billing keys
  • Form field placeholders and labels
  • Profile page extensions for both organization and user contexts
  • Navigation updates

This consistency ensures uniform feature availability across supported locales when translations are completed.

Also applies to: 93-93, 99-99, 138-138, 172-174, 190-192, 237-285, 358-358, 878-938, 1061-1061

packages/localizations/src/de-DE.ts (3)

96-96: LGTM! Consistent placeholder additions to commerce section.

The new pastDueNotice and totalDue keys are properly integrated and consistently use undefined placeholders.

Also applies to: 141-141


250-291: LGTM! Well-structured billing page scaffolding.

The new paymentHistorySection and statementsSection provide comprehensive placeholders for billing UI elements with consistent undefined values and proper nesting structure.


295-297: LGTM! Consistent completion of billing and navigation scaffolding.

The new table header keys and navbar apiKeys entry maintain the undefined placeholder pattern and complete the UI scaffolding structure.

Also applies to: 365-365

packages/localizations/src/fr-FR.ts (3)

17-49: LGTM! Excellent consistent placeholder approach.

The apiKeys section demonstrates the ideal pattern with all keys consistently set to undefined, providing clean scaffolding for future translations while maintaining structural integrity.


93-93: LGTM! Comprehensive and consistent scaffolding across all sections.

All new commerce and billing-related keys maintain the undefined placeholder pattern consistently, creating reliable scaffolding for future French translations.

Also applies to: 99-99, 138-138, 246-286, 290-292, 901-941, 945-947


173-175: LGTM! Complete and consistent API key scaffolding.

The French localization demonstrates exemplary consistency with all new API key and billing-related keys properly set to undefined, providing comprehensive scaffolding for future translation work.

Also applies to: 191-193, 238-240, 360-360, 881-883, 1066-1066

packages/localizations/src/th-TH.ts (5)

17-49: LGTM: Comprehensive API keys localization structure added.

The new apiKeys object provides a well-organized structure for API key management features including:

  • Action keys (add, search, revoke)
  • Form fields and validation
  • Expiration options (1d, 7d, 30d, 60d, 90d, 180d, 1y, never)
  • Last used timestamps
  • Confirmation dialogs

All keys are properly typed as undefined placeholders for future Thai translations.


172-174: LGTM: API key form field placeholders and labels added.

The new form field placeholders and labels for API key name, description, and expiration are consistent with the existing pattern and properly follow the naming convention.

Also applies to: 189-192


93-93: LGTM: Commerce-related keys added for billing features.

The new keys pastDueNotice, credit, and totalDue align with the billing functionality being introduced. Proper placement within the commerce section maintains structural consistency.

Also applies to: 99-99, 138-138


236-238: LGTM: Organization profile billing page structure added.

The comprehensive billing page structure includes:

  • API keys page title
  • Payment history section with table headers
  • Statements section with captions and totals
  • Enhanced subscription list headers
  • Navigation integration

All additions maintain proper nesting and follow established patterns.

Also applies to: 244-250, 269-269, 275-285, 288-291, 358-358


874-876: LGTM: User profile billing features mirror organization structure.

The user profile changes mirror the organization profile structure, ensuring consistency between personal and organizational billing management interfaces. The systematic duplication maintains feature parity.

Also applies to: 893-899, 918-918, 923-933, 937-944, 948-951, 1054-1054, 1069-1069

packages/localizations/src/pl-PL.ts (1)

17-49: LGTM: Consistent localization structure across locales.

The Polish localization file contains identical new key structures as the Thai file, ensuring:

  • Feature parity across supported languages
  • Consistent API key management capabilities
  • Unified billing and payment history interfaces
  • Proper TypeScript typing with undefined placeholders

This systematic approach will facilitate future translation efforts while maintaining structural integrity across all locales.

Also applies to: 172-174, 190-192, 93-93, 99-99, 138-138, 237-239, 245-251, 270-270, 276-286, 289-292, 358-358, 884-886, 904-910, 929-929, 934-944, 948-951, 1069-1069

packages/localizations/src/ru-RU.ts (4)

17-49: LGTM! Comprehensive API key management localization structure added.

The new apiKeys section provides complete coverage for API key functionality including form fields, expiration options, usage tracking, and revocation workflows. The nested structure and placeholder approach with undefined values follows the established localization patterns in this codebase.


93-93: LGTM! New commerce billing keys added consistently.

The new billing-related keys (pastDueNotice, credit, totalDue) are appropriately placed within the commerce section and follow the established naming conventions. Using undefined placeholders is the correct approach for future translation.

Also applies to: 99-99, 138-138


240-242: LGTM! Comprehensive billing functionality added to both profiles.

The billing page extensions for both organizationProfile and userProfile are well-structured and consistent with each other. The additions include:

  • API keys page integration
  • Payment history with table headers and state management
  • Statements section with comprehensive billing details
  • Enhanced subscription list headers

The parallel structure between organization and user profiles maintains consistency, and all placeholder values are appropriately set to undefined.

Also applies to: 248-254, 273-273, 278-288, 292-294, 889-891, 909-915, 934-934, 939-949, 953-955


174-176: LGTM! API key navigation and form field support completed.

The addition of apiKeys to both profile navbars ensures consistent access to API key management. The new form field placeholders and labels provide proper input support for API key creation and management forms. All additions maintain the established pattern of using undefined for future translation.

Also applies to: 192-194, 362-362, 1075-1075

packages/localizations/src/id-ID.ts (1)

17-49: LGTM! Consistent implementation of API key and billing functionality.

The Indonesian localization file demonstrates excellent consistency with the Russian file changes. All additions follow the same structure and patterns:

  • Comprehensive apiKeys section with complete functionality coverage
  • Consistent commerce billing keys (pastDueNotice, credit, totalDue)
  • Parallel billing page extensions for both organization and user profiles
  • Matching navbar integration and form field support
  • Proper use of undefined placeholders throughout

This systematic approach across localization files ensures feature parity and maintainability. The implementation aligns perfectly with the PR objective of generating missing API keys locales.

Also applies to: 93-93, 99-99, 138-138, 237-239, 245-251, 270-270, 275-285, 289-291, 359-359, 885-887, 905-911, 930-930, 935-945, 949-951, 1061-1061, 172-174, 189-191

packages/localizations/src/mn-MN.ts (4)

17-49: Comprehensive API keys localization structure added

Excellent systematic addition of all necessary localization keys for API key management features. The structure covers all UI components including forms, actions, confirmation dialogs, and time displays. Using undefined placeholders is the correct approach for future translation work.


93-93: Enhanced commerce localization keys added

The new commerce keys (pastDueNotice, credit, totalDue) are well-positioned within the existing structure and support enhanced billing functionality. Consistent use of undefined placeholders is appropriate.

Also applies to: 99-99, 138-138


237-291: Systematic organizationProfile enhancements for billing and API keys

The additions to organizationProfile provide comprehensive support for:

  • API key management page structure
  • Enhanced payment history and statements sections
  • Improved subscription management table headers
  • API keys navigation entry

All changes maintain consistency with existing localization patterns and proper nesting structure.

Also applies to: 359-359


172-175: Consistent userProfile and form field enhancements

The userProfile changes mirror the organizationProfile enhancements, ensuring feature parity between user types. The new form field placeholders and labels for API keys provide complete form support. Excellent consistency in structure and naming conventions.

Also applies to: 189-192, 876-942, 1060-1060

packages/localizations/src/he-IL.ts (1)

17-49: Consistent localization structure across locales

The Hebrew localization file mirrors the exact same systematic additions as the Mongolian file, demonstrating excellent consistency in the localization rollout. This unified approach ensures:

  • Feature parity across all supported locales
  • Consistent API key and billing functionality structure
  • Proper placeholder management for future translations
  • Unified user experience regardless of language selection

The identical structure and naming conventions across locales will facilitate efficient translation workflows and maintain system integrity.

Also applies to: 93-93, 99-99, 138-138, 172-175, 189-192, 236-291, 356-356, 866-942, 1042-1042

packages/localizations/src/tr-TR.ts (7)

17-49: Well-structured API key localization additions.

The new apiKeys section provides comprehensive placeholder keys for API key management functionality, including form fields, actions, expiration options, and confirmation dialogs. Using undefined placeholders is appropriate for community-maintained localization files.


93-138: Consistent commerce section additions.

The new billing-related keys (pastDueNotice, credit, totalDue) follow the established pattern and are properly integrated into the existing commerce structure.


172-191: Appropriate form field placeholder additions.

The API key form field placeholders and labels are consistently structured and follow the existing naming conventions for form field inputs and labels.


236-290: Comprehensive organization profile billing features.

The additions to organizationProfile include well-structured sections for API keys page, payment history, statements, and subscription management. The nested structure is logical and maintains consistency with existing profile sections.


358-358: Navigation consistency maintained.

Adding apiKeys to the organization profile navbar maintains consistency with the new API key management features.


879-945: User profile billing sections mirror organization structure.

The user profile additions appropriately mirror the organization profile structure, ensuring consistent user experience across both profile types for billing and API key management features.


1063-1063: User profile navigation completed.

The addition of apiKeys to the user profile navbar completes the navigation consistency for the new API key management features.

packages/localizations/src/uk-UA.ts (7)

17-49: Consistent API key localization structure.

The Ukrainian localization follows the exact same structure as other locale files for the new API key management features. This consistency across locales ensures maintainability and proper feature parity.


93-138: Commerce section additions align with pattern.

The billing-related key additions maintain the same structure and naming conventions across all localization files, which is essential for consistent UI behavior.


172-192: Form field additions follow established conventions.

The API key form field placeholders and labels use the same naming pattern and structure, ensuring consistent form behavior across different locales.


237-291: Organization profile sections properly structured.

The billing and API key management sections in the organization profile are well-organized and maintain the established nested structure pattern used throughout the localization files.


358-358: Navigation consistency maintained.

The navbar addition for API keys ensures consistent navigation experience across all localization files.


872-938: User profile billing features complete.

The user profile additions provide comprehensive coverage for billing and API key management features, maintaining structural consistency with the organization profile sections.


1057-1057: Final navigation addition completes the pattern.

The user profile navbar addition ensures all navigation elements are consistently available across locale files for the new API key management functionality.

packages/localizations/src/ca-ES.ts (5)

17-49: LGTM! Well-structured API key localization scaffolding.

The new apiKeys section provides comprehensive placeholders for API key management UI elements, including actions, form fields, expiration options, and confirmation dialogs. The undefined values are appropriate for establishing the structure before translations are added.


93-93: LGTM! Appropriate commerce section extensions.

The new billing-related keys (pastDueNotice, credit, totalDue) are logically placed within the commerce section and properly initialized as placeholders.

Also applies to: 99-99, 138-138


172-174: LGTM! Consistent form field additions for API keys.

The new API key form field placeholders and labels are properly structured and follow the existing naming conventions in the localization file.

Also applies to: 189-193


236-238: LGTM! Comprehensive organization profile extensions.

The additions to organizationProfile properly structure API key management and billing functionality, including payment history, statements, and subscription management. The navbar integration and table headers follow consistent patterns.

Also applies to: 244-250, 269-269, 274-284, 288-290, 358-358


876-878: LGTM! Consistent user profile extensions.

The userProfile additions mirror the organization profile changes, providing consistent API key and billing management capabilities across both contexts. The structural consistency is excellent.

Also applies to: 896-902, 921-921, 926-936, 940-942, 1063-1063

packages/localizations/src/cs-CZ.ts (1)

17-49: LGTM! Excellent consistency with other localization files.

The Czech localization file changes are structurally identical to the Catalan file, demonstrating excellent consistency across locales. All API key management, billing, and profile extensions are properly scaffolded with undefined placeholders, ensuring uniform behavior across different language selections.

Also applies to: 93-93, 99-99, 138-138, 173-175, 191-193, 238-240, 246-252, 271-271, 276-286, 290-292, 359-359, 873-875, 893-899, 918-918, 923-933, 937-939, 1057-1057

.changeset/eleven-pigs-juggle.md (1)

1-5: LGTM! Proper changeset documentation.

The changeset correctly documents this as a patch update for the @clerk/localizations package, with an accurate description that aligns with the PR objectives. The format follows standard conventions for the Clerk repository.

packages/localizations/src/en-US.ts (4)

8-37: Well-structured API keys localization additions.

The new API keys section is comprehensive and well-organized, covering all necessary UI elements for API key management including creation, expiration, status tracking, and revocation workflows.


165-166: Consistent form field additions for API key management.

The new API key form field placeholders and labels follow established naming patterns and provide clear guidance for users.

Also applies to: 181-183


229-231: Proper integration of API keys into navigation and profile sections.

The API keys functionality is correctly integrated into both organization and user profile navigation structures.

Also applies to: 352-352, 870-872, 1055-1055


237-286: Comprehensive billing page enhancements.

The addition of payment history, statements, and subscription management sections provides a complete billing experience for both organization and user profiles.

Also applies to: 889-939

packages/localizations/src/ro-RO.ts (3)

17-49: Proper placeholder structure for API keys localization.

All new API key related strings are correctly set to undefined, maintaining structural consistency with the English locale while awaiting translation.

Also applies to: 173-175, 191-193


238-240: Consistent billing and navigation placeholder additions.

The billing page sections and navigation entries are properly structured with undefined placeholders, matching the en-US file structure exactly.

Also applies to: 246-286, 360-360, 879-881, 899-939, 1066-1066


93-93: Well-organized commerce section additions.

New commerce keys like pastDueNotice, credit, and totalDue are appropriately placed and set to undefined for future translation.

Also applies to: 99-99, 138-138

packages/localizations/src/ja-JP.ts (4)

17-49: Well-structured API keys localization section.

The new apiKeys section provides comprehensive placeholder keys for API key management features, including actions, form elements, expiration options, and confirmation dialogs. The structure follows established patterns and uses appropriate undefined placeholders for future translations.


172-174: Consistent API key form field additions.

The form field placeholders and labels for API key management are properly added and follow the existing naming conventions used throughout the localization file.

Also applies to: 190-192


93-93: Commerce section enhancements aligned with billing features.

The new commerce keys (pastDueNotice, credit, totalDue) complement the API key management features and billing functionality being added across the localization files.

Also applies to: 99-99, 138-138


237-239: Comprehensive billing and API keys integration in user profiles.

The additions to both organizationProfile and userProfile sections provide consistent placeholder structure for:

  • API keys page navigation
  • Payment history sections with table headers
  • Statements sections with comprehensive metadata
  • Updated navigation bars

The structural consistency between organization and user profiles ensures a unified user experience.

Also applies to: 245-285, 358-358, 876-943

packages/localizations/src/ko-KR.ts (2)

17-49: Consistent API keys localization structure.

The Korean localization mirrors the Japanese implementation exactly, providing the same comprehensive API key management placeholder structure. This consistency ensures uniform feature coverage across locales.

Also applies to: 172-174, 190-192


93-93: Unified billing and profile enhancements.

The commerce, organization profile, and user profile sections receive identical structural updates as the Japanese locale, maintaining consistency in the localization schema across languages. The placeholder approach allows for future translation while establishing the complete feature structure.

Also applies to: 99-99, 138-138, 237-291, 358-358, 869-943

packages/localizations/src/zh-CN.ts (5)

17-49: Well-structured API keys localization scaffolding.

The new apiKeys section provides comprehensive placeholder structure for API key management UI elements including form fields, actions, confirmation dialogs, and time-based formatting. The hierarchical organization and consistent use of undefined placeholders aligns well with the PR's objective of generating missing locales.


172-174: Consistent API key form field integration.

The API key-related form field placeholders and labels are properly integrated into the existing form field structure, maintaining naming consistency with the established patterns.

Also applies to: 189-191


235-237: Symmetric navigation structure for API keys.

The addition of apiKeysPage sections and navigation entries in both organizationProfile and userProfile maintains UI consistency between personal and organizational contexts. This symmetric approach ensures a coherent user experience.

Also applies to: 354-354, 860-862, 1033-1033


243-249: Comprehensive billing and payment history scaffolding.

The new billing-related sections (paymentHistorySection, statementsSection, and subscription list enhancements) provide thorough placeholder structure for financial management features. The parallel implementation in both organization and user profiles ensures feature parity.

Also applies to: 268-268, 273-283, 287-289, 878-884, 903-903, 908-918, 922-924


93-93: Commerce section enhancements are appropriately minimal.

The targeted additions to the commerce section (pastDueNotice, credit, totalDue) align with billing functionality requirements without unnecessary expansion.

Also applies to: 99-99, 138-138

Comment on lines +17 to +49
apiKeys: {
action__add: undefined,
action__search: undefined,
createdAndExpirationStatus__expiresOn: undefined,
createdAndExpirationStatus__never: undefined,
detailsTitle__emptyRow: undefined,
formButtonPrimary__add: undefined,
formFieldCaption__expiration__expiresOn: undefined,
formFieldCaption__expiration__never: undefined,
formFieldOption__expiration__180d: undefined,
formFieldOption__expiration__1d: undefined,
formFieldOption__expiration__1y: undefined,
formFieldOption__expiration__30d: undefined,
formFieldOption__expiration__60d: undefined,
formFieldOption__expiration__7d: undefined,
formFieldOption__expiration__90d: undefined,
formFieldOption__expiration__never: undefined,
formHint: undefined,
formTitle: undefined,
lastUsed__days: undefined,
lastUsed__hours: undefined,
lastUsed__minutes: undefined,
lastUsed__months: undefined,
lastUsed__seconds: undefined,
lastUsed__years: undefined,
menuAction__revoke: undefined,
revokeConfirmation: {
confirmationText: undefined,
formButtonPrimary__revoke: undefined,
formHint: undefined,
formTitle: undefined,
},
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Verification agent

🧩 Analysis chain

Consider translation planning for undefined placeholders.

While using undefined for untranslated strings is a valid pattern, this introduces a significant number of placeholder keys across critical user-facing features like API key management and billing. Consider:

  1. Planning translation priorities for these new features
  2. Ensuring consistent placeholder handling across all locale files
  3. Documenting which features may have limited localization initially

Also applies to: 172-174, 189-193, 236-290, 357-357, 875-941, 1059-1059


🏁 Script executed:

#!/bin/bash
# Check if similar API key and billing additions exist across other locale files
echo "Checking for consistency across locale files..."

# Find all locale files and count new apiKeys sections
fd -e ts . packages/localizations/src/ --exec grep -l "apiKeys:" {} \; | wc -l

# Check for undefined placeholders in API key sections
rg "apiKeys:.*undefined" packages/localizations/src/ -A 50 | head -20

# Verify billing section additions are consistent
rg "paymentHistorySection:" packages/localizations/src/ -A 10 | head -20

Length of output: 2863


Ensure consistent locale key structure for new features

It looks like the new API-key and billing sections in pt-PT.ts use a full nested object of undefined placeholders, whereas other locales (e.g. zh-TW.ts) simply have apiKeys: undefined, and nl-NL.ts exposes paymentHistorySection with undefined fields but may not mirror the exact shape. To streamline translation and avoid missing keys later:

• packages/localizations/src/pt-PT.ts (lines 17–49): nested apiKeys definitions
• packages/localizations/src/zh-TW.ts: apiKeys: undefined (should include the same nested keys)
• packages/localizations/src/nl-NL.ts: paymentHistorySection keys are present but need to match the same shape across all locales

Next steps:

  • Define the complete object structure for each new feature (API keys, billing, payment history) in every locale file—even if values start as undefined.
  • Document which features/locales are slated for initial translation and your rollout priority.
  • Add a CI or validation script to flag missing keys or mismatched structures in any locale.
🤖 Prompt for AI Agents
In packages/localizations/src/pt-PT.ts between lines 17 and 49, the apiKeys
object is fully expanded with undefined placeholders, while other locale files
like zh-TW.ts use a simple undefined assignment for apiKeys, causing
inconsistency. To fix this, ensure that all locale files define the complete
nested structure for new features such as apiKeys and paymentHistorySection with
matching keys and undefined values where translations are not yet provided. This
alignment will streamline translation efforts and prevent missing keys.
Additionally, prepare documentation on translation priorities and implement a CI
validation script to detect missing or mismatched locale keys across all files.

@@ -14,6 +14,39 @@ import type { LocalizationResource } from '@clerk/types';

export const nlBE: LocalizationResource = {
locale: 'nl-NL',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Fix locale identifier mismatch.

The locale identifier is set to 'nl-NL' but this file is for Belgian Dutch (nl-BE). This should be corrected for consistency.

-  locale: 'nl-NL',
+  locale: 'nl-BE',
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
locale: 'nl-NL',
locale: 'nl-BE',
🤖 Prompt for AI Agents
In packages/localizations/src/nl-BE.ts at line 16, the locale identifier is
incorrectly set to 'nl-NL' instead of 'nl-BE'. Update the locale property value
to 'nl-BE' to correctly reflect the Belgian Dutch locale and maintain
consistency with the file's purpose.

Comment on lines 17 to 49
apiKeys: {
action__add: 'Neuen API-Key hinzufügen',
action__search: 'Suche',
createdAndExpirationStatus__expiresOn: undefined,
createdAndExpirationStatus__never: undefined,
detailsTitle__emptyRow: 'Keine API-Keys gefunden',
formButtonPrimary__add: 'API-Key erstellen',
formHint: 'Geben Sie einen Namen an, um einen API-Key zu erstellen. Sie können ihn jederzeit widerrufen.',
formTitle: 'Neuen API-Key hinzufügen',
menuAction__revoke: 'API-Key widerrufen',
revokeConfirmation: {
formButtonPrimary__revoke: 'API-Key widerrufen',
formHint: 'Sind Sie sicher, dass Sie diesen API-Key löschen wollen?',
formTitle: 'API-Key "{{apiKeyName}}" widerrufen?',
confirmationText: 'Widerrufen',
},
formFieldCaption__expiration__expiresOn: undefined,
formFieldCaption__expiration__never: undefined,
formFieldOption__expiration__180d: undefined,
formFieldOption__expiration__1d: undefined,
formFieldOption__expiration__7d: undefined,
formFieldOption__expiration__1y: undefined,
formFieldOption__expiration__30d: undefined,
formFieldOption__expiration__60d: undefined,
formFieldOption__expiration__7d: undefined,
formFieldOption__expiration__90d: undefined,
formFieldOption__expiration__180d: undefined,
formFieldOption__expiration__1y: undefined,
formFieldOption__expiration__never: undefined,
lastUsed__seconds: undefined,
lastUsed__minutes: undefined,
lastUsed__hours: undefined,
formHint: 'Geben Sie einen Namen an, um einen API-Key zu erstellen. Sie können ihn jederzeit widerrufen.',
formTitle: 'Neuen API-Key hinzufügen',
lastUsed__days: undefined,
lastUsed__hours: undefined,
lastUsed__minutes: undefined,
lastUsed__months: undefined,
lastUsed__seconds: undefined,
lastUsed__years: undefined,
menuAction__revoke: 'API-Key widerrufen',
revokeConfirmation: {
confirmationText: 'Widerrufen',
formButtonPrimary__revoke: 'API-Key widerrufen',
formHint: 'Sind Sie sicher, dass Sie diesen API-Key löschen wollen?',
formTitle: 'API-Key "{{apiKeyName}}" widerrufen?',
},
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Inconsistent placeholder handling in apiKeys section.

The apiKeys section mixes German translations with undefined placeholders. For consistency and better user experience, either translate all keys or mark all as undefined placeholders.

Since this PR aims to generate missing locale placeholders, consider making all new apiKeys consistently undefined:

   apiKeys: {
-    action__add: 'Neuen API-Key hinzufügen',
-    action__search: 'Suche',
+    action__add: undefined,
+    action__search: undefined,
     createdAndExpirationStatus__expiresOn: undefined,
     createdAndExpirationStatus__never: undefined,
-    detailsTitle__emptyRow: 'Keine API-Keys gefunden',
-    formButtonPrimary__add: 'API-Key erstellen',
+    detailsTitle__emptyRow: undefined,
+    formButtonPrimary__add: undefined,
     formFieldCaption__expiration__expiresOn: undefined,
     // ... continue for all currently translated keys
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
apiKeys: {
action__add: 'Neuen API-Key hinzufügen',
action__search: 'Suche',
createdAndExpirationStatus__expiresOn: undefined,
createdAndExpirationStatus__never: undefined,
detailsTitle__emptyRow: 'Keine API-Keys gefunden',
formButtonPrimary__add: 'API-Key erstellen',
formHint: 'Geben Sie einen Namen an, um einen API-Key zu erstellen. Sie können ihn jederzeit widerrufen.',
formTitle: 'Neuen API-Key hinzufügen',
menuAction__revoke: 'API-Key widerrufen',
revokeConfirmation: {
formButtonPrimary__revoke: 'API-Key widerrufen',
formHint: 'Sind Sie sicher, dass Sie diesen API-Key löschen wollen?',
formTitle: 'API-Key "{{apiKeyName}}" widerrufen?',
confirmationText: 'Widerrufen',
},
formFieldCaption__expiration__expiresOn: undefined,
formFieldCaption__expiration__never: undefined,
formFieldOption__expiration__180d: undefined,
formFieldOption__expiration__1d: undefined,
formFieldOption__expiration__7d: undefined,
formFieldOption__expiration__1y: undefined,
formFieldOption__expiration__30d: undefined,
formFieldOption__expiration__60d: undefined,
formFieldOption__expiration__7d: undefined,
formFieldOption__expiration__90d: undefined,
formFieldOption__expiration__180d: undefined,
formFieldOption__expiration__1y: undefined,
formFieldOption__expiration__never: undefined,
lastUsed__seconds: undefined,
lastUsed__minutes: undefined,
lastUsed__hours: undefined,
formHint: 'Geben Sie einen Namen an, um einen API-Key zu erstellen. Sie können ihn jederzeit widerrufen.',
formTitle: 'Neuen API-Key hinzufügen',
lastUsed__days: undefined,
lastUsed__hours: undefined,
lastUsed__minutes: undefined,
lastUsed__months: undefined,
lastUsed__seconds: undefined,
lastUsed__years: undefined,
menuAction__revoke: 'API-Key widerrufen',
revokeConfirmation: {
confirmationText: 'Widerrufen',
formButtonPrimary__revoke: 'API-Key widerrufen',
formHint: 'Sind Sie sicher, dass Sie diesen API-Key löschen wollen?',
formTitle: 'API-Key "{{apiKeyName}}" widerrufen?',
},
},
apiKeys: {
action__add: undefined,
action__search: undefined,
createdAndExpirationStatus__expiresOn: undefined,
createdAndExpirationStatus__never: undefined,
detailsTitle__emptyRow: undefined,
formButtonPrimary__add: undefined,
formFieldCaption__expiration__expiresOn: undefined,
formFieldCaption__expiration__never: undefined,
formFieldOption__expiration__180d: undefined,
formFieldOption__expiration__1d: undefined,
formFieldOption__expiration__1y: undefined,
formFieldOption__expiration__30d: undefined,
formFieldOption__expiration__60d: undefined,
formFieldOption__expiration__7d: undefined,
formFieldOption__expiration__90d: undefined,
formFieldOption__expiration__never: undefined,
formHint: undefined,
formTitle: undefined,
lastUsed__days: undefined,
lastUsed__hours: undefined,
lastUsed__minutes: undefined,
lastUsed__months: undefined,
lastUsed__seconds: undefined,
lastUsed__years: undefined,
menuAction__revoke: undefined,
revokeConfirmation: {
confirmationText: undefined,
formButtonPrimary__revoke: undefined,
formHint: undefined,
formTitle: undefined,
},
},
🤖 Prompt for AI Agents
In packages/localizations/src/de-DE.ts between lines 17 and 49, the apiKeys
section inconsistently mixes German translations with undefined placeholders. To
maintain consistency and align with the PR goal of generating missing locale
placeholders, update all apiKeys entries to be undefined placeholders instead of
partial translations, ensuring uniform handling of untranslated keys.

Copy link

pkg-pr-new bot commented Jun 30, 2025

Open in StackBlitz

@clerk/agent-toolkit

npm i https://pkg.pr.new/@clerk/agent-toolkit@6223

@clerk/astro

npm i https://pkg.pr.new/@clerk/astro@6223

@clerk/backend

npm i https://pkg.pr.new/@clerk/backend@6223

@clerk/chrome-extension

npm i https://pkg.pr.new/@clerk/chrome-extension@6223

@clerk/clerk-js

npm i https://pkg.pr.new/@clerk/clerk-js@6223

@clerk/dev-cli

npm i https://pkg.pr.new/@clerk/dev-cli@6223

@clerk/elements

npm i https://pkg.pr.new/@clerk/elements@6223

@clerk/clerk-expo

npm i https://pkg.pr.new/@clerk/clerk-expo@6223

@clerk/expo-passkeys

npm i https://pkg.pr.new/@clerk/expo-passkeys@6223

@clerk/express

npm i https://pkg.pr.new/@clerk/express@6223

@clerk/fastify

npm i https://pkg.pr.new/@clerk/fastify@6223

@clerk/localizations

npm i https://pkg.pr.new/@clerk/localizations@6223

@clerk/nextjs

npm i https://pkg.pr.new/@clerk/nextjs@6223

@clerk/nuxt

npm i https://pkg.pr.new/@clerk/nuxt@6223

@clerk/clerk-react

npm i https://pkg.pr.new/@clerk/clerk-react@6223

@clerk/react-router

npm i https://pkg.pr.new/@clerk/react-router@6223

@clerk/remix

npm i https://pkg.pr.new/@clerk/remix@6223

@clerk/shared

npm i https://pkg.pr.new/@clerk/shared@6223

@clerk/tanstack-react-start

npm i https://pkg.pr.new/@clerk/tanstack-react-start@6223

@clerk/testing

npm i https://pkg.pr.new/@clerk/testing@6223

@clerk/themes

npm i https://pkg.pr.new/@clerk/themes@6223

@clerk/types

npm i https://pkg.pr.new/@clerk/types@6223

@clerk/upgrade

npm i https://pkg.pr.new/@clerk/upgrade@6223

@clerk/vue

npm i https://pkg.pr.new/@clerk/vue@6223

commit: d49bd74

@wobsoriano wobsoriano enabled auto-merge (squash) June 30, 2025 17:34
@wobsoriano wobsoriano merged commit baac817 into main Jun 30, 2025
63 of 64 checks passed
@wobsoriano wobsoriano deleted the rob/api-keys-localizations branch June 30, 2025 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants