[WEB-3737]chore: estimates code refactor and translations#6857
[WEB-3737]chore: estimates code refactor and translations#6857sriramveeraghanta merged 2 commits intopreviewfrom
Conversation
* chore: added translations for estimates components.
WalkthroughThe changes extend and restructure the "estimates" section in translation files for multiple locales, adding new keys (such as Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant ECS as EstimateCreateStageOne
participant IE as isEstimateSystemEnabled
participant EI as EstimateInputRoot
U->>ECS: Select estimate system option
ECS->>IE: Check if system is enabled
IE-->>ECS: Return true/false
alt System Enabled
ECS->>EI: Render corresponding input component
U->>EI: Enter estimate value
EI-->>ECS: Return input data
else System Disabled
ECS->>U: Display "Coming Soon" tooltip
end
sequenceDiagram
participant U as User
participant ED as EstimateDropdown
participant T as useTranslation
participant CF as convertMinutesToHoursMinutesString
U->>ED: Open dropdown
ED->>T: Fetch localized strings for labels
ED->>ED: Render options with disabled state
alt Estimate type is TIME
ED->>CF: Format estimate values
end
ED->>U: Display formatted estimates and options
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (1)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
|
Pull Request Linked with Plane Work Items
Comment Automatically Generated by Plane |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (2)
web/core/components/estimates/inputs/index.ts (1)
1-4:⚠️ Potential issueMissing export for time-input module
The index file exports components from three modules (root, number-input, text-input) but appears to be missing the export for the time-input module, which is referenced in the AI summary and exists as part of the files under review.
Add the missing export to maintain consistency with the barrel pattern:
export * from "./root"; export * from "./number-input"; export * from "./text-input"; +export * from "./time-input";web/core/components/estimates/points/update.tsx (1)
94-164: 🛠️ Refactor suggestionStandardize error handling patterns and simplify validation logic.
The error handling is inconsistent, using both the logical AND operator (
&&) and explicitifstatements. Additionally, the validation logic is complex and nested, making it difficult to follow.Consider extracting the validation logic to a separate function and standardizing the error handling pattern:
+ const validateEstimateInput = (value: string, type: TEstimateSystemKeys): { isValid: boolean; errorMessage?: string } => { + // Check for repeated values + const currentEstimatePointValues = estimatePoints + .map((point) => (point?.key != estimatePoint?.key ? point?.value : undefined)) + .filter((value) => value != undefined) as string[]; + + const isRepeated = (type && isEstimatePointValuesRepeated(currentEstimatePointValues, type, value)) || false; + + if (isRepeated) { + return { isValid: false, errorMessage: t("project_settings.estimates.validation.already_exists") }; + } + + // Empty value check + if (!value || value.trim() === "") { + return { isValid: false, errorMessage: t("project_settings.estimates.validation.empty") }; + } + + // Type-specific validation + if ([EEstimateSystem.TIME, EEstimateSystem.POINTS].includes(type)) { + if (isNaN(Number(value))) { + return { isValid: false, errorMessage: t("project_settings.estimates.validation.numeric") }; + } + + if (Number(value) <= 0) { + return { isValid: false, errorMessage: t("project_settings.estimates.validation.min_length") }; + } + } else if (type === EEstimateSystem.CATEGORIES) { + if (isNaN(Number(value)) && value.length > 0) { + return { isValid: true }; + } + return { isValid: false, errorMessage: t("project_settings.estimates.validation.character") }; + } + + return { isValid: true }; + }; const handleUpdate = async (event: FormEvent<HTMLFormElement>) => { event.preventDefault(); if (!workspaceSlug || !projectId) return; handleEstimatePointError && handleEstimatePointError(estimateInputValue || "", undefined, "delete"); if (estimateInputValue) { - const currentEstimateType: EEstimateSystem | undefined = estimateType; - let isEstimateValid = false; - - const currentEstimatePointValues = estimatePoints - .map((point) => (point?.key != estimatePoint?.key ? point?.value : undefined)) - .filter((value) => value != undefined) as string[]; - const isRepeated = - (estimateType && isEstimatePointValuesRepeated(currentEstimatePointValues, estimateType, estimateInputValue)) || - false; - - if (!isRepeated) { - if (currentEstimateType && [EEstimateSystem.TIME, EEstimateSystem.POINTS].includes(currentEstimateType)) { - if (estimateInputValue && !isNaN(Number(estimateInputValue))) { - if (Number(estimateInputValue) <= 0) { - if (handleEstimatePointError) - handleEstimatePointError(estimateInputValue, t("project_settings.estimates.validation.min_length")); - return; - } else { - isEstimateValid = true; - } - } - } else if (currentEstimateType && currentEstimateType === EEstimateSystem.CATEGORIES) { - if (estimateInputValue && estimateInputValue.length > 0 && isNaN(Number(estimateInputValue))) { - isEstimateValid = true; - } - } - - if (isEstimateValid) { + const validation = validateEstimateInput(estimateInputValue, estimateType); + + if (validation.errorMessage && handleEstimatePointError) { + handleEstimatePointError(estimateInputValue, validation.errorMessage); + return; + } + + if (validation.isValid) { // Rest of the code remains the same...
🧹 Nitpick comments (31)
web/core/components/estimates/inputs/number-input.tsx (1)
8-24: Consider adding input constraintsThe component implementation is clean and follows React best practices. However, consider adding
min,max, andstepattributes to provide better constraints for numerical input.<input value={value} onChange={(e) => handleEstimateInputValue(e.target.value)} className="border-none focus:ring-0 focus:border-0 focus:outline-none px-2 py-2 w-full bg-transparent text-sm" placeholder={t("project_settings.estimates.create.enter_estimate_point")} autoFocus type="number" + min="0" + step="1" />web/core/components/estimates/inputs/text-input.tsx (1)
8-24: Consider extracting common input logicThis component shares significant similarities with the
EstimateNumberInputcomponent. Consider creating a base input component that both can extend to reduce code duplication.// Example of a potential base component (in a new file) export const EstimateBaseInput: FC<TEstimateBaseInputProps> = (props) => { const { value, handleEstimateInputValue, type, placeholder, className } = props; return ( <input value={value} onChange={(e) => handleEstimateInputValue(e.target.value)} className={`border-none focus:ring-0 focus:border-0 focus:outline-none w-full bg-transparent text-sm ${className}`} placeholder={placeholder} autoFocus type={type} /> ); };web/core/components/estimates/points/create.tsx (3)
67-67: Use optional chaining for cleaner codeConsider using optional chaining to simplify these conditional checks for better readability.
- if (handleEstimatePointError) handleEstimatePointError(value, undefined); + handleEstimatePointError?.(value, undefined);- if (handleEstimatePointError) handleEstimatePointError(estimateInputValue, undefined, "delete"); + handleEstimatePointError?.(estimateInputValue, undefined, "delete");Also applies to: 76-76
93-94: Use optional chaining for cleaner codeConsider using optional chaining to simplify this nested conditional check.
- if (handleEstimatePointError) - handleEstimatePointError(estimateInputValue, t("project_settings.estimates.validation.min_length")); + handleEstimatePointError?.(estimateInputValue, t("project_settings.estimates.validation.min_length"));
154-159: Refactor conditional checks for cleaner codeThese consecutive conditionals follow the same pattern and can be refactored using optional chaining and potentially introducing a helper function to reduce repetition.
- } else - handleEstimatePointError && - handleEstimatePointError(estimateInputValue, t("project_settings.estimates.validation.already_exists")); - } else - handleEstimatePointError && - handleEstimatePointError(estimateInputValue, t("project_settings.estimates.validation.empty")); + } else { + handleEstimatePointError?.( + estimateInputValue, + isRepeated + ? t("project_settings.estimates.validation.already_exists") + : t("project_settings.estimates.validation.empty") + ); + }🧰 Tools
🪛 Biome (1.9.4)
[error] 155-156: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 158-159: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
web/core/components/estimates/inputs/root.tsx (1)
17-36: Consider refactoring value parsing logic.The parsing of values is currently done inline for different estimate types. Consider extracting this to a helper function to improve maintainability, especially if this parsing logic needs to be used elsewhere.
export const EstimateInputRoot: FC<TEstimateInputRootProps> = (props) => { const { estimateType, handleEstimateInputValue, value } = props; + const parseValue = (value: string | undefined, needsInteger: boolean): string | number | undefined => { + if (!value) return undefined; + return needsInteger ? parseInt(value) : value; + }; + switch (estimateType) { case EEstimateSystem.POINTS: return ( <EstimateNumberInput - value={value ? parseInt(value) : undefined} + value={parseValue(value, true)} handleEstimateInputValue={handleEstimateInputValue} /> ); case EEstimateSystem.CATEGORIES: - return <EstimateTextInput value={value} handleEstimateInputValue={handleEstimateInputValue} />; + return <EstimateTextInput value={parseValue(value, false) as string} handleEstimateInputValue={handleEstimateInputValue} />; case EEstimateSystem.TIME: return ( <EstimateTimeInput - value={value ? parseInt(value) : undefined} + value={parseValue(value, true)} handleEstimateInputValue={handleEstimateInputValue} /> ); default: return null; } };packages/i18n/src/locales/cs/translations.json (4)
1737-1740: Review of the "estimates" Base KeysThe new keys—
"label","title","description", and"no_estimate"—are now defined under"estimates". These entries clearly communicate the purpose of the estimates feature and align with the PR objectives (i.e. enhancing translations). Please verify that the terminology and tone are consistent with other locale files to maintain a cohesive user experience.
1741-1747: Review of the "create" Section within "estimates"The
"create"sub-object now offers multiple options:"custom","start_from_scratch","choose_template","choose_estimate_system", and"enter_estimate_point". The labels are clear and descriptive. Ensure that these translations use terminology consistent with the rest of the application for creating estimates.
1748-1785: Review of the "toasts" Section under "estimates"This segment introduces user feedback messages for various actions (creation, update, enabling, and disabling of estimate points). The messages are informative and follow a structured pattern with both
"success"and"error"details. It is advisable to double-check punctuation and tone consistency across messages—for example, ensuring that message endings and exclamation marks are uniform with similar notifications elsewhere.
1786-1794: Review of the "validation" Section under "estimates"The validation messages are comprehensive, covering minimum length, processing errors, numeric and character constraints, empty values, duplicate checks, and unsaved changes. These should help end users effectively correct input errors. Please confirm that the phrasing (e.g., between "numeric" and "character") and overall tone match the rest of the translation guidelines used in other parts of the application.
packages/i18n/src/locales/ru/translations.json (1)
1739-1797: Comprehensive Addition of "estimates" Translations
The newly added"estimates"section is very detailed and well structured. It includes a label, a title (which appears to be used as a toggle or description for enabling estimates in the project), a description, and further sub-keys such as"no_estimate","create","toasts", and"validation".A few points to consider:
- Tone and Consistency: Ensure that phrases like
"Включить оценки для моего проекта"harmonize with similar UI action descriptions throughout the app. If other toggles or settings use a slightly different tone (for example, a call-to-action phrase), consider unifying the style.- Validation Message Wording: The validation messages are clear; however, examine the
"character"key's message"Значение оценки должно быть символом."to verify it meets the application’s needs. If the requirement is to accept a specific symbol or letter (instead of a numeric value), confirm that the message clearly communicates that to the end user.- Cross-locale Consistency: Since these changes align with updates in other locale files, double-check that the terminology used here (e.g.,
"Оценки","Без оценки") is consistent with those in other languages.If needed, I can help generate a revised proposal for the phrasing for consistency across the UI.
packages/i18n/src/locales/sk/translations.json (3)
1742-1748: Translation of "create" Options
The sub-section under"create"—including options for"custom","start_from_scratch","choose_template","choose_estimate_system", and"enter_estimate_point"—is concise and clear. Ensure that phrases like"Začať od nuly"accurately convey the intended meaning of "start from scratch" for the target audience.
1749-1786: Consistency in "toasts" Messages
This block defines detailed user feedback for actions related to estimates—covering creation, updating, enabling, and disabling. The structure (titles and messages for both success and error cases) is solid. Please review the punctuation, capitalization, and tone across these messages for consistency with the rest of the application’s UI copy.
1787-1795: Validation Messages Accuracy
The validations cover a good range of potential input issues (minimum length, numeric value, character type, empty input, duplicate values, and unsaved changes). However, please verify that both the"numeric"and"character"validation messages are necessary and correctly reflect the underlying business logic for the estimate input.packages/i18n/src/locales/es/translations.json (3)
1741-1744: Consistency in Estimates Translations
The newly added "estimates" block provides key labels for the estimates feature (e.g."label": "Estimaciones","title": "Habilitar estimaciones para mi proyecto","description": "Ayudan a comunicar la complejidad y la carga de trabajo del equipo.", and"no_estimate": "Sin estimación"). Please verify that the tone and terminology match those in other locale files.
1752-1789: Refine Toast Messages for Estimates Actions
The"toasts"object provides detailed success and error messages for operations like creation, updating, enabling, and disabling. For instance, the error message
"No pudimos crear el nuevo punto de estimación, por favor intenta de nuevo."
might be more readable if revised to use a period and proper punctuation (e.g. "No pudimos crear el nuevo punto de estimación. Por favor, inténtalo de nuevo."). Consider applying similar refinements across all toast messages for enhanced clarity and consistency.
1790-1798: Clarify Validation Messages for Estimate Points
The"validation"object delivers several messages to enforce input rules (e.g."min_length","numeric","character", etc.).
• Verify that the term"character"in"El punto de estimación debe ser un valor de carácter."accurately describes the expected input. If the intent is to require text (for example, alphabetical input), consider clarifying it as"alfabético"o"de solo letras", or if it conveys that a non-numeric string is expected, adjust accordingly.
• It is also advisable to standardize punctuation (e.g. ending with a period) across all these messages.packages/i18n/src/locales/id/translations.json (3)
1739-1749: New Estimates Base Keys and Create Options
The newly added keys (i.e.,label,title,description,no_estimate, and the entirecreateobject) clearly introduce the estimates feature in Indonesian. The texts are generally clear and consistent with the tone of other sections. Please double-check that "Aktifkan perkiraan untuk proyek saya" accurately reflects the intended UI action and fits the overall language style used elsewhere in the application.
1750-1788: Toast Messages for Estimates Feature
The structure for the toast messages undertoastsis well organized, with separate entries for created, updated, enabled, and disabled states. The success and error messages are descriptive and should provide clear feedback to the user. Consider standardizing punctuation across the messages for consistency. For example, you might want to ensure that all error messages end with a period.
1788-1796: Validation Messages for Estimates
The validation block covers several conditions such as minimum value, numeric input, empty input, and duplicate values. There is one potential area of ambiguity: the"numeric"key states that the estimate must be a numeric value, while the"character"key says it must be a character value. Please verify whether these validations are mutually exclusive or if they target different types of estimate inputs. If the intent is to require text (for instance, a descriptive label) in some cases versus a numeric input in others, clarifying comments or disambiguated keys might help.A possible refinement for the
"character"message might be:-"character": "Poin perkiraan harus berupa nilai karakter.", +"character": "Poin perkiraan harus berupa teks.",packages/i18n/src/locales/zh-TW/translations.json (1)
1741-1799: Review of Estimates Translation Changes
Key Consistency & Naming:
The PR objectives mentioned updatingestimates.titletoestimates.labeland shiftingestimates.descriptiontoestimates.no_estimate. In this section, you now have a"label", a"title", a"description", and a separate"no_estimate"key. Please verify whether the coexistence of both"title"and"description"(in addition to"label"and"no_estimate") is intentional for supporting different UI contexts or for backward compatibility. If not, consider deprecating the old keys to maintain consistency across locales.New Keys Structure:
The newly introduced keys under"create","toasts", and"validation"(including items like"custom","start_from_scratch","choose_template","choose_estimate_system","enter_estimate_point", along with all success/error messages and validation messages) are well organized. Ensure that these keys mirror similar changes in other locale files to provide a uniform internationalization experience.Translation Accuracy:
The translation for the estimates-related keys (e.g.,"为我的项目启用估算","它们有助于您传达团队的复杂性和工作量。", and"无估算") appears to be clear and appropriate. It could be helpful to have a subject matter expert review these terms to confirm that they best convey the intended meaning to the audience in traditional Chinese usage.packages/i18n/src/locales/ja/translations.json (1)
1739-1797: Ensure Consistency and Clarity in the Estimates Translations
- The new
"estimates"block is structured consistently with other locale files, adding keys for labels, titles, descriptions, creation options, toast messages, and validation messages.- The translations for keys such as
"label": "見積もり","no_estimate": "見積もりなし", and the options in the"create"object (e.g.,"custom": "カスタム","start_from_scratch": "最初から作成") appear accurate and in line with the expected terminology.- In the
"toasts"section, both success and error messages for creation, updates, enabling, and disabling of estimates are clearly defined. The messages use a concise and user-friendly tone.- In the
"validation"section, while most messages are straightforward, please verify the intent of the"character"validation message:
- Current translation:
"見積もりポイントは文字である必要があります。"- This phrasing may be ambiguous compared to the
"numeric"validation. It is worth confirming whether the estimate input can be either numeric or text—or if the message should enforce a specific data type.- Overall, the additions improve internationalization for the estimates feature and should help users receive more precise feedback during estimate-related actions.
packages/i18n/src/locales/en/translations.json (1)
1571-1628: Review of the new "estimates" translations blockThe newly added "estimates" section is structured in a clear and organized manner that mirrors similar sub-sections in the file. It includes keys for the section label, title, description, a nested "create" object, "toasts" for user feedback, and detailed "validation" messages. Overall, the approach enhances internationalization support for the estimates feature.
Points to consider:
- Grammar & Clarity:
- The description currently reads:
"They help you in communicating complexity and workload of the team."
Consider rephrasing for clarity and conciseness, e.g.:
"They help communicate your team's complexity and workload."- The "unsaved_changes" message could be slightly refined. For example,
"You have some unsaved changes, Please save them before clicking on done"
might be updated to:
"You have unsaved changes. Please save them before clicking 'done'."- Validation Consistency:
- Within the "validation" object, there are two messages—one for "numeric" and one for "character"—which might seem contradictory. Please verify the intended data type for estimate points. If only numeric values are expected, you may consider removing or rewording the "character" validation to avoid any ambiguity.
- Punctuation Consistency:
- While most messages end with appropriate punctuation, double-check that similar alerts (especially in the nested "toasts" and "validation" messages) follow a consistent style across the file.
Overall, the additions look solid and align well with the PR’s objectives of enhancing estimates functionality and improving modularity in translations.
web/core/components/estimates/create/stage-one.tsx (1)
80-82: Missing translation for custom description text.The description text "Add your own [system name] from scratch" is still hardcoded and marked with a TODO comment. This should be translated to maintain consistency with the rest of the internationalized UI.
Consider replacing this with a translation key that includes a placeholder for the system name:
- <p className="text-xs text-custom-text-300"> - {/* TODO: Translate here */} - Add your own <span className="lowercase">{currentEstimateSystem.name}</span> from scratch - </p> + <p className="text-xs text-custom-text-300"> + {t("project_settings.estimates.create.custom_description", { + name: currentEstimateSystem.name.toLowerCase() + })} + </p>Then add a corresponding entry in the translation files with a placeholder like:
"custom_description": "Add your own {{name}} from scratch"packages/i18n/src/locales/pt-BR/translations.json (3)
1741-1745: Core Estimates Translations:
The new keys for estimates—label,title,description, andno_estimate—are clearly defined and contextually appropriate. Consider cross-checking these values with the corresponding entries in other locale files to ensure consistency across translations.
1752-1789: Toast Notification Translations Review:
Thetoastssection covers various actions (created, updated, enabled, disabled) comprehensively. A few minor points for consistency:
- The success message for "created" uses “Ponto de estimativa criado” while the updated message uses “Estimativa modificada”. For a unified user experience, consider aligning these—e.g., using “Ponto de estimativa atualizado” for the update case.
- Also, check that the singular versus plural usage (e.g. “estimativa” vs “estimativas”) is consistent throughout the toasts.
A diff suggestion for the updated block could be:- "title": "Estimativa modificada", + "title": "Ponto de estimativa atualizado",This small adjustment would harmonize the terminology with the created toast message.
1790-1798: Validation Message Translations:
The validation messages clearly articulate the input requirements for estimates. They cover conditions such as minimum length, numeric input, non-empty value, and duplicate checks. One note: the message for"character"—"O ponto de estimativa precisa ser um caractere."—might warrant verification against functional requirements. If the expected input is numeric (as indicated by the"numeric"message), ensure that this message accurately reflects the validation rule.packages/i18n/src/locales/de/translations.json (1)
1713-1771: New "estimates" Section is Well-StructuredThe newly added "estimates" block clearly provides all the required translation keys for the estimates feature. The keys such as
"label","title","description","no_estimate","create","toasts", and"validation"mirror a structured approach that should foster consistency throughout the application.
- Please verify that the title
"Schätzungen für mein Projekt aktivieren"precisely conveys the intended call-to-action to enable estimates within a project.- The validation key
"character": "Schätzungspunkt muss ein Zeichenwert sein."is slightly ambiguous. Confirm if the requirement is for a single-character input or if the message should better reflect the expected format.- Ensure that these translations remain consistent with similar keys in other locale files so that the overall user experience is uniform.
packages/i18n/src/locales/it/translations.json (2)
1749-1786: Estimates “Toasts” Messages Block
The"toasts"section now includes detailed feedback for actions (created, updated, enabled, disabled) with nested"success"and"error"messages. The structure is consistent with other parts of the application.
- Nitpick: Consider verifying that all error messages conclude with a period for a uniform punctuation style, if that fits with the rest of your translations.
1787-1795: Estimates “Validation” Messages Update
The validation block provides essential user feedback for common input issues (e.g., minimum length, numeric value, non-empty requirements).
- Suggestion: The translation for the key
"character"reads as"Il punto di stima deve essere un valore carattere."Verify that this wording accurately conveys the intended validation requirement. If the intent is to require a text value, you might consider wording such as"Il punto di stima deve essere un valore testuale."packages/i18n/src/locales/ua/translations.json (1)
1726-1763: Review of Toast Messages in the Estimates SectionThe
"toasts"section delivers feedback for various operations:
- For creation: success and error messages ("Бал оцінки створено" / "Не вдалося створити бал оцінки")
- For updates: success and error messages ("Оцінку змінено" / "Не вдалося змінити оцінку")
- For enabling/disabling: corresponding success and error notifications
The language is direct and clear. However, it might be beneficial to double-check that the tonal style here is consistent with the messaging used in other parts of the app. A minor nitpick: you might consider whether the phrasing (e.g., “Бал оцінки” vs. “Оцінка”) should be standardized for brand consistency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (37)
packages/i18n/src/locales/cs/translations.json(1 hunks)packages/i18n/src/locales/de/translations.json(2 hunks)packages/i18n/src/locales/en/translations.json(1 hunks)packages/i18n/src/locales/es/translations.json(1 hunks)packages/i18n/src/locales/fr/translations.json(1 hunks)packages/i18n/src/locales/id/translations.json(1 hunks)packages/i18n/src/locales/it/translations.json(2 hunks)packages/i18n/src/locales/ja/translations.json(1 hunks)packages/i18n/src/locales/ko/translations.json(1 hunks)packages/i18n/src/locales/pl/translations.json(2 hunks)packages/i18n/src/locales/pt-BR/translations.json(1 hunks)packages/i18n/src/locales/ro/translations.json(1 hunks)packages/i18n/src/locales/ru/translations.json(1 hunks)packages/i18n/src/locales/sk/translations.json(1 hunks)packages/i18n/src/locales/ua/translations.json(2 hunks)packages/i18n/src/locales/vi-VN/translations.json(1 hunks)packages/i18n/src/locales/zh-CN/translations.json(1 hunks)packages/i18n/src/locales/zh-TW/translations.json(1 hunks)packages/ui/src/dropdown/common/options.tsx(2 hunks)packages/ui/src/dropdown/dropdown.d.ts(2 hunks)web/ce/components/estimates/helper.tsx(1 hunks)web/ce/components/estimates/index.ts(1 hunks)web/ce/components/estimates/inputs/index.ts(1 hunks)web/ce/components/estimates/inputs/time-input.tsx(1 hunks)web/ce/components/estimates/points/delete.tsx(1 hunks)web/ce/constants/estimates.ts(1 hunks)web/core/components/dropdowns/estimate.tsx(9 hunks)web/core/components/estimates/create/stage-one.tsx(5 hunks)web/core/components/estimates/estimate-disable-switch.tsx(3 hunks)web/core/components/estimates/estimate-list-item.tsx(2 hunks)web/core/components/estimates/inputs/index.ts(1 hunks)web/core/components/estimates/inputs/number-input.tsx(1 hunks)web/core/components/estimates/inputs/root.tsx(1 hunks)web/core/components/estimates/inputs/text-input.tsx(1 hunks)web/core/components/estimates/points/create.tsx(8 hunks)web/core/components/estimates/points/preview.tsx(4 hunks)web/core/components/estimates/points/update.tsx(6 hunks)
🧰 Additional context used
🧬 Code Definitions (3)
web/core/components/estimates/points/create.tsx (1)
web/core/components/estimates/inputs/root.tsx (1)
EstimateInputRoot(14-37)
web/core/components/estimates/points/update.tsx (1)
web/core/components/estimates/inputs/root.tsx (1)
EstimateInputRoot(14-37)
web/core/components/estimates/inputs/root.tsx (3)
web/core/components/estimates/inputs/number-input.tsx (1)
EstimateNumberInput(8-24)web/core/components/estimates/inputs/text-input.tsx (1)
EstimateTextInput(8-24)web/ce/components/estimates/inputs/time-input.tsx (1)
EstimateTimeInput(8-8)
🪛 Biome (1.9.4)
web/core/components/estimates/points/create.tsx
[error] 127-131: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 155-156: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 158-159: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (82)
packages/i18n/src/locales/pl/translations.json (1)
1716-1773: Comprehensive translation additions for the estimates feature.These new translation keys provide comprehensive Polish language support for the estimates functionality, including labels, descriptions, validation messages, and toast notifications. The structure matches the internationalization pattern used throughout the file.
web/ce/components/estimates/inputs/index.ts (1)
1-1: Export addition for time-based estimate inputs.The new export makes the time input functionality available from the main inputs module, supporting the time estimation features being implemented.
web/ce/components/estimates/index.ts (1)
4-4: Added helper module export to enhance estimate functionality.This export makes helper functions available to components that import from the estimates module, improving code organization and reusability for estimate-related operations.
web/ce/constants/estimates.ts (1)
122-122:Details
✅ Verification successful
Enabled time-based estimation system.
The time estimation system is now enabled by setting
is_availabletotrue. This change aligns with the addition of time input components in the other files and provides users with a time-based estimation option.Verify that any components using this constant properly handle the newly available time estimate system:
🏁 Script executed:
#!/bin/bash # Search for components that check the availability of estimate systems rg -A 3 -B 3 "is_available" --glob "**/*.{ts,tsx}"Length of output: 2839
Time-based estimation system integration confirmed
The updated constant in
web/ce/constants/estimates.tscorrectly setsis_available: true, and our search confirms that components (e.g., inweb/core/components/estimates/create/stage-one.tsx) are checking this flag as expected. The flag is properly integrated into the estimation logic, so no further adjustments are needed.web/ce/components/estimates/helper.tsx (1)
4-13: Function implementation looks goodThe
isEstimateSystemEnabledhelper function correctly implements a switch statement to determine if a specific estimate system is enabled, returning true for POINTS and CATEGORIES systems.packages/ui/src/dropdown/common/options.tsx (2)
53-53: Support for disabled options addedGood addition of the disabled attribute to the Combobox.Option component, which enables proper handling of disabled dropdown options.
70-70: Passing disabled prop to renderItem functionCorrectly passing the disabled state to the renderItem function, ensuring consistent rendering of disabled options across the component.
web/ce/components/estimates/inputs/time-input.tsx (1)
3-6: Well-defined props interfaceThe type definition for TEstimateTimeInputProps is clear and properly defines the expected props for the component.
web/core/components/estimates/estimate-disable-switch.tsx (4)
5-5: Good addition of i18n supportAdding the
useTranslationhook is a great first step toward internationalizing this component.
18-19: Well-structured translation implementationGood implementation of the translation hook with clear code organization using comments.
35-40: Toast messages properly internationalizedGood job replacing hardcoded success messages with translation keys. This ensures consistent messaging across different languages.
45-46: Error toast messages properly internationalizedGood job replacing hardcoded error messages with translation keys.
web/core/components/estimates/inputs/number-input.tsx (1)
1-6: Well-defined component props interfaceThe type definition is clear and properly typed with the optional value parameter and required handler function.
web/core/components/estimates/inputs/text-input.tsx (1)
1-6: Well-defined component props interfaceThe type definition is clear and properly typed with the optional value parameter and required handler function.
web/core/components/estimates/points/create.tsx (5)
6-6: Good addition of i18n supportAdding the
useTranslationhook and organizing the code with clear comments improves maintainability and internationalization support.Also applies to: 46-47
9-9: Good component refactoringImporting the
EstimateInputRootcomponent is a positive step toward better modularity, aligning with the PR objectives.
121-123: Toast messages properly internationalizedGood job replacing hardcoded toast messages with translation keys. This ensures consistent messaging across different languages.
Also applies to: 134-136
150-152: Internationalized validation messagesGood implementation of translated validation messages based on estimate type.
🧰 Tools
🪛 Biome (1.9.4)
[error] 146-152: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
176-180: Good implementation of modular input componentGreat refactoring to use the
EstimateInputRootcomponent, which improves code modularity and maintainability by delegating input rendering to a specialized component.web/core/components/estimates/inputs/root.tsx (2)
1-7: Good job on structuring imports effectively.The imports are well-organized with clear separation between React core, types, and components.
8-12: Well-defined type definition.The
TEstimateInputRootPropstype clearly defines the required properties for this component.web/core/components/estimates/estimate-list-item.tsx (1)
4-10: Good use of utility function for formatting time estimates.The import of
convertMinutesToHoursMinutesStringandEEstimateSystemenhances the component's ability to format time estimates appropriately.web/ce/components/estimates/points/delete.tsx (1)
5-17:Details
✅ Verification successful
Good enhancement of type definition.
The exported
TEstimatePointDeletetype with additional propertiesestimatePointsandestimateSystemprovides better type safety and clearer contracts for the component's props.
🏁 Script executed:
#!/bin/bash # Check if the updated type is properly used in other files rg "TEstimatePointDelete" --type typescriptLength of output: 78
Action: Verify Updated Type Usage Across the Codebase
The update in
web/ce/components/estimates/points/delete.tsx—adding the propertiesestimatePointsandestimateSystemto theTEstimatePointDeletetype—clearly improves type safety and component contract clarity.However, our previous verification attempt returned an error due to an unrecognized file type flag. Please run the shell script above, which uses glob patterns for proper file matching, to ensure that the updated type is correctly imported and used in the repository. After confirming usage across all relevant TypeScript files, you can proceed with confidence.
--- 🏁 Script executed: ```shell #!/bin/bash # Search for all occurrences of "TEstimatePointDelete" in TypeScript files (.ts and .tsx) rg "TEstimatePointDelete" --glob '*.ts' --glob '*.tsx'Length of output: 379
Enhancement Verified and Approved
The updated
TEstimatePointDeletetype has been verified as correctly defined and utilized in the component atweb/ce/components/estimates/points/delete.tsx. The added properties (estimatePointsandestimateSystem) improve type safety and clearly define the component’s contract. There are no further concerns.web/core/components/estimates/points/update.tsx (3)
6-9: Good addition of internationalization support.The integration of the
useTranslationhook from@plane/i18nand theEstimateInputRootcomponent enhances the component's capabilities for internationalization and input handling.
48-49: Good implementation of i18n hook.Adding the translation hook as a separate, clearly commented section improves code organization and readability.
175-179: Good use of the EstimateInputRoot component.Replacing the direct input element with the
EstimateInputRootcomponent encapsulates input rendering logic based on the estimate type, improving component reusability and maintainability.packages/i18n/src/locales/ko/translations.json (4)
1741-1744: Good job adding the new estimates localization keys!The new "label" and "no_estimate" keys have been properly added to match the estimates feature UI requirements. This maintains consistency with other locales.
1745-1751: Well-structured translation keys for estimate creation!The "create" object with nested keys for various estimate creation options provides a good structure for the UI workflow. This makes it easy to maintain and extend the translations in the future.
1752-1789: Comprehensive toast notifications for user feedback!The toast messages for different states (created, updated, enabled, disabled) with both success and error variants provide clear user feedback for all possible scenarios during estimate management.
1790-1798: Well-defined validation messages!The validation section covers all necessary error cases for estimates, from min length to already existing values. Particularly good to see the "unsaved_changes" message which helps prevent data loss.
web/core/components/dropdowns/estimate.tsx (10)
8-9: Good addition of i18n and enum imports!Adding the translation hook and estimate system enum provides the necessary foundations for internationalization and type-specific estimate handling.
67-68: Proper i18n hook implementation!Correctly implemented the translation hook with appropriate comment, following project conventions.
93-93: Enhanced hook usage with currentActiveEstimate!Adding currentActiveEstimate to the destructured values from useProjectEstimates allows for type-specific rendering, which is a good improvement for handling different estimate systems.
110-114: Well-implemented conditional rendering based on estimate type!The conditional rendering logic that formats time estimates differently from other types improves usability by displaying values in a user-friendly format.
123-128: Good replacement of hardcoded strings with translation keys!Replacing the hardcoded "No estimate" string with the translation key maintains consistency in the UI and supports multiple languages.
188-188: Proper tooltip internationalization!Updated tooltip heading to use the translation function, maintaining UI consistency across languages.
196-202: Enhanced display of selected estimate values!The conditional rendering logic for displaying selected estimate values has been improved to handle time estimates properly, providing better user experience.
242-243: Internationalized search placeholder!Good job replacing the hardcoded search placeholder with a translation key for better internationalization support.
255-255: Consistent translation use for "no estimate" message!Replaced hardcoded string with translation key in the dropdown, maintaining consistency with the option added earlier.
282-288: Properly internationalized status messages!Status messages for no matching results and loading state now use translation keys, completing the internationalization of the component.
packages/i18n/src/locales/fr/translations.json (4)
1739-1742: Good addition of French translations for estimates.The addition of French translations for estimate labels and basic terms improves internationalization support, aligning with the PR objective of enhancing the estimates feature with translations.
1743-1749: Complete translation set for estimate creation options.The translations for all creation-related UI elements are well structured and comprehensive. The French terminology chosen appropriately conveys the meaning of each option.
1750-1787: Comprehensive toast notifications in French.Good job including translations for all success and error states for the various estimate operations (creating, updating, enabling, disabling). This ensures a consistent user experience for French-speaking users.
1788-1796: Complete validation messages in French.All necessary validation messages for estimate points have been properly translated, covering different validation scenarios like minimum length, numeric values, and unsaved changes.
web/core/components/estimates/points/preview.tsx (6)
4-4: Good addition of necessary imports.The inclusion of
useTranslation,convertMinutesToHoursMinutesString, andEEstimateSystemcorrectly supports the internationalization and formatting improvements made to this component.Also applies to: 7-7, 12-12
42-43: Properly implemented i18n hook.Good implementation of the translation hook to support internationalization of the component.
58-58: Minor UI improvements.The padding and text size adjustments improve the UI consistency and readability of the estimate point items.
Also applies to: 62-62
64-64: Enhanced display of time-based estimates.The conditional formatting of estimate values based on the estimate type is a good improvement, especially for time-based estimates which now display in a human-readable hours and minutes format instead of raw minute values.
66-68: Internationalized placeholder text.Replacing the hardcoded placeholder with a translated string improves the user experience for non-English users.
116-116: Additional props passed to delete component.Correctly added the
estimatePointsandestimateSystemprops to theEstimatePointDeletecomponent, which ensures the delete component has the necessary context for its operations.Also applies to: 120-120
packages/i18n/src/locales/sk/translations.json (1)
1738-1741: Overall Structure of the "estimates" Module
The newly added "estimates" section is well-organized and clear. Keys such as"label","title","description", and"no_estimate"provide a solid foundation for displaying estimates in the UI. Please double-check that these translations are consistent with similar sections in other locale files.packages/i18n/src/locales/es/translations.json (1)
1745-1751: Clear UI Actions for Creating Estimates
The"create"object includes translations for actions such as"custom","start_from_scratch","choose_template","choose_estimate_system", and"enter_estimate_point". These translations are clear and user-friendly. Please ensure these keys align with UI usage (i.e. that the same identifiers are used across components) and remain consistent with other languages.packages/i18n/src/locales/zh-CN/translations.json (3)
1739-1742: Good addition of the estimates label and description translations.The Chinese translations for the estimates label and description are correctly implemented. This enhances the user experience for Chinese-speaking users.
1743-1749: Comprehensive translation of estimate creation elements.The translations for "no_estimate" and the nested "create" object with its options are well-structured and provide complete coverage for the estimate creation workflow in Chinese.
1750-1787: Toast notifications properly translated with consistent structure.The toast notification translations for the estimates feature follow a consistent pattern with both success and error states for all operations (creation, updates, enabling, disabling). This ensures users receive appropriate feedback in their preferred language.
packages/ui/src/dropdown/dropdown.d.ts (3)
30-38: Support for disabled state in dropdown renderItem function.Adding the optional
disabledparameter to the renderItem function signature enables rendering different UI for disabled dropdown options, enhancing accessibility and user experience.
46-47: Enhanced dropdown option type definition.Making the
selectedparameter optional in the className function and adding the optionaldisabledproperty provides more flexibility for styling and interaction control in dropdown options.
94-96: Consistent type definition update for renderItem in IDropdownOptions.This change maintains consistency with the updated renderItem signature in the IDropdown interface, ensuring type safety throughout the component hierarchy.
packages/i18n/src/locales/vi-VN/translations.json (5)
1714-1715: [Translation Consistency: Label & Title]
The new keys for the estimates header are clearly translated. "Ước tính" and "Bật ước tính cho dự án của tôi" both convey the intended meaning and follow the tone of other UI text in this locale.
1716-1717: [Translation Clarity: Description & No Estimate]
The description—"Chúng giúp bạn truyền đạt độ phức tạp và khối lượng công việc của nhóm."—and the "no_estimate" value "Không có ước tính" are understandable and contextually appropriate. Ensure that the tone matches similar descriptions across other locale files.
1718-1724: [Translation Completeness: Create Section]
The new "create" block with keys such as "custom", "start_from_scratch", "choose_template", "choose_estimate_system", and "enter_estimate_point" has been translated accurately. Each phrase is concise and aligns with the expected user actions.
1725-1762: [Translation Detail: Toasts Messages for Estimates]
The "toasts" section provides clear success and error messages for both creation and update events, as well as feedback when estimates are enabled or disabled. The messages ("Đã tạo điểm ước tính", "Không thể tạo điểm ước tính mới, vui lòng thử lại", etc.) are consistent in tone and informative. It’s advisable to verify these messages against similar toast messages in other locale files to ensure uniformity across the application.
1763-1771: [Translation Accuracy: Validation Messages]
The validation texts—covering conditions like minimum length, numeric and character requirements, empty values, duplicate entries, and unsaved changes—are translated in a user-friendly manner. They clearly instruct the user on the expectations for estimate input. One minor consideration might be to double-check that the term used ("Điểm ước tính") is consistently applied throughout the UI versus possible alternatives like "Giá trị ước tính" in other contexts.packages/i18n/src/locales/ro/translations.json (4)
1739-1742: Good addition of estimate-related translations for the Romanian locale.The translation keys for "label" and "no_estimate" have been properly added to support the internationalization of the estimates feature.
1743-1749: Complete set of create-related translations added.All necessary translations for the estimate creation process have been added, including options for custom estimates, starting from scratch, choosing templates and systems, and entering estimate points.
1750-1787: Comprehensive toast message translations added.A complete set of toast notifications for various estimate operations (create, update, enable, disable) has been added with appropriate success and error messages, maintaining consistency with the application's feedback system.
1788-1796: Validation message translations properly implemented.All necessary validation messages for the estimate feature have been added, covering minimum length requirements, numeric validation, character validation, and other error states such as unsaved changes and duplicate values.
web/core/components/estimates/create/stage-one.tsx (9)
5-5: Translation support properly integrated.The useTranslation hook has been correctly imported from @plane/i18n to enable internationalization in this component.
9-9: Helper functions and utilities properly imported.The code now imports:
- convertMinutesToHoursMinutesString for formatting time values
- isEstimateSystemEnabled helper function for cleaner code
- UpgradeBadge for premium features
- Estimate-related constants
These imports support the refactoring for better internationalization and code organization.
Also applies to: 12-14
25-26: Translation hook properly initialized.The useTranslation hook is correctly set up with clear code organization, including a descriptive comment.
37-37: Code refactored for better maintainability.The logic for determining if an estimate system is enabled has been extracted into a separate helper function, making the code more maintainable and easier to understand.
42-44: Tooltips now use translated content.The "Coming soon" tooltip message now uses the translation function, ensuring consistency across different languages.
46-50: Improved UI for disabled estimate systems.The code now displays an upgrade badge for estimate systems that require a premium plan, and properly disables those options. This enhances the user experience by clearly communicating feature availability.
Also applies to: 55-56
59-59: Radio input label now translated.The "Choose an estimate system" label now uses translations, supporting multi-language interfaces.
71-73: All UI labels now use translation function.Section headers and button texts like "Start from scratch", "Custom", and "Choose a template" now use the translation function, supporting internationalization.
Also applies to: 78-78, 87-89
100-107: Improved template value display logic.The code now properly formats template values based on the estimate system type, converting minutes to a human-readable format for time-based estimates. This provides a better user experience by presenting values in an appropriate format.
packages/i18n/src/locales/pt-BR/translations.json (1)
1745-1751: Create Options for Estimates:
The translations for the creation options (custom,start_from_scratch,choose_template,choose_estimate_system, andenter_estimate_point) are clear and provide good guidance to the users. They effectively convey the available choices for creating estimates.packages/i18n/src/locales/it/translations.json (2)
1738-1741: Estimates Section – Basic Keys Added
The new keys"label","title","description", and"no_estimate"provide the foundational text for the estimates feature. The translations are clear, consistent in tone, and seem to align well with the other sections.
1742-1748: Estimates “Create” Subsection Translations
This block introduces keys under"create"for various estimate creation options such as"custom","start_from_scratch","choose_template","choose_estimate_system", and"enter_estimate_point". The Italian translations are concise and user-friendly.packages/i18n/src/locales/ua/translations.json (3)
1715-1718: Review of Estimates Base KeysThe new keys for the estimates section—specifically:
"label": "Оцінки""title": "Увімкнути оцінки для мого проєкту""description": "Вони допомагають вам у комунікації складності та навантаження команди""no_estimate": "Без оцінки"—provide a clear and user-friendly description for the estimates feature. Please verify that these terms are consistent with the style and terminology used in other locales to maintain uniformity across translations.
1719-1725: Review of the "create" Object for EstimatesThe
"create"block now includes detailed keys:
"custom": "Власний""start_from_scratch": "Почати з нуля""choose_template": "Вибрати шаблон""choose_estimate_system": "Вибрати систему оцінок""enter_estimate_point": "Введіть бал оцінки"These entries clearly outline the available options for creating an estimate. Ensure that these translations accurately reflect the intended user actions and align with similar action labels elsewhere in the application.
1764-1772: Review of Validation Messages for EstimatesThe
"validation"object includes messages such as:
"min_length": "Бал оцінки має бути більшим за 0.""unable_to_process": "Не вдалося обробити ваш запит, спробуйте ще раз.""numeric": "Бал оцінки має бути числовим значенням.""character": "Бал оцінки має бути символьним значенням.""empty": "Значення оцінки не може бути порожнім.""already_exists": "Таке значення оцінки вже існує.""unsaved_changes": "У вас є незбережені зміни. Збережіть їх перед тим, як натиснути 'готово'"The messages are clear; however, the inclusion of both
"numeric"and"character"validations suggests that the system may accept either type of input. Please confirm if this dual-mode validation is intentional. If so, verify that the user interface clearly distinguishes between these input types to avoid potential confusion.
* * chore: refactored estimates components. * chore: added translations for estimates components. * fix: translation key update
3 participants
Description
Added translations to estimates.
Refactored estimates components for better modularity.
Type of Change
Screenshots and Media (if applicable)
Test Scenarios
References
WEB-3737
Summary by CodeRabbit
New Features
Improvements