Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

[WIP] Marked files for translation #3548

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

a-gradina
Copy link
Contributor

Marked the following files for translation:

  • packages/desktop-client/src/components/reports/DateRange.tsx
  • packages/desktop-client/src/components/reports/ReportLegend.tsx
  • packages/desktop-client/src/components/reports/ReportOptions.ts
  • packages/desktop-client/src/components/reports/disabledList.ts
  • packages/desktop-client/src/components/reports/getLiveRange.ts
  • packages/desktop-client/src/components/reports/index.tsx

@actual-github-bot actual-github-bot bot changed the title Marked files for translation [WIP] Marked files for translation Oct 3, 2024
Copy link
Contributor

coderabbitai bot commented Oct 3, 2024

Walkthrough

This pull request implements internationalization support across several components in the desktop client application. The changes involve replacing hardcoded strings with translation function calls from the react-i18next library, allowing for dynamic translation based on user language preferences. Key components affected include DateRange, ReportLegend, ReportOptions, disabledList, getLiveRange, and index.tsx, ensuring that user-facing text is translatable while maintaining the original logic and structure of each component.

Changes

File Path Change Summary
.../reports/ReportOptions.ts Updated various fields in defaultReport, balanceTypeOptions, dateRangeOptions, and intervalOptions to utilize the t() function for translation.
.../reports/DateRange.tsx Added internationalization support by integrating useTranslation and Trans hooks, replacing hardcoded strings with translatable strings.
.../reports/ReportLegend.tsx Integrated useTranslation to replace hardcoded 'Interval' string with a translatable version.
.../reports/disabledList.ts Replaced hardcoded strings in intervalOptions, currentIntervalOptions, totalGraphOptions, and timeGraphOptions with calls to the t() function.
.../reports/getLiveRange.ts Modified getLiveRange function to use t() for localized string checks instead of hardcoded values.
.../reports/index.tsx Added localization support by using useTranslation to replace the hardcoded loading message with a translatable string.

Possibly related PRs

  • Marked files for translation #3444: This PR introduces internationalization support in various components, which aligns with the main PR's focus on enhancing localization capabilities by replacing hardcoded strings with translatable calls to the t() function.
  • SpendingReport: Fixing some display issues #3451: This PR includes changes to the ReportLegend component, which also utilizes the t() function for translation, directly connecting it to the main PR's goal of improving internationalization in report-related components.
  • ♻️ (synced-prefs) separate metadata and local prefs out #3458: This PR adds the useTranslation hook in the FinancesApp component, similar to the main PR's changes, which enhance the application's internationalization features by integrating translation capabilities.

Suggested labels

#sparkles: Merged

Suggested reviewers

  • carkom
  • matt-fidd

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 225df29 and d1945c7.

⛔ Files ignored due to path filters (1)
  • upcoming-release-notes/3548.md is excluded by !**/*.md
📒 Files selected for processing (1)
  • packages/desktop-client/src/components/reports/ReportOptions.ts (20 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • packages/desktop-client/src/components/reports/ReportOptions.ts

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

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

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

CodeRabbit Commands (Invoked using PR comments)

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

Other keywords and placeholders

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

CodeRabbit Configuration File (.coderabbit.yaml)

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

Documentation and Community

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

Copy link

netlify bot commented Oct 3, 2024

Deploy Preview for actualbudget ready!

Name Link
🔨 Latest commit d1945c7
🔍 Latest deploy log https://app.netlify.com/sites/actualbudget/deploys/66ff5e5c0951ef0009ab4554
😎 Deploy Preview https://deploy-preview-3548.demo.actualbudget.org
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link
Contributor

github-actions bot commented Oct 3, 2024

Bundle Stats — desktop-client

Hey 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

Files count Total bundle size % Changed
9 5.29 MB → 5.29 MB (+471 B) +0.01%
Changeset
File Δ Size
src/components/reports/DateRange.tsx 📈 +206 B (+10.56%) 1.91 kB → 2.11 kB
src/components/reports/index.tsx 📈 +37 B (+7.68%) 482 B → 519 B
src/components/reports/ReportLegend.tsx 📈 +37 B (+4.22%) 876 B → 913 B
src/components/reports/disabledList.ts 📈 +105 B (+2.69%) 3.82 kB → 3.92 kB
src/components/reports/ReportOptions.ts 📈 +80 B (+1.18%) 6.63 kB → 6.71 kB
src/components/reports/getLiveRange.ts 📈 +6 B (+0.54%) 1.08 kB → 1.08 kB
View detailed bundle breakdown

Added

No assets were added

Removed

No assets were removed

Bigger

Asset File Size % Changed
static/js/ReportRouter.js 1.5 MB → 1.5 MB (+434 B) +0.03%
static/js/index.js 3.32 MB → 3.32 MB (+37 B) +0.00%

Smaller

No assets were smaller

Unchanged

Asset File Size % Changed
static/js/AppliedFilters.js 20.96 kB 0%
static/js/usePreviewTransactions.js 1.64 kB 0%
static/js/resize-observer.js 18.37 kB 0%
static/js/indexeddb-main-thread-worker-e59fee74.js 13.5 kB 0%
static/js/BackgroundImage.js 122.29 kB 0%
static/js/narrow.js 81.98 kB 0%
static/js/wide.js 225.26 kB 0%

Copy link
Contributor

github-actions bot commented Oct 3, 2024

Bundle Stats — loot-core

Hey 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

Files count Total bundle size % Changed
1 1.19 MB 0%

Changeset

No files were changed

View detailed bundle breakdown

Added

No assets were added

Removed

No assets were removed

Bigger

No assets were bigger

Smaller

No assets were smaller

Unchanged

Asset File Size % Changed
kcab.worker.js 1.19 MB 0%

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (6)
packages/desktop-client/src/components/reports/ReportLegend.tsx (2)

38-40: LGTM with a suggestion: Consider extracting the translation.

The changes correctly implement internationalization for the 'Interval' string while maintaining the existing logic. However, to improve readability and maintainability, consider extracting the translation to a constant.

Here's a suggested refactor:

+ const intervalText = t('Interval');
- {groupBy === t('Interval')
+ {groupBy === intervalText
    ? ReportOptions.intervalMap.get(interval)
    : groupBy}

This change would make the code more readable and ensure consistent use of the translated string if needed elsewhere in the component.


2-2: Summary: Successful implementation of internationalization support.

The changes in this file successfully introduce internationalization support using react-i18next. The modifications are minimal, focused, and preserve the existing functionality while allowing for translation of the 'Interval' text. This implementation aligns well with the PR objective of marking files for translation.

As the project moves forward with internationalization, consider the following recommendations:

  1. Ensure consistent use of the useTranslation hook across all components that require text translation.
  2. Create a centralized location for managing translation keys to maintain consistency and ease of management.
  3. Implement a process for extracting and managing translation strings to facilitate the work of translators.

Also applies to: 18-18, 38-40

packages/desktop-client/src/components/reports/getLiveRange.ts (2)

Line range hint 45-49: LGTM: Internationalization implemented correctly.

The changes correctly implement internationalization for the strings 'This month' and 'This week' using the t function. This is consistent with the PR objective of marking files for translation.

Consider extracting these translated strings into constants at the top of the file for better maintainability:

const THIS_MONTH = t('This month');
const THIS_WEEK = t('This week');

// Then use these constants in the function:
[THIS_MONTH, THIS_WEEK].includes(cond)

This approach can make it easier to manage and update these strings in the future.


Line range hint 1-58: Summary: Successful implementation of internationalization.

The changes in this file successfully implement internationalization for two key strings used in the getLiveRange function. These modifications align well with the PR objective of marking files for translation. The overall structure and logic of the function remain intact, ensuring that existing functionality is preserved while adding support for localization.

As the project moves forward with internationalization, consider the following recommendations:

  1. Implement a consistent strategy for managing translated strings across the entire project.
  2. Use a translation management system to keep track of all strings that need translation.
  3. Consider adding context comments for translators to ensure accurate translations in different scenarios.
  4. Implement a process for testing the application with different languages to catch any layout or formatting issues early.
packages/desktop-client/src/components/reports/DateRange.tsx (1)

Line range hint 58-71: LGTM with a minor suggestion: t function used correctly for translations.

The t function is properly used to translate "Compare" and "to". However, there's a minor inconsistency in spacing around the translated "to".

Consider adjusting the spacing for consistency:

-        {type ? t(' to ') : ' - '}
+        {type ? ` ${t('to')} ` : ' - '}

Apply this change to both lines 60 and 71 for consistency.

packages/desktop-client/src/components/reports/ReportOptions.ts (1)

307-307: Consider adding a translation comment to provide context.

While the change itself is fine, consider adding a translation comment above the line to provide context for translators. This can help ensure accurate translations and maintain consistency across languages.

// Translators: This comment describes the purpose of the sorting logic below.
+ // It sorts categories based on their income status, group sort order, and individual sort order.
  Number(catGroupA.is_income) - Number(catGroupB.is_income) ||
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 3f85aed and 225df29.

📒 Files selected for processing (6)
  • packages/desktop-client/src/components/reports/DateRange.tsx (5 hunks)
  • packages/desktop-client/src/components/reports/ReportLegend.tsx (3 hunks)
  • packages/desktop-client/src/components/reports/ReportOptions.ts (11 hunks)
  • packages/desktop-client/src/components/reports/disabledList.ts (2 hunks)
  • packages/desktop-client/src/components/reports/getLiveRange.ts (2 hunks)
  • packages/desktop-client/src/components/reports/index.tsx (1 hunks)
🔇 Additional comments (28)
packages/desktop-client/src/components/reports/index.tsx (4)

1-1: LGTM: Import statement for localization.

The import of useTranslation from 'react-i18next' is correctly added and aligns with the PR objective of marking files for translation.


7-7: LGTM: Initialization of translation function.

The useTranslation hook is correctly used to initialize the t function, enabling localization within the component.


13-13: LGTM: Localization of loading message.

The loading message is now correctly wrapped with the t function, enabling its localization. This change is consistent with the PR objective of marking files for translation.


1-13: Overall assessment: Localization support successfully implemented.

The changes in this file consistently implement localization support by introducing the useTranslation hook and applying it to the loading message. These modifications align well with the PR objective of marking files for translation.

packages/desktop-client/src/components/reports/ReportLegend.tsx (2)

2-2: LGTM: Correct import for internationalization.

The import statement for useTranslation from 'react-i18next' is correctly added, which is necessary for the internationalization changes in the component.


18-18: LGTM: Correct usage of useTranslation hook.

The useTranslation hook is properly utilized to obtain the translation function t. This setup allows for easy internationalization of the component's text content.

packages/desktop-client/src/components/reports/getLiveRange.ts (1)

1-1: LGTM: Import statement for internationalization.

The import of the t function from 'i18next' is correctly placed and necessary for the internationalization changes in the file.

packages/desktop-client/src/components/reports/DateRange.tsx (5)

2-2: LGTM: Internationalization imports added correctly.

The import of useTranslation and Trans from 'react-i18next' is correctly placed and necessary for the internationalization changes in this file.


30-31: LGTM: useTranslation hook initialized correctly.

The useTranslation hook is properly initialized and destructured. The added empty line improves code readability.


40-40: LGTM: Error message wrapped with Trans component.

The error message "There was a problem loading your date range" is correctly wrapped with the Trans component, making it ready for internationalization.


49-52: LGTM: Comparison text wrapped with Trans component.

The comparison text is correctly wrapped with the Trans component, including proper handling of dynamic content (date formatting and conditional text). This change effectively prepares the text for internationalization.


Line range hint 1-83: Summary: Internationalization changes implemented correctly.

The changes to add internationalization support to the DateRange component have been implemented correctly. The useTranslation hook and Trans component from react-i18next are used appropriately throughout the file. The component's core functionality remains intact while adding proper translation support for all user-facing strings.

A minor suggestion was made for spacing consistency around the translated "to" text, but overall, the changes are well-implemented and ready for use.

packages/desktop-client/src/components/reports/disabledList.ts (5)

1-18: LGTM: Internationalization applied correctly

The import of the t function and its application to the intervalOptions array are implemented correctly. This change successfully prepares these strings for translation.


24-40: LGTM: Internationalization applied consistently

The description fields in the currentIntervalOptions array have been correctly wrapped with the t function, maintaining consistency with the internationalization approach.


58-84: LGTM: Internationalization applied correctly to totalGraphOptions

The defaultSplit, defaultType, and disabledSplit fields in the totalGraphOptions array have been correctly wrapped with the t function. The array of strings in the disabledSplit field for the 'AreaGraph' option has been properly internationalized as well.


92-110: LGTM: Internationalization applied correctly to timeGraphOptions

The defaultSplit, defaultType, and disabledSplit fields in the timeGraphOptions array have been correctly wrapped with the t function. The array of strings in the disabledType field for the 'TableGraph' option has been properly internationalized as well.


Line range hint 1-110: Summary: Successful internationalization of string literals

The changes in this file successfully prepare it for translation by wrapping all relevant string literals with the t function from i18next. The modifications are consistent and don't alter the functionality of the code. This update aligns well with the PR objective of marking files for translation.

Key points:

  1. All string literals in intervalOptions, currentIntervalOptions, totalGraphOptions, and timeGraphOptions arrays have been internationalized.
  2. The changes maintain the existing structure and logic of the code.
  3. Exported functions and constants remain unchanged, as they didn't require direct internationalization.

These changes lay the groundwork for future localization efforts in the application.

packages/desktop-client/src/components/reports/ReportOptions.ts (11)

21-25: LGTM!

The changes to the defaultReport object look good. The hardcoded string literals for dateRange, groupBy, interval, and balanceType have been replaced with calls to the t() function, enabling translation for these properties.


37-41: LGTM!

The description fields in the balanceTypeOptions array have been updated to use the t() function for translation. This change is consistent and appropriate.


45-49: LGTM!

The description fields in the groupByOptions array have been updated to use the t() function for translation. This change is consistent and appropriate.


64-147: LGTM!

The description and type fields in the dateRangeOptions array have been updated to use the t() function for translation. This change is consistent and appropriate across all date range options.


168-189: LGTM!

The description and name fields in the intervalOptions array have been updated to use the t() function for translation. This change is consistent and appropriate across all interval options.


256-256: LGTM!

The name property of the uncategorizedCategory object has been updated to use the t() function for translation. This change is consistent with the overall internationalization effort.


265-265: LGTM!

The name property of the transferCategory object has been updated to use the t() function for translation. This change is consistent with the overall internationalization effort.


274-274: LGTM!

The name property of the offBudgetCategory object has been updated to use the t() function for translation. This change is consistent with the overall internationalization effort.


290-290: LGTM!

The name property of the uncategorizedGroup object has been updated to use the t() function for translation. This change is consistent with the overall internationalization effort.


341-368: LGTM!

The case statements in the groupBySelections function have been updated to use the t() function for translation. This change ensures that the grouping options are properly translated based on the selected language.


1-1: Ensure the i18next library is installed and properly configured.

Verify that the i18next library is installed in the project and properly configured to support internationalization. This includes setting up the necessary language files, configuring the fallback language, and initializing the library with the appropriate options.

Run the following script to verify the i18next setup:

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (6)
packages/desktop-client/src/components/reports/index.tsx (2)

13-13: Consider using a specific translation key.

The implementation of localization for the loading message is correct. However, using the English text as the translation key might lead to maintenance issues in the future.

Consider using a more specific translation key:

-        message={t('Loading reports...')}
+        message={t('reports.loading_message')}

This approach would make it easier to manage translations if the English text changes and helps ensure uniqueness across the application.


Line range hint 1-20: Summary: Localization successfully implemented.

The changes in this file successfully introduce localization support to the Reports component. The implementation is correct and aligns with the PR objective of marking files for translation.

Next steps to consider:

  1. Implement a consistent strategy for translation keys across the application.
  2. Ensure that all user-facing strings in this component are localized.
  3. Create translation files for different languages.
  4. Set up a process for managing and updating translations.
packages/desktop-client/src/components/reports/getLiveRange.ts (1)

45-47: Approve changes with suggestion for improvement.

The use of the t function for translating 'This month' and 'This week' is a good step towards localization. However, there's room for improvement in the translation approach.

Consider using translation keys instead of directly translating the English strings. This approach is more maintainable and less error-prone. For example:

[t('report.this_month'), t('report.this_week')].includes(t(cond))

This assumes that cond is already a translation key. If it's not, you might need to create a mapping between the English strings and their corresponding translation keys.

packages/desktop-client/src/components/reports/DateRange.tsx (1)

58-60: Consider combining phrases for better translation support.

The t function is correctly used for translating shorter phrases. However, separating "Compare" and "to" into individual translations might cause issues with languages that have different word orders.

Consider combining these phrases into a single translation string with placeholders. For example:

t('Compare {{startDate}} to {{endDate}}', {
  startDate: d.format(startDate, 'MMM yyyy'),
  endDate: ['budget', 'average'].includes(type || '')
    ? type
    : d.format(endDate, 'MMM yyyy')
})

This approach would allow translators to rearrange the words as needed for their language.

Also applies to: 69-71

packages/desktop-client/src/components/reports/disabledList.ts (2)

5-6: LGTM: Internationalization applied to intervalOptions.

The changes consistently apply the t function to all string literals in the intervalOptions array, covering both description and defaultRange fields. This is a good step towards internationalization.

Consider extracting these strings into a separate constants file or using a key-based approach for better maintainability. For example:

import { INTERVAL_KEYS } from './constants';

const intervalOptions = [
  {
    description: t(INTERVAL_KEYS.DAILY),
    defaultRange: t(INTERVAL_KEYS.THIS_MONTH),
  },
  // ... other options
];

This approach can help centralize all translatable strings and make it easier to manage them as the application grows.

Also applies to: 9-10, 13-14, 17-18


Line range hint 1-190: LGTM: Consistent internationalization changes.

The internationalization changes have been consistently applied to the relevant parts of the file. The overall structure and logic of the file remain intact, which is good.

For consistency, consider applying internationalization to other user-facing strings in the file, if any. This might include error messages or any other text that could potentially be displayed to the user.

Also, to ensure all translatable strings are properly handled, you might want to run a static analysis tool that can detect non-internationalized strings. This can help catch any missed opportunities for translation.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 3f85aed and 225df29.

📒 Files selected for processing (6)
  • packages/desktop-client/src/components/reports/DateRange.tsx (5 hunks)
  • packages/desktop-client/src/components/reports/ReportLegend.tsx (3 hunks)
  • packages/desktop-client/src/components/reports/ReportOptions.ts (11 hunks)
  • packages/desktop-client/src/components/reports/disabledList.ts (2 hunks)
  • packages/desktop-client/src/components/reports/getLiveRange.ts (2 hunks)
  • packages/desktop-client/src/components/reports/index.tsx (1 hunks)
🔇 Additional comments (19)
packages/desktop-client/src/components/reports/index.tsx (2)

1-1: LGTM: Import statement for localization added correctly.

The import of useTranslation from 'react-i18next' is appropriate for implementing localization in this component.


7-7: LGTM: Translation hook initialized correctly.

The useTranslation hook is properly used to obtain the translation function t. This follows best practices for implementing localization in React components.

packages/desktop-client/src/components/reports/ReportLegend.tsx (4)

2-2: LGTM: Correct import for localization.

The import of useTranslation from 'react-i18next' is correctly added and is necessary for the localization changes in this component.


18-19: LGTM: Proper usage of useTranslation hook.

The useTranslation hook is correctly implemented, destructuring the t function for use in translations within the component.


Line range hint 1-54: Summary: Localization implemented correctly, with a minor concern.

The changes in this file successfully introduce localization using react-i18next, which aligns with the PR objective. The implementation is correct, but there's a potential logic issue in the comparison of 'groupBy' with the translated 'Interval' string. This should be verified and possibly adjusted to ensure correct functionality across different languages.

Overall, good progress on internationalization!


38-40: Approve translation, but verify comparison logic.

The use of t('Interval') for translation is correct. However, there's a potential logic issue:

  1. The comparison groupBy === t('Interval') might not work as expected if 'groupBy' is not translated elsewhere.
  2. This could lead to the condition always being false, defaulting to displaying the 'groupBy' value instead of the interval.

To verify this, please run the following script:

If 'groupBy' is not translated elsewhere, consider updating the logic to:

{groupBy.toLowerCase() === 'interval'
  ? ReportOptions.intervalMap.get(interval)
  : groupBy}

This would make the comparison case-insensitive and independent of translation.

packages/desktop-client/src/components/reports/getLiveRange.ts (2)

1-1: LGTM: Import statement for translation function.

The import of the t function from 'i18next' is correctly placed and necessary for the translation functionality added to the file.


Line range hint 1-58: Verify consistent translation approach across the codebase.

The changes made to this file are a good start for localization. However, as this PR is marked as WIP, it's important to ensure that a consistent translation approach is applied across all files mentioned in the PR objectives.

To check for consistency and identify other potential translation opportunities, you can run the following script:

This script will help identify potential hardcoded strings that might need translation and show existing uses of the t function in the files mentioned in the PR objectives.

✅ Verification successful

Translation Approach Verified

All relevant strings in the specified files are consistently using the t function for translations. No hardcoded strings requiring translation were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential translation opportunities in the files mentioned in the PR.

# List of files to check
files=(
  "packages/desktop-client/src/components/reports/DateRange.tsx"
  "packages/desktop-client/src/components/reports/ReportLegend.tsx"
  "packages/desktop-client/src/components/reports/ReportOptions.ts"
  "packages/desktop-client/src/components/reports/disabledList.ts"
  "packages/desktop-client/src/components/reports/getLiveRange.ts"
  "packages/desktop-client/src/components/reports/index.tsx"
)

# Check for hardcoded strings that might need translation
echo "Checking for potential hardcoded strings that might need translation:"
rg -n --type typescript --type tsx "'[A-Z][a-z]+'" "${files[@]}"
echo

# Check for existing uses of the t function
echo "Checking for existing uses of the t function:"
rg -n --type typescript --type tsx "t\(['\"]" "${files[@]}"

Length of output: 1574


Script:

#!/bin/bash
# Description: Check for potential translation opportunities in the files mentioned in the PR using file extensions.

# List of files to check
files=(
  "packages/desktop-client/src/components/reports/DateRange.tsx"
  "packages/desktop-client/src/components/reports/ReportLegend.tsx"
  "packages/desktop-client/src/components/reports/ReportOptions.ts"
  "packages/desktop-client/src/components/reports/disabledList.ts"
  "packages/desktop-client/src/components/reports/getLiveRange.ts"
  "packages/desktop-client/src/components/reports/index.tsx"
)

# Check for hardcoded strings that might need translation
echo "Checking for potential hardcoded strings that might need translation:"
rg -n -g "*.ts" -g "*.tsx" "'[A-Z][a-z]+'" "${files[@]}"
echo

# Check for existing uses of the t function
echo "Checking for existing uses of the t function:"
rg -n -g "*.ts" -g "*.tsx" "t\(['\"]" "${files[@]}"

Length of output: 16746

packages/desktop-client/src/components/reports/DateRange.tsx (5)

2-2: LGTM: Correct import for internationalization.

The import of useTranslation and Trans from 'react-i18next' is correctly added, which aligns with the PR objective of preparing the file for translation.


30-31: LGTM: Proper use of useTranslation hook.

The useTranslation hook is correctly implemented to obtain the t function for translations. This is a necessary step for internationalizing the component.


40-40: LGTM: Appropriate use of Trans component for error message.

The Trans component is correctly used to wrap the error message, making it translatable. This approach allows for more complex translations if needed in the future.


49-52: LGTM: Effective use of Trans component for complex string.

The Trans component is appropriately used here to handle a more complex string with interpolation. This approach correctly allows for translation of sentences with dynamic content.


Line range hint 1-83: Overall, excellent preparation for internationalization.

The changes made to this file effectively prepare it for translation, aligning well with the PR objective. The implementation of react-i18next is correct and follows best practices. The use of both Trans components for complex strings and the t function for simpler phrases is appropriate.

There's a minor suggestion for improvement regarding the handling of word order for different languages, but overall, this is a solid foundation for internationalizing the DateRange component.

Great job on taking this important step towards making the application more accessible to a global audience!

packages/desktop-client/src/components/reports/disabledList.ts (5)

1-1: LGTM: Import statement for internationalization.

The import of the t function from 'i18next' is correctly placed at the top of the file, setting up the internationalization capability for the rest of the code.


24-24: LGTM: Internationalization applied to currentIntervalOptions.

The changes correctly apply the t function to all description fields in the currentIntervalOptions array. The disableInclude property is appropriately left unchanged as it's a boolean value.

Also applies to: 28-28, 32-32, 36-36, 40-40


92-92: LGTM: Internationalization applied to timeGraphOptions.

The changes correctly apply the t function to most string literals in the timeGraphOptions array. This is consistent with the changes made in totalGraphOptions.

As mentioned in the previous comment, please clarify if strings like 'TableGraph', 'StackedBarGraph', etc., should remain untranslated.

Also applies to: 93-93, 94-94, 100-100, 101-101, 103-103, 107-107, 108-108, 110-110


Line range hint 1-190: Overall assessment: Good progress on internationalization.

This review has covered the changes made to disabledList.ts for internationalization. The modifications align well with the PR objectives of marking files for translation. Here's a summary of the key points:

  1. The t function from i18next is correctly imported and used throughout the file.
  2. Internationalization has been consistently applied to most user-facing strings in the various option arrays.
  3. Some strings (like graph types) were left untranslated, which may or may not be intentional.
  4. The overall structure and logic of the file remain intact.

Suggestions for improvement:

  1. Clarify whether certain strings (like 'TableGraph') should be translated.
  2. Consider extracting translatable strings into a separate constants file for better maintainability.
  3. Ensure all user-facing strings in the file are internationalized, including any that might be in unchanged sections.
  4. Run a static analysis tool to catch any non-internationalized strings.

These changes represent a solid step towards making the application more accessible to users who speak different languages. Great work on this internationalization effort!


58-58: LGTM with a question: Internationalization applied to totalGraphOptions.

The changes correctly apply the t function to most string literals in the totalGraphOptions array. However, some strings like 'TableGraph', 'BarGraph', etc., are not wrapped with t.

Could you clarify if strings like 'TableGraph', 'BarGraph', etc., are intentionally left untranslated? If they should be translated, consider wrapping them with the t function as well.

Also applies to: 60-60, 67-67, 69-69, 73-73, 74-74, 76-76, 82-82, 84-84

packages/desktop-client/src/components/reports/ReportOptions.ts (1)

1-1: Verify the import source of the t function.

Currently, t is imported from 'i18next'. Depending on your project's configuration, you might need to import t from 'react-i18next' to ensure proper functionality within React components.

Check if the import should be adjusted:

- import { t } from 'i18next';
+ import { useTranslation } from 'react-i18next';

const { t } = useTranslation();

Please confirm if this change aligns with your project's localization setup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant