apps/web/app/[locale]/dashboard/app-url/components/productivity-employee/ProductivityEmployeeTable.tsx (1)

13-19: 🛠️ Refactor suggestion

Replace hardcoded strings with translation keys.

The TABLE_HEADERS constant uses hardcoded English strings. For consistency with other components, these should use translation keys.

-const TABLE_HEADERS = [
-  'Date',
-  'Project',
-  'Application',
-  'Time Spent',
-  'Percent used'
-] as const;
+const TABLE_HEADERS = [
+  t('common.DATE'),
+  t('common.PROJECT'),
+  t('common.APPLICATION'),
+  t('common.TIME_SPENT'),
+  t('common.PERCENT_USED')
+] as const;

apps/web/app/[locale]/dashboard/app-url/components/productivity-project/states.tsx (2)

56-61: Consider using the current locale for date formatting.

The date is being formatted using a hardcoded 'en-US' locale, which may not match the user's selected language.

-  const formattedDate = selectedDate ? new Date(selectedDate).toLocaleDateString('en-US', {
+  const formattedDate = selectedDate ? new Date(selectedDate).toLocaleDateString(undefined, {
     weekday: 'long',
     day: '2-digit',
     month: 'long',
     year: 'numeric'
   }) : '';

---

22-26: Consider using TypeScript const assertions for translation keys.

Using const assertions for translation keys can help catch typos and ensure type safety.

+const TRANSLATION_KEYS = {
+  DATE: 'common.DATE',
+  MEMBER: 'common.MEMBER',
+  APPLICATION: 'common.APPLICATION',
+  TIME_SPENT: 'common.TIME_SPENT',
+  PERCENT_USED: 'common.PERCENT_USED',
+  NO_ACTIVITY_DATA: 'common.NO_ACTIVITY_DATA',
+  SELECT_DIFFERENT_DATE: 'common.SELECT_DIFFERENT_DATE',
+} as const;

-<TableHead className="font-semibold">{t('common.DATE')}</TableHead>
+<TableHead className="font-semibold">{t(TRANSLATION_KEYS.DATE)}</TableHead>

Also applies to: 66-66, 70-70

apps/web/app/[locale]/dashboard/app-url/components/productivity-project/index.tsx (1)

43-47: Consider extracting shared translation keys.

The translation keys are duplicated between this component and the LoadingSkeleton component. Consider extracting them to a shared constants file.

Create a new file translationKeys.ts:

export const PRODUCTIVITY_TRANSLATION_KEYS = {
  DATE: 'common.DATE',
  MEMBER: 'common.MEMBER',
  APPLICATION: 'common.APPLICATION',
  TIME_SPENT: 'common.TIME_SPENT',
  PERCENT_USED: 'common.PERCENT_USED',
  NO_ACTIVITY_DATA: 'common.NO_ACTIVITY_DATA',
  SELECT_DIFFERENT_DATE: 'common.SELECT_DIFFERENT_DATE',
} as const;

apps/web/app/[locale]/dashboard/app-url/components/productivity-employee/ProductivityEmployeeTable.tsx (1)

31-39: Use consistent locale for date formatting.

The date formatting uses a hardcoded 'en-US' locale in multiple places. This should respect the user's locale preference.

-  return date.toLocaleDateString('en-US', {
+  return date.toLocaleDateString(undefined, {
     weekday: 'long',
     day: '2-digit',
     month: 'long',
     year: 'numeric'
   });

Also applies to: 174-174

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

apps/web/app/[locale]/dashboard/app-url/components/productivity-project/types.ts (2)

57-60: Add clarifying documentation for new interface.

Although the interface is self-explanatory, a short doc comment explaining its usage in consumer code might help readers understand how it fits into the overall reporting workflow.

---

62-69: Unify the activity item type.

Handling a union of IActivityItem or IActivityItem[] tends to complicate type checks. If possible, consider always using an array for consistency or providing clear utilities to handle single vs. multiple items.

apps/web/app/[locale]/dashboard/app-url/components/productivity-project/utils.ts (2)

4-23: Validate fallback behavior for invalid durations.

Returning '00:00:00' and logging a warning may be acceptable, but consider:

1. Throwing or surfacing an explicit error in development.
2. Providing a user-facing indication that the time is invalid.

This ensures developers/users quickly understand when the data is incorrect.

---

25-113: Avoid using any casting and standardize data validation.

Forcing the cast using data as any can hide potential issues if data is not shaped as expected. A more robust solution is to narrow the type with explicit checks or use safer parsing techniques. Consider extracting validation logic into a helper or rewriting to ensure type safety without multiple logging statements.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro