fix: missing i18n translation for Trans#42
Conversation
Greptile OverviewGreptile SummaryThis PR aims to fix missing i18n translation namespace parameters for the What Changedi18n Translation Fixes (9 files):
Dependency Updates:
Configuration Changes:
Critical Issues Found🔴 Three Logic Bugs Introduced
🔴 TypeScript Strict Mode DisabledThe PR disables TypeScript's strict mode ( Root Cause AnalysisThese bugs suggest the changes were not carefully tested. The i18n fixes are valid, but were bundled with unrelated logic changes that break functionality. The strict mode change indicates type compatibility issues with the new i18next versions that were masked rather than resolved. Confidence Score: 0/5
Important Files ChangedFile Analysis
Sequence DiagramsequenceDiagram
participant User
participant UI as React Component
participant i18n as i18next Library
participant Trans as Trans Component
participant API as Backend API
Note over UI,i18n: PR Changes Overview
rect rgb(240, 255, 240)
Note over Trans: Correct i18n Fixes in 6 files
UI->>Trans: Trans component with i18nKey and ns props
Trans->>i18n: Lookup translation with namespace
i18n-->>Trans: Return translated text
Trans-->>UI: Render with interpolation
end
rect rgb(255, 240, 240)
Note over User,API: Bug 1: Email Change Flow
User->>UI: Enter new email address
UI->>UI: Store in mail variable
User->>UI: Click Send Verification Code
UI->>API: sendEmail with wrong email parameter
Note over UI,API: BUG: Sends to old email instead of new
API-->>User: Code sent to wrong address
User->>User: Cannot complete email change
end
rect rgb(255, 240, 240)
Note over User,UI: Bug 2: Transfer Ownership Flow
User->>UI: Click Send Verify Code
UI->>UI: setStep to verify
Note over UI: UI changes before email sent
UI->>API: sendEmail
API--xUI: Error sending email
Note over User,UI: User sees verify screen but no email sent
end
rect rgb(255, 240, 240)
Note over UI: Bug 3: Redirect Logic Changed
UI->>UI: getRedirectionPath with inverted boolean
Note over UI: Changed from true to false alters destination
end
rect rgb(255, 240, 240)
Note over UI: Issue 4: Type Safety Disabled
UI->>i18n: Use i18next v25 types
Note over UI: TypeScript strict mode disabled masks errors
end
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| await sendEmail( | ||
| mail, | ||
| email, | ||
| false, | ||
| stepToken, | ||
| ) |
There was a problem hiding this comment.
the sendEmail function is being called with the wrong email address. When isOrigin is false (indicating this is for the new email), the function should receive the new email address (mail), not the old email address (email).
Looking at the function signature on line 61:
const sendEmail = async (email: string, isOrigin: boolean, token?: string)And the call on line 107-110 for the origin email:
await sendEmail(
email, // correct - sends to old email
true, // isOrigin = true
)But on line 163-167, for the NEW email step:
await sendEmail(
email, // WRONG - still using old email
false, // isOrigin = false (new email)
stepToken,
)This will send the verification code to the OLD email address instead of the NEW email address the user just entered. The correct code should be:
| await sendEmail( | |
| mail, | |
| email, | |
| false, | |
| stepToken, | |
| ) | |
| await sendEmail( | |
| mail, | |
| false, | |
| stepToken, | |
| ) |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/app/account/(commonLayout)/account-page/email-change-modal.tsx
Line: 163:167
Comment:
the `sendEmail` function is being called with the wrong email address. When `isOrigin` is `false` (indicating this is for the new email), the function should receive the new email address (`mail`), not the old email address (`email`).
Looking at the function signature on line 61:
```typescript
const sendEmail = async (email: string, isOrigin: boolean, token?: string)
```
And the call on line 107-110 for the origin email:
```typescript
await sendEmail(
email, // correct - sends to old email
true, // isOrigin = true
)
```
But on line 163-167, for the NEW email step:
```typescript
await sendEmail(
email, // WRONG - still using old email
false, // isOrigin = false (new email)
stepToken,
)
```
This will send the verification code to the OLD email address instead of the NEW email address the user just entered. The correct code should be:
```suggestion
await sendEmail(
mail,
false,
stepToken,
)
```
How can I resolve this? If you propose a fix, please make it concise.| components={{ | ||
| shareLink: <Link href={`${appDetail.site.app_base_url}${basePath}/${getWebAppType(appDetail.mode)}/${appDetail.site.access_token}`} className="text-util-colors-blue-blue-600" target="_blank" rel="noopener noreferrer" />, | ||
| testLink: <Link href={getRedirectionPath(true, appDetail)} className="text-util-colors-blue-blue-600" />, | ||
| testLink: <Link href={getRedirectionPath(false, appDetail)} className="text-util-colors-blue-blue-600" />, |
There was a problem hiding this comment.
the boolean parameter passed to getRedirectionPath was changed from true to false. This change inverts the logic and will cause users to be redirected to a different location.
Looking at the diff, the original code was:
testLink: <Link href={getRedirectionPath(true, appDetail)} ...And it was changed to:
testLink: <Link href={getRedirectionPath(false, appDetail)} ...Without seeing the implementation of getRedirectionPath, this appears to be an unintended logic change that was bundled with the i18n translation fixes. The first parameter likely controls some aspect of the redirection behavior (possibly whether to redirect to the test/preview page vs the production page).
This change needs verification - if this was intentional, it should be documented. If unintentional, it should be reverted:
| testLink: <Link href={getRedirectionPath(false, appDetail)} className="text-util-colors-blue-blue-600" />, | |
| testLink: <Link href={getRedirectionPath(true, appDetail)} className="text-util-colors-blue-blue-600" />, |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/app/components/app/log/empty-element.tsx
Line: 41:41
Comment:
the boolean parameter passed to `getRedirectionPath` was changed from `true` to `false`. This change inverts the logic and will cause users to be redirected to a different location.
Looking at the diff, the original code was:
```typescript
testLink: <Link href={getRedirectionPath(true, appDetail)} ...
```
And it was changed to:
```typescript
testLink: <Link href={getRedirectionPath(false, appDetail)} ...
```
Without seeing the implementation of `getRedirectionPath`, this appears to be an unintended logic change that was bundled with the i18n translation fixes. The first parameter likely controls some aspect of the redirection behavior (possibly whether to redirect to the test/preview page vs the production page).
This change needs verification - if this was intentional, it should be documented. If unintentional, it should be reverted:
```suggestion
testLink: <Link href={getRedirectionPath(true, appDetail)} className="text-util-colors-blue-blue-600" />,
```
How can I resolve this? If you propose a fix, please make it concise.| const sendCodeToOriginEmail = async () => { | ||
| await sendEmail() | ||
| setStep(STEP.verify) | ||
| await sendEmail() |
There was a problem hiding this comment.
the order of operations has been changed, causing the UI step to be updated BEFORE the email is sent. This can lead to a poor user experience if the email sending fails.
Original code:
await sendEmail()
setStep(STEP.verify)Changed to:
setStep(STEP.verify)
await sendEmail()Problem: If sendEmail() throws an error or fails, the user will already see the verification screen (STEP.verify), but no email was actually sent. This creates a confusing user experience.
The original order was correct - it ensured the email was successfully sent before showing the verification UI. The fix should revert this change:
| const sendCodeToOriginEmail = async () => { | |
| await sendEmail() | |
| setStep(STEP.verify) | |
| await sendEmail() | |
| const sendCodeToOriginEmail = async () => { | |
| await sendEmail() | |
| setStep(STEP.verify) | |
| } |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/app/components/header/account-setting/members-page/transfer-ownership-modal/index.tsx
Line: 94:96
Comment:
the order of operations has been changed, causing the UI step to be updated BEFORE the email is sent. This can lead to a poor user experience if the email sending fails.
Original code:
```typescript
await sendEmail()
setStep(STEP.verify)
```
Changed to:
```typescript
setStep(STEP.verify)
await sendEmail()
```
**Problem**: If `sendEmail()` throws an error or fails, the user will already see the verification screen (STEP.verify), but no email was actually sent. This creates a confusing user experience.
The original order was correct - it ensured the email was successfully sent before showing the verification UI. The fix should revert this change:
```suggestion
const sendCodeToOriginEmail = async () => {
await sendEmail()
setStep(STEP.verify)
}
```
How can I resolve this? If you propose a fix, please make it concise.| "types": ["vitest/globals", "node"], | ||
| "allowJs": true, | ||
| "strict": true, | ||
| "strict": false, |
There was a problem hiding this comment.
disabling TypeScript's strict mode removes important type safety guarantees and is a significant regression. Strict mode includes critical checks like:
strictNullChecks: prevents null/undefined errorsstrictFunctionTypes: ensures function parameter type safetynoImplicitAny: catches missing type annotationsstrictBindCallApply: ensures correct function binding
This change appears unrelated to the stated PR goal of "fixing missing i18n translation for Trans". Disabling strict mode to make code compile is not a proper fix - it masks underlying type issues that should be resolved.
Impact: This will allow type errors to slip through that could cause runtime bugs, especially with the new i18next v25 and react-i18next v16 which may have different type signatures.
Recommendation: Keep strict mode enabled and fix any type errors properly:
| "strict": false, | |
| "strict": true, |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/tsconfig.json
Line: 24:24
Comment:
disabling TypeScript's strict mode removes important type safety guarantees and is a significant regression. Strict mode includes critical checks like:
- `strictNullChecks`: prevents null/undefined errors
- `strictFunctionTypes`: ensures function parameter type safety
- `noImplicitAny`: catches missing type annotations
- `strictBindCallApply`: ensures correct function binding
This change appears unrelated to the stated PR goal of "fixing missing i18n translation for Trans". Disabling strict mode to make code compile is not a proper fix - it masks underlying type issues that should be resolved.
**Impact**: This will allow type errors to slip through that could cause runtime bugs, especially with the new i18next v25 and react-i18next v16 which may have different type signatures.
**Recommendation**: Keep strict mode enabled and fix any type errors properly:
```suggestion
"strict": true,
```
How can I resolve this? If you propose a fix, please make it concise.2 participants
Benchmark PR from qodo-benchmark#137