Marked files for translation #3832
Conversation
✅ Deploy Preview for actualbudget ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Bundle Stats — desktop-clientHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset
View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger
Smaller
Unchanged
|
Bundle Stats — loot-coreHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset No files were changed View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger No assets were bigger Smaller No assets were smaller Unchanged
|
awaisalee
force-pushed
the
feature/i18n-integration
branch
from
7a6b03b to
45b8f08
Compare
awaisalee
changed the title
WalkthroughThe pull request introduces internationalization features across several modal components within the desktop client application. It primarily involves integrating the Possibly related PRs
Suggested labels
Suggested reviewers
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
packages/desktop-client/src/components/modals/EnvelopeBalanceMenuModal.tsxOops! Something went wrong! :( ESLint: 8.57.1 ESLint couldn't find the plugin "eslint-plugin-eslint-plugin". (The package "eslint-plugin-eslint-plugin" was not found when loaded as a Node module from the directory "/packages/eslint-plugin-actual".) It's likely that the plugin isn't installed correctly. Try reinstalling by running the following: The plugin "eslint-plugin-eslint-plugin" was referenced from the config file in "packages/eslint-plugin-actual/.eslintrc.js". If you still can't figure out the problem, please stop by https://eslint.org/chat/help to chat with the team. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (14)
packages/desktop-client/src/components/modals/TrackingBudgetSummaryModal.tsx (1)
29-29: Consider using structured translation keysWhile using English text directly as translation keys works, consider using structured keys for better maintainability and type safety. This helps prevent typos and makes it easier to track translations.
Example improvement:
-title={t('Budget Summary')} +title={t('modals.budget_summary.title')}Benefits:
- Provides better context for translators
- Enables type checking with TypeScript when using type-safe translation keys
- Makes it easier to track missing translations
- Follows i18n best practices for key structuring
packages/desktop-client/src/components/modals/TrackingBalanceMenuModal.tsx (1)
Line range hint
44-104: Consider translating the remaining user-facing stringsWhile the "Balance" string has been internationalized, there are other potential candidates for translation in this component:
- The modal name "tracking-balance-menu" (if used in aria labels or debugging)
- The category name display (though this is likely user data)
Here's how you could enhance the internationalization:
- <Modal name="tracking-balance-menu"> + <Modal name={t('tracking-balance-menu')}>Note: Only proceed with these additional translations if these strings are indeed meant to be shown to users in some form (e.g., accessibility labels, tooltips).
packages/desktop-client/src/components/modals/EnvelopeBalanceMenuModal.tsx (1)
71-71: Consider using a more specific translation keyWhile the translation works, using a generic key like 'Balance' might lead to conflicts or inconsistent translations across different contexts. Consider using a more specific key that includes the component context.
- {t('Balance')} + {t('envelope.balance.label')}packages/desktop-client/src/components/modals/EnvelopeBudgetMenuModal.tsx (1)
87-87: Consider translating additional user-facing strings.While the "Budgeted" string is now properly internationalized, consider also translating the modal name "envelope-budget-menu" to maintain consistency in the internationalization effort.
- <Modal name="envelope-budget-menu"> + <Modal name={t('envelope-budget-menu')}>packages/desktop-client/src/components/modals/TrackingBudgetMenuModal.tsx (1)
87-87: Consider additional translation opportunitiesThe translation of "Budgeted" is correctly implemented. However, consider if the category name (
category.name) should also be translatable depending on your internationalization requirements.If category names should be translatable, consider wrapping them in the translation function:
-title={<ModalTitle title={category.name} shrinkOnOverflow />} +title={<ModalTitle title={t(category.name)} shrinkOnOverflow />}packages/desktop-client/src/components/modals/LoadBackupModal.tsx (2)
84-84: Consider using a more specific translation keyWhile the translation works, using a more specific key like 'modals.backup.title' would better organize translations and avoid potential conflicts.
- title={t('Load Backup')} + title={t('modals.backup.title')}
Line range hint
1-150: Overall implementation looks good with minor suggestionsThe internationalization changes are well-implemented and maintain the component's functionality while making it translation-ready. Consider:
- Using a more structured approach for translation keys (e.g., nested keys like 'modals.backup.messages.warning')
- Adding translation key comments to provide context for translators
To maintain consistency across the application, consider creating a translation key structure guide in the project documentation. This would help maintain a standardized approach as more components are internationalized.
packages/desktop-client/src/components/reports/Header.tsx (1)
97-97: Consider using more specific translation keys and consistent capitalizationWhile the translations are functional, consider these improvements for better maintainability:
- Use more specific keys instead of plain English
- Maintain consistent capitalization in keys
- Consider adding a namespace for reports/header section
Example refactor:
- {t('Static')} + {t('header.mode.static')} - {t('Live')} + {t('header.mode.live')} - {t('to')} + {t('header.date_range.connector')} - {t('1 month')} + {t('header.time_range.one_month')} - {t('3 months')} + {t('header.time_range.three_months')} - {t('6 months')} + {t('header.time_range.six_months')} - {t('1 Year')} + {t('header.time_range.one_year')} - {t('All Time')} + {t('header.time_range.all_time')}Also applies to: 116-116, 140-140, 147-147, 153-153, 159-159, 169-169
packages/desktop-client/src/components/modals/TrackingBudgetMonthMenuModal.tsx (2)
89-91: Consider simplifying the notes conditional expressionWhile the translation is correctly implemented, the ternary expression could be more readable.
Consider this alternative:
-notes={ - originalNotes?.length > 0 ? originalNotes : t('No notes') -} +notes={originalNotes || t('No notes')}This achieves the same result but is more concise, as empty strings and arrays are falsy in JavaScript.
Line range hint
182-184: Fix inconsistent translation patternThere's an untranslated notification message that uses template literals instead of the t function.
Apply this change to maintain consistency with other notification messages:
-message: `${displayMonth} budgets have all been set to ${numberOfMonths === 12 ? 'yearly' : `${numberOfMonths} month`} average.`, +message: t( + '{displayMonth} budgets have all been set to {period} average.', + { + displayMonth, + period: numberOfMonths === 12 ? t('yearly') : t('{n} month', { n: numberOfMonths }) + } +),packages/desktop-client/src/components/modals/EnvelopeBudgetMonthMenuModal.tsx (2)
Line range hint
180-180: Missing translation for average budget messageThis message should be translated like the other notification messages:
- message: `${displayMonth} budgets have all been set to ${numberOfMonths === 12 ? 'yearly' : `${numberOfMonths} month`} average.`, + message: t( + '{displayMonth} budgets have all been set to {period} average.', + { + displayMonth, + period: numberOfMonths === 12 ? t('yearly') : t('{count} month', { count: numberOfMonths }) + } + ),
Line range hint
1-224: Consider implementing i18n type safetyWhile the translations are correctly implemented, consider enhancing type safety for translations:
- Use TypeScript's type system to ensure all translation keys exist
- Consider using a tool like
typesafe-i18nor similar to catch missing translations at compile timepackages/desktop-client/src/components/reports/reports/NetWorth.tsx (1)
252-254: Consider using a shorter translation key.While using full text as translation keys works, it's generally recommended to use shorter, more maintainable keys. This makes it easier to manage translations and reduces the risk of inconsistencies when the same text appears in multiple places.
Consider this approach:
- {t( - 'Net worth shows the balance of all accounts over time, including all of your investments. Your "net worth" is considered to be the amount you'd have if you sold all your assets and paid off as much debt as possible. If you hover over the graph, you can also see the amount of assets and debt individually.', - )} + {t('networth.explanation')}Then add this key-value pair to your translation file:
{ "networth.explanation": "Net worth shows the balance of all accounts over time, including all of your investments. Your \"net worth\" is considered to be the amount you'd have if you sold all your assets and paid off as much debt as possible. If you hover over the graph, you can also see the amount of assets and debt individually." }packages/desktop-client/src/components/select/RecurringSchedulePicker.tsx (1)
397-397: LGTM: Consistent translation of UI elementsAll user-facing strings in the RecurringScheduleTooltip have been properly internationalized. However, there's room for improvement.
Consider also translating the static options in the Select components for consistency:
- 'indefinitely', 'for', 'until' in the end mode dropdown
- 'before', 'after' in the weekend solve dropdown
- Day names in
DAY_OF_WEEK_OPTIONS- 'Day' and 'Last' in the monthly patterns dropdowns
Example for the end mode options:
options={[ - ['never', 'indefinitely'], - ['after_n_occurrences', 'for'], - ['on_date', 'until'], + ['never', t('indefinitely')], + ['after_n_occurrences', t('for')], + ['on_date', t('until')], ]}Also applies to: 434-434, 449-449, 472-472, 508-508, 525-525, 533-533, 539-539
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
upcoming-release-notes/3832.mdis excluded by!**/*.md
📒 Files selected for processing (12)
packages/desktop-client/src/components/modals/EnvelopeBalanceMenuModal.tsx(2 hunks)packages/desktop-client/src/components/modals/EnvelopeBudgetMenuModal.tsx(2 hunks)packages/desktop-client/src/components/modals/EnvelopeBudgetMonthMenuModal.tsx(6 hunks)packages/desktop-client/src/components/modals/EnvelopeBudgetSummaryModal.tsx(4 hunks)packages/desktop-client/src/components/modals/LoadBackupModal.tsx(3 hunks)packages/desktop-client/src/components/modals/TrackingBalanceMenuModal.tsx(2 hunks)packages/desktop-client/src/components/modals/TrackingBudgetMenuModal.tsx(2 hunks)packages/desktop-client/src/components/modals/TrackingBudgetMonthMenuModal.tsx(7 hunks)packages/desktop-client/src/components/modals/TrackingBudgetSummaryModal.tsx(2 hunks)packages/desktop-client/src/components/reports/Header.tsx(6 hunks)packages/desktop-client/src/components/reports/reports/NetWorth.tsx(1 hunks)packages/desktop-client/src/components/select/RecurringSchedulePicker.tsx(10 hunks)
🧰 Additional context used
📓 Learnings (2)
packages/desktop-client/src/components/modals/LoadBackupModal.tsx (1)
Learnt from: tlesicka
PR: actualbudget/actual#3689
File: packages/desktop-client/src/components/modals/LoadBackupModal.tsx:162-190
Timestamp: 2024-11-10T16:45:25.627Z
Learning: Adding progress indicators for backup operations in the budget application requires updates to the server backend, and may be beyond the scope of a single PR.
packages/desktop-client/src/components/modals/TrackingBudgetMenuModal.tsx (2)
Learnt from: qedi-r
PR: actualbudget/actual#3527
File: packages/desktop-client/src/components/accounts/Header.jsx:0-0
Timestamp: 2024-11-10T16:45:25.627Z
Learning: In the Actual Budget project, importing `t` directly from 'i18next' is acceptable and commonly used in the codebase.
Learnt from: qedi-r
PR: actualbudget/actual#3527
File: packages/desktop-client/src/components/accounts/Header.jsx:0-0
Timestamp: 2024-11-10T16:45:25.627Z
Learning: In the Actual Budget project, importing `t` directly from 'i18next' is acceptable and commonly used in the codebase.
🔇 Additional comments (28)
packages/desktop-client/src/components/modals/TrackingBudgetSummaryModal.tsx (3)
2-2: LGTM: Import statement is correctly placed
The useTranslation hook import is properly added and necessary for implementing internationalization.
22-22: LGTM: Hook usage follows React best practices
The useTranslation hook is correctly implemented at the component's top level, following React hooks rules.
Line range hint 34-46: Verify translation coverage in child components
While the modal title is now translatable, ensure that the child components (IncomeTotal, ExpenseTotal, and Saved) also support translations for a consistent user experience.
✅ Verification successful
Translation support is properly implemented in all child components
All three components (IncomeTotal, ExpenseTotal, and Saved) already have proper translation support:
- They import and use
useTranslationhook fromreact-i18next - All visible strings are wrapped in translation functions:
IncomeTotal: Usest('Income')ExpenseTotal: Usest('Expenses')Saved: UsesTranscomponent andt()for multiple strings including "Projected Savings", "Overspent", "Saved", etc.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if child components have translation support
echo "Checking translation implementation in child components..."
# Search for translation usage in related components
rg -l "useTranslation|react-i18next" "packages/desktop-client/src/components/budget/tracking/budgetsummary/"
# Search for potential hardcoded strings in these components
echo "Checking for potential hardcoded strings..."
rg -i "total|saved|income|expense" "packages/desktop-client/src/components/budget/tracking/budgetsummary/" \
--type tsx \
--glob '!*.test.{ts,tsx}' \
-C 2
Length of output: 1020
Script:
#!/bin/bash
# Let's check the content of these components to verify translation implementation
echo "Checking IncomeTotal component..."
cat packages/desktop-client/src/components/budget/tracking/budgetsummary/IncomeTotal.tsx
echo -e "\nChecking ExpenseTotal component..."
cat packages/desktop-client/src/components/budget/tracking/budgetsummary/ExpenseTotal.tsx
echo -e "\nChecking Saved component..."
cat packages/desktop-client/src/components/budget/tracking/budgetsummary/Saved.tsx
Length of output: 4612
packages/desktop-client/src/components/modals/TrackingBalanceMenuModal.tsx (3)
6-6: LGTM: Import statement follows i18next conventions
The import of the t function from i18next is correctly implemented.
69-69: LGTM: String translation implementation is correct
The hardcoded "Balance" string has been properly replaced with the translation function call.
Line range hint 1-104: Verify i18next initialization
Since this is one of the first files being marked for translation, we should ensure that i18next is properly initialized in the application.
✅ Verification successful
Let me try a different search pattern to find i18next initialization and configuration.
Let me search for i18next initialization code in the codebase.
i18next is properly initialized and configured
The codebase has proper i18next initialization:
- i18next is initialized in a dedicated
i18n.tsfile - It uses
initReactI18nextandi18next-resources-to-backendfor loading translations - The initialization file is imported at the application entry point (index.tsx)
- Language files are loaded dynamically from the
localedirectory - Default language is set to 'en' with ability to override via localStorage
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for i18next setup files and initialization
echo "Checking for i18next configuration..."
rg -l "i18next" --type ts --type tsx packages/desktop-client/src/
echo "\nChecking for translation initialization..."
ast-grep --pattern 'i18next.init'
Length of output: 6063
Script:
#!/bin/bash
# Search for i18next configuration and initialization with proper file type
echo "Checking for i18next configuration..."
rg -l "i18next" packages/desktop-client/src/
echo "\nChecking for i18next initialization code..."
rg -A 5 "i18next" packages/desktop-client/src/
Length of output: 136238
Script:
#!/bin/bash
# Check for i18next initialization in i18n.ts
echo "Checking i18next initialization in i18n.ts..."
cat packages/desktop-client/src/i18n.ts
# Check for i18next usage in app entry points
echo "\nChecking i18next usage in app entry points..."
rg -A 5 "import.*i18n" packages/desktop-client/src/index.tsx
Length of output: 1290
packages/desktop-client/src/components/modals/EnvelopeBalanceMenuModal.tsx (1)
6-7: LGTM: Clean import of translation function
The import of the t function from i18next is properly placed and follows the project's import organization.
packages/desktop-client/src/components/modals/EnvelopeBudgetMenuModal.tsx (1)
8-8: LGTM! Import of i18next translation function.
The import is correctly placed and aligns with the internationalization objective.
packages/desktop-client/src/components/modals/TrackingBudgetMenuModal.tsx (2)
8-8: LGTM: Import follows project conventions
The direct import of t from 'i18next' aligns with the project's established practices.
Line range hint 89-106: Verify number formatting localization
While text translation is being implemented, ensure that number formatting (including currency symbols and decimal separators) is properly handled for different locales. The FocusableAmountInput component and the integerToAmount/amountToInteger utilities should respect the user's locale settings.
✅ Verification successful
Based on the shell script results, I can now generate the final response since I have enough information about the number formatting implementation:
Number formatting is properly localized
The codebase already handles number formatting localization correctly through:
- A locale-aware
Intl.NumberFormatformatter inpackages/loot-core/src/shared/util.tsthat's used by the currency formatting functions - Proper separation between storage (integer cents) and display (decimal amounts) through
integerToAmount/amountToIntegerutility functions - Consistent usage of these utilities throughout the codebase for all amount conversions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if number formatting utilities handle localization
rg -A 5 "integerToAmount|amountToInteger" "packages/desktop-client/src" "packages/loot-core/src"
# Look for any existing locale-aware number formatting
ast-grep --pattern 'new Intl.NumberFormat'
Length of output: 64370
packages/desktop-client/src/components/modals/EnvelopeBudgetSummaryModal.tsx (2)
2-2: LGTM: Translation setup is correctly implemented
The useTranslation hook is properly imported and initialized at the component level, following React i18n best practices.
Also applies to: 39-39
Line range hint 1-138: Test translations with different locales
The translation implementation looks good overall. To ensure completeness:
- Test the component with different locales to verify all strings are properly translated
- Verify that dynamic content (numbers, dates, currency) is formatted according to locale conventions
#!/bin/bash
# Check for any remaining hardcoded strings in the file
echo "Checking for potential hardcoded strings..."
rg -n "['\"][A-Za-z\s]+['\"]" packages/desktop-client/src/components/modals/EnvelopeBudgetSummaryModal.tsx
# Look for translation keys in the locale files
echo "Verifying translation keys exist..."
fd -e json -e yaml "translation" | xargs rg "Transfer: To Budget|Cover: Overbudgeted|Budget Summary"packages/desktop-client/src/components/modals/LoadBackupModal.tsx (3)
1-2: LGTM: Clean import addition
The useTranslation hook is properly imported alongside other React imports.
77-77: LGTM: Proper hook initialization
The useTranslation hook is correctly initialized within the component scope.
100-139: Verify translations for critical warning messages
The translations are properly implemented, especially for the critical warning messages about device sync and backup implications. However, we should ensure these important messages are properly translated across all supported languages to maintain their clarity and impact.
packages/desktop-client/src/components/reports/Header.tsx (3)
2-2: LGTM: Translation hook import added correctly
The useTranslation hook is properly imported from react-i18next.
64-64: LGTM: Translation hook initialized properly
The useTranslation hook is correctly initialized and destructured at the component's top level, following React hooks best practices.
Line range hint 173-177: Verify translations in child components
Please ensure that the text in child components FilterButton and AppliedFilters is also marked for translation.
Also applies to: 195-203
✅ Verification successful
Let me check the FiltersMenu.jsx file since it's in JSX format and verify its content.
No translation issues found in child components
Based on the verification results, all text strings that need translation in the child components are properly handled:
FiltersMenu.jsxuses the translation hook (useTranslation) andTranscomponent fromreact-i18nextFilterExpression.tsxuses the translation hook (useTranslation) and properly translates UI elements including the "Delete filter" button labelConditionsOpMenu.tsxdoesn't contain any hardcoded UI strings that need translationAppliedFilters.tsxonly contains structural code without user-facing strings
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if FilterButton and AppliedFilters components contain hardcoded strings
echo "Checking FilterButton component..."
rg -l "FilterButton" packages/desktop-client/src/components/filters/
echo "Checking for hardcoded strings in these files..."
rg -i "['\"](.*?)['\"]" packages/desktop-client/src/components/filters/FiltersMenu.tsx
echo "Checking AppliedFilters component..."
rg -l "AppliedFilters" packages/desktop-client/src/components/filters/
echo "Checking for hardcoded strings in these files..."
rg -i "['\"](.*?)['\"]" packages/desktop-client/src/components/filters/AppliedFilters.tsx
Length of output: 1392
Script:
#!/bin/bash
# Check FiltersMenu.jsx for hardcoded strings
echo "Checking FiltersMenu.jsx content..."
rg -i "['\"](.*?)['\"]" packages/desktop-client/src/components/filters/FiltersMenu.jsx
# Also check FilterExpression since it's imported in AppliedFilters
echo "Checking FilterExpression content..."
rg -l "FilterExpression" packages/desktop-client/src/components/filters/
rg -i "['\"](.*?)['\"]" packages/desktop-client/src/components/filters/FilterExpression.tsx
# Check ConditionsOpMenu as well since it's used
echo "Checking ConditionsOpMenu content..."
rg -i "['\"](.*?)['\"]" packages/desktop-client/src/components/filters/ConditionsOpMenu.tsx
Length of output: 7738
packages/desktop-client/src/components/modals/TrackingBudgetMonthMenuModal.tsx (3)
3-3: LGTM: Proper i18n setup
The internationalization setup follows best practices with proper import and hook initialization.
Also applies to: 31-31
Line range hint 1-214: Verify translation key definitions
Let's ensure all translation keys used in this component are defined in the translation files.
#!/bin/bash
# Extract all translation keys used in this file
echo "Translation keys used in TrackingBudgetMonthMenuModal:"
rg "t\(['\"]([^'\"]*)['\"]\)" packages/desktop-client/src/components/modals/TrackingBudgetMonthMenuModal.tsx -o -r '$1'
# Check if these keys exist in the translation files
echo -e "\nSearching for these keys in translation files:"
rg "(['\"]No notes['\"]|['\"]Edit notes['\"]|['\"]Actions['\"])" packages/desktop-client/src/locales/120-120: Verify translation key consistency across components
The button labels are correctly translated, but we should verify that these translation keys are used consistently across similar modal components.
Also applies to: 150-150
✅ Verification successful
Translation keys are consistently used across modal components
The translation keys "Edit notes" and "Actions" are consistently used across multiple modal components in the codebase:
- "Edit notes" appears in 5 modal components (TrackingBudgetMonth, EnvelopeBudgetMonth, Account, CategoryGroup, and Category)
- "Actions" appears in 3 modal components (TrackingBudgetMonth, EnvelopeBudgetMonth, and SelectLinkedAccounts)
This consistent usage across similar components indicates proper translation key reuse and maintainability.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for 'Edit notes' and 'Actions' translations in other modal components
rg "('Edit notes'|\"Edit notes\")" packages/desktop-client/src/components/modals/
rg "('Actions'|\"Actions\")" packages/desktop-client/src/components/modals/
Length of output: 576
Script:
#!/bin/bash
# Let's search for translation keys in the entire codebase
fd . -t f -e ts -e tsx -e js -e jsx | xargs rg "t\(['\"]Edit notes['\"]\)" -l
fd . -t f -e ts -e tsx -e js -e jsx | xargs rg "t\(['\"]Actions['\"]\)" -l
# Also search for potential translation files
fd "translations|locales|i18n" --type f
Length of output: 891
packages/desktop-client/src/components/modals/EnvelopeBudgetMonthMenuModal.tsx (3)
3-3: LGTM: Translation setup is correct
The import and initialization of the translation hook follow React best practices.
Also applies to: 60-60
118-118: LGTM: Button text translations are properly implemented
Button labels are correctly wrapped with the translation function.
Also applies to: 148-148
160-163: LGTM: Notification messages properly handle translations with variables
The notification messages correctly use the translation function with proper variable interpolation for displayMonth.
Also applies to: 170-173, 191-194, 201-204, 211-214
packages/desktop-client/src/components/reports/reports/NetWorth.tsx (1)
249-249: LGTM! Text properly marked for translation.
The heading text is correctly wrapped with the translation function.
packages/desktop-client/src/components/select/RecurringSchedulePicker.tsx (3)
10-10: LGTM: Import for i18next translation function
The addition of the i18next import is appropriate for implementing internationalization.
320-320: LGTM: Translated aria-labels for accessibility
The aria-labels for add/remove buttons have been properly internationalized while maintaining accessibility.
Also applies to: 333-333
575-575: LGTM: Translated default text
The default text for no recurring date has been properly internationalized.
packages/desktop-client/src/components/modals/EnvelopeBudgetSummaryModal.tsx
Show resolved
Hide resolved
packages/desktop-client/src/components/modals/EnvelopeBudgetSummaryModal.tsx
Show resolved
Hide resolved
|
@youngcw @MikesGlitch, Could you please review PR? |
|
@awaisalee I know I'm a little late to this, but didn't look at this until I was syncing my PR's with the master. No problems, just a question. Again, no issues, just curious as to which way I should code things in the future. I have another PR that I'm working on that will create a couple new modals and want to have consistency with what is already established. @MikesGlitch or @youngcw if either of you have any thoughts, let me know. |
|
My only thoughts about it are we can't enforce a code styling rule if it's not in lint. New people won't know about it (which is important for open source). I prefer using |
Marked files for translation: