Skip to content

fix: i18n related hardcoded data issue

Bhaskar Battula requested to merge i18n-issue into develop

Overview

This MR fixes hardcoded strings in the codebase and ensures all user-facing text uses the i18n translation framework. It addresses test failures caused by missing translation keys.

What does this MR do and why?

  • Replaces hardcoded strings with proper i18n keys
  • Updates translation files with missing entries
  • Refactors components to use translation hooks (t('key'))
  • Updates unit tests to validate translated content

Motivation: Previous commits introduced hardcoded text, which broke tests and prevented proper localization. This MR restores i18n compliance and test stability.

Changes Made

  • Modified all affected UI components to remove hardcoded strings
  • Updated src/locales/*.json with new translation keys
  • Refactored unit tests to check translations instead of hardcoded values
  • Staged changes to CHANGELOG.md

Technical Details

  • Root cause: hardcoded strings bypassing i18n hooks
  • Fix: extract strings into i18n JSON files and reference via translation functions
  • Trade-offs: minor refactoring required for some nested components

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • 📝 Documentation update (CHANGELOG.md updated)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change
  • 🎨 UI/UX improvement
  • ♻️ Refactor
  • ⚡ Performance improvement
  • 🧪 Test update
  • 🔧 Configuration change
  • 🚨 Security fix

Related Issues / References

How to Set Up and Validate Locally

  1. Checkout this branch
  2. Install dependencies: 
    bun install>

How to Set Up and Validate Locally

Testing Done

Test Cases Covered:

Scenario Expected Result Status
All UI strings use i18n keys No hardcoded strings remain Pass
Tests validate translation rendering Tests pass with i18n keys Pass
Language switching works Text updates according to selected language Pass

Code Quality Checklist

Code Standards

  • Code follows project conventions (naming, structure, formatting)
  • No console.log() or debugger statements left in code
  • No unused imports, variables, or functions
  • No duplicate code and use of existing components for reusability
  • i18n check passed with no hardcoded strings in codebase for i18n support
  • TypeScript types are properly defined (no any unless justified)
  • ESLint and Prettier checks pass 
    bun run lint

React Best Practices

  • Components are properly split and single-responsibility
  • Hooks follow rules (no conditional hooks, proper dependencies)
  • State management is appropriate (local vs global state)
  • No unnecessary re-renders (memoization used where needed)
  • Event handlers are properly cleaned up

Component Patterns

  • shadcn/ui components used correctly
  • Tailwind classes follow utility-first approach
  • Responsive design considered (mobile-first if applicable)
  • Accessibility attributes included (aria-*, role, etc.)
  • Icons from lucide-react used consistently

API & Data Fetching

  • TanStack Query used for server state (if applicable)
  • Loading and error states handled
  • API types defined in src/types/api.ts
  • Axios interceptors handle auth tokens correctly
  • Use of Zod for data validations

Error Handling

  • Errors are caught and handled gracefully
  • User-friendly error messages displayed
  • Errors are being toasted properly
  • Network failures handled appropriately

Documentation

  • README.md updated (if setup steps changed)
  • .env.example updated (if new env vars added)
  • CHANGELOG.md updated (if applicable)
Edited by Bhaskar Battula

Merge request reports