-
Notifications
You must be signed in to change notification settings - Fork 361
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
Conversation
🦋 Changeset detectedLatest commit: d49bd74 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
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 |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
📝 WalkthroughWalkthroughThis change introduces a new changeset file documenting a patch update for the Possibly related PRs
Suggested reviewers
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this 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
📒 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
Avoidany
type - preferunknown
when type is uncertain, then narrow with type guards
Useinterface
for object shapes that might be extended
Usetype
for unions, primitives, and computed types
Preferreadonly
properties for immutable data structures
Useprivate
for internal implementation details
Useprotected
for inheritance hierarchies
Usepublic
explicitly for clarity in public APIs
Preferreadonly
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
Useconst assertions
for literal types:as const
Usesatisfies
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
Preferunknown
overany
for performance
Use type-only imports:import type { ... }
Use branded types for domain safety
Noany
types without justification
Proper error handling with typed errors
Consistent use ofreadonly
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 forrevokeConfirmation
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
, andtotalDue
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 theapiKeys
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 toundefined
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
, andtotalDue
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:
- All locales will support the same features once translated
- The codebase can rely on consistent key structures
- 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 ofundefined
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 theorganizationProfile
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 confirmedAll
apiKeys.*
,billingPage.paymentHistorySection.*
, andbillingPage.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
anduserProfile
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. Usingundefined
placeholders is appropriate for future Vietnamese translations.
93-93
: LGTM: Commerce section extensions are consistent.The additions of
pastDueNotice
,credit
, andtotalDue
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 bothorganizationProfile
anduserProfile
, 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 consistentundefined
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 FilesPlease 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 atitle
key (even ifundefined
).- Each locale defines the billing section (for example,
billingPage
orpaymentHistorySection
) alongsideapiKeysPage
.- Under each locale’s
navbar
object, ensure there is anapiKeys
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 nestedrevokeConfirmation
dialog. The undefined placeholders are appropriate for this chore task.
97-97
: Commerce section appropriately extended.New keys
pastDueNotice
,credit
, andtotalDue
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*
andformFieldLabel__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 withorganizationProfile
, 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. Usingundefined
placeholders is appropriate for missing locale generation.
93-93
: Appropriate commerce section enhancements.The additions of
pastDueNotice
,credit
, andtotalDue
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. Usingundefined
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. Usingundefined
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 bothorganizationProfile
anduserProfile
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. Usingundefined
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
anduserProfile
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
andtotalDue
keys are properly integrated and consistently useundefined
placeholders.Also applies to: 141-141
250-291
: LGTM! Well-structured billing page scaffolding.The new
paymentHistorySection
andstatementsSection
provide comprehensive placeholders for billing UI elements with consistentundefined
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
, andtotalDue
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 withundefined
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. Usingundefined
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
anduserProfile
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 usingundefined
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 throughoutThis 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 addedExcellent 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 addedThe new commerce keys (
pastDueNotice
,credit
,totalDue
) are well-positioned within the existing structure and support enhanced billing functionality. Consistent use ofundefined
placeholders is appropriate.Also applies to: 99-99, 138-138
237-291
: Systematic organizationProfile enhancements for billing and API keysThe 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 enhancementsThe 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 localesThe 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. Usingundefined
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
, andtotalDue
are appropriately placed and set toundefined
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 appropriateundefined
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
anduserProfile
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 ofundefined
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 bothorganizationProfile
anduserProfile
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
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, | ||
}, | ||
}, |
There was a problem hiding this comment.
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:
- Planning translation priorities for these new features
- Ensuring consistent placeholder handling across all locale files
- 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', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
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?', | ||
}, | ||
}, |
There was a problem hiding this comment.
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.
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.
@clerk/agent-toolkit
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/dev-cli
@clerk/elements
@clerk/clerk-expo
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/clerk-react
@clerk/react-router
@clerk/remix
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/themes
@clerk/types
@clerk/upgrade
@clerk/vue
commit: |
Description
Checklist
pnpm test
runs as expected.pnpm build
runs as expected.Type of change
Summary by CodeRabbit
New Features
Chores