Added the lang select option in 7 languages using lingo.dev added a f…#56
Added the lang select option in 7 languages using lingo.dev added a f…#56naheel0 merged 2 commits intoBeyteFlow:mainfrom
Conversation
…ile locals where all the translated data from database.json is present you can select the language by node filename --lang hi(hindi for example )if you want to update databse in future in the scripts file there is a script which will convert and put the translated data in there respected lang file in the env file you just have to setup the LINGO_API_KEY which you can get for free and they provide 10000 tokens per month for free
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughAdded i18n support: CLI Changes
Sequence DiagramsequenceDiagram
participant User
participant CLI as bin/index.js
participant Matcher as lib/matcher.js
participant Locales as locales/*.json
User->>CLI: invoke run/analyze with --lang (or default "en")
CLI->>CLI: parse options.lang
CLI->>Matcher: findError(input, lang)
Matcher->>Matcher: match entries from database
Matcher->>Locales: loadLocale(lang) (sync read)
Locales-->>Matcher: return locale object
Matcher->>Matcher: translateEntry(match, locale) -> override explanation/why/fixes
Matcher-->>CLI: return matches (translated)
CLI-->>User: display translated results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
locales/ja.json (1)
1-199: Add CI key-parity validation for locale JSONs.This file is large and manually maintained; missing/extra keys can silently fall back to English and ship unnoticed. Add a test that diffs keys against
locales/en.jsonfor all locales.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@locales/ja.json` around lines 1 - 199, Add a CI test that enforces key parity between the English reference and all other locale JSONs by loading en.json as the canonical key set and diffing each locale (e.g., ja.json) to fail on any missing or extra keys; implement this as a test named "locale key parity" (or a script function like validateLocaleKeys) that reads JSON, recursively extracts flattened key paths, compares sets, and throws/asserts with a clear diff so CI fails when keys diverge. Ensure the test runs in the existing test suite/CI pipeline and covers nested keys (flattened dot-notation), ignoring only allowed exceptions if needed, and reference the created test name "locale key parity" / function "validateLocaleKeys" when committing so reviewers can find it.lib/matcher.js (1)
9-14: Consider logging when falling back to English locale.When the requested locale file fails to load (malformed JSON or missing), the fallback silently loads
en.json. This could hide configuration issues. Consider adding a warning or ensuring the fallback file exists.💡 Optional improvement
try { return JSON.parse(fs.readFileSync(filepath,"utf8")) } catch (error) { + if (lang !== "en") { + console.warn(`Locale '${lang}' not found, falling back to English.`); + } return JSON.parse(fs.readFileSync(fallback,"utf8")) - }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/matcher.js` around lines 9 - 14, The catch block that silently falls back to reading fallback ("en.json") should log a warning with the original error and the failed filepath so broken/missing locale files are visible; in lib/matcher.js modify the catch to call the logger (or console.warn) with a message including filepath and error, then attempt to read fallback, and additionally check that reading/parsing fallback succeeded (and log or throw an error if fallback is missing/invalid). Use the existing variables error, filepath, fallback and fs.readFileSync to implement these checks and messages.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@bin/index.js`:
- Around line 125-128: Remove the duplicate/broken command registration: delete
the .argument("<error>", ...) and the stray .action((error, options) => { const
result = findError(error, options.lang)}) block (it conflicts with the existing
<errorString> argument and other .action handler, contains unmatched braces, and
assigns an unused result). If the intent was to call findError, move that call
into the single existing .action handler for the command (use the existing
argument name <errorString> and options.lang) so there is only one well-formed
.action and no duplicate arguments.
In `@lib/matcher.js`:
- Line 31: The default language parameter for function findError is incorrect:
change the default value in the findError function signature from "eng" to "en"
so it matches other defaults (e.g., loadLocale and CLI). Update the function
declaration function findError(input, lang = "eng") to use lang = "en" and run
tests/lint to ensure no other references rely on "eng".
In `@package.json`:
- Line 37: Update the "translate" npm script to invoke lingo.dev reproducibly by
using the npx + `@latest` specifier instead of relying on a global binary; modify
the "translate" entry in package.json (script key "translate") to call npx
lingo.dev@latest run so CI and fresh environments run the exact tool without a
global install.
In `@scripts/extractlocals.js`:
- Line 28: The console.log message in scripts/extractlocals.js incorrectly says
"local/en.json"; update the string in the console.log call (the console.log(...)
statement) to refer to "locales/en.json" so the printed path matches the file
the script writes.
In `@test/test-lang.js`:
- Around line 1-15: Rename the file to test/test-lang.test.js and convert the
procedural script into proper unit tests that assert expected behavior: iterate
over the languages array and for each language call findError(testError, lang)
and use the Node test framework (import from 'node:test' or a test runner in
use) with assertions (e.g., strictEqual/ok) to verify result.matches contains
expected entries and that match.explanation, match.why, and match.fixes meet
expectations; update the top-level requires (keep require('../lib/matcher') and
function findError) and replace console.log lines with assertions so the test
runner executes and fails on regressions.
---
Nitpick comments:
In `@lib/matcher.js`:
- Around line 9-14: The catch block that silently falls back to reading fallback
("en.json") should log a warning with the original error and the failed filepath
so broken/missing locale files are visible; in lib/matcher.js modify the catch
to call the logger (or console.warn) with a message including filepath and
error, then attempt to read fallback, and additionally check that
reading/parsing fallback succeeded (and log or throw an error if fallback is
missing/invalid). Use the existing variables error, filepath, fallback and
fs.readFileSync to implement these checks and messages.
In `@locales/ja.json`:
- Around line 1-199: Add a CI test that enforces key parity between the English
reference and all other locale JSONs by loading en.json as the canonical key set
and diffing each locale (e.g., ja.json) to fail on any missing or extra keys;
implement this as a test named "locale key parity" (or a script function like
validateLocaleKeys) that reads JSON, recursively extracts flattened key paths,
compares sets, and throws/asserts with a clear diff so CI fails when keys
diverge. Ensure the test runs in the existing test suite/CI pipeline and covers
nested keys (flattened dot-notation), ignoring only allowed exceptions if
needed, and reference the created test name "locale key parity" / function
"validateLocaleKeys" when committing so reviewers can find it.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6015963b-eb2c-45ec-886e-a3fc514eadbf
⛔ Files ignored due to path filters (2)
i18n.lockis excluded by!**/*.lockpackage-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (14)
bin/index.jsi18n.jsonlib/matcher.jslocales/de.jsonlocales/en.jsonlocales/es.jsonlocales/fr.jsonlocales/hi.jsonlocales/ja.jsonlocales/pt.jsonlocales/zh.jsonpackage.jsonscripts/extractlocals.jstest/test-lang.js
| const { findError } = require('../lib/matcher') | ||
|
|
||
| const languages = ['en', 'hi', 'es', 'fr', 'de', 'zh', 'ja', 'pt'] | ||
| const testError = "Cannot read properties of undefined" | ||
|
|
||
| for (const lang of languages) { | ||
| console.log(`\n--- ${lang.toUpperCase()} ---`) | ||
| const result = findError(testError, lang) | ||
| if (result.matches.length > 0) { | ||
| const match = result.matches[0] | ||
| console.log('explanation:', match.explanation) | ||
| console.log('why: ', match.why) | ||
| console.log('fixes: ', match.fixes) | ||
| } | ||
| } No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Test command:"
jq -r '.scripts.test' package.json
echo -e "\nFiles currently matching *.test.js under test/:"
fd -t f '.*\.test\.js$' test || true
echo -e "\nDoes test/test-lang.js match test/**/*.test.js ?"
python - <<'PY'
import fnmatch
print(fnmatch.fnmatch("test/test-lang.js", "test/**/*.test.js"))
PY
echo -e "\nAssertion-like usage in test/test-lang.js:"
rg -n "assert|expect\\(|t\\." test/test-lang.js || trueRepository: BeyteFlow/errlens
Length of output: 329
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Current test/test-lang.js content ==="
cat -n test/test-lang.js
echo -e "\n=== All files in test/ directory ==="
find test -type f | sort
echo -e "\n=== Checking if test/test-lang.test.js exists ==="
test -f test/test-lang.test.js && echo "EXISTS" || echo "DOES NOT EXIST"
echo -e "\n=== Verifying Node.js test framework usage in existing test files ==="
fd -t f '\.test\.js$' . 2>/dev/null | head -5 || echo "No .test.js files found"Repository: BeyteFlow/errlens
Length of output: 913
Rename to test/test-lang.test.js and convert to proper assertions.
The file won't be executed by the test runner (node --test test/**/*.test.js) due to its .js filename, and contains only console logging with no assertions—making it non-functional as a test.
Suggested test conversion
+const test = require('node:test')
+const assert = require('node:assert/strict')
const { findError } = require('../lib/matcher')
const languages = ['en', 'hi', 'es', 'fr', 'de', 'zh', 'ja', 'pt']
const testError = "Cannot read properties of undefined"
-for (const lang of languages) {
- console.log(`\n--- ${lang.toUpperCase()} ---`)
- const result = findError(testError, lang)
- if (result.matches.length > 0) {
- const match = result.matches[0]
- console.log('explanation:', match.explanation)
- console.log('why: ', match.why)
- console.log('fixes: ', match.fixes)
- }
-}
+for (const lang of languages) {
+ test(`findError returns translated match for ${lang}`, () => {
+ const result = findError(testError, lang)
+ assert.ok(result.matches.length > 0)
+ const match = result.matches[0]
+ assert.ok(typeof match.explanation === 'string' && match.explanation.length > 0)
+ assert.ok(typeof match.why === 'string' && match.why.length > 0)
+ assert.ok(Array.isArray(match.fixes) && match.fixes.length > 0)
+ })
+}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/test-lang.js` around lines 1 - 15, Rename the file to
test/test-lang.test.js and convert the procedural script into proper unit tests
that assert expected behavior: iterate over the languages array and for each
language call findError(testError, lang) and use the Node test framework (import
from 'node:test' or a test runner in use) with assertions (e.g., strictEqual/ok)
to verify result.matches contains expected entries and that match.explanation,
match.why, and match.fixes meet expectations; update the top-level requires
(keep require('../lib/matcher') and function findError) and replace console.log
lines with assertions so the test runner executes and fails on regressions.
…s in function findError the argument lang = eng changed to en 3)In pakage.json the translate : ling.dev run is removed can be implemented again by just adding it in the scripts 4) In the extractorlocal script spelling mistake fixed test-lang seplling fixed in the pakage.json
|
Changes |
|
Thanks for the PR! I’ll test the multilingual feature on this branch first, and once I confirm everything works as expected, I’ll go ahead and merge it. |
|
Hi @rahulgope45, I tested the branch and noticed that --lang was not working. I’ve fixed bin/index.js locally by removing the duplicate and wiring --lang correctly. Wonderful work on adding multilingual support — this is a great feature! I can push the fix to this PR so it’s testable and merge-ready. |
|
Thanks for the review I missed the wiring part in the index thanks for merging anyway |
…ile locals where all the translated data from database.json is present you can select the language by node filename --lang hi(hindi for example )if you want to update databse in future in the scripts file there is a script which will convert and put the translated data in there respected lang file in the env file you just have to setup the LINGO_API_KEY which you can get for free and they provide 10000 tokens per month for free
🚀 BΞYTΞFLʘW | Pull Request Protocol
PR Type: (feat)
Adds a
--lang <code>flag to both therunandanalyzecommands,allowing users to receive error explanations in their preferred language.
errlens run app.js --lang hi errlens analyze "Cannot read properties of undefined" --lang es📝 System Summary
Used Lingo.dev (I have used this so I trusted it )to translate your datase.json to 7 different language in future if you scale your database you can use the script in the script extractlocals.js which uses lingo.dev (Before running add env variable LINGO_API_KEY they provide 10000 free tokens so u won't face any issues ) test any file error by errlens run filename --lang hi(hindi for example) writen a test also verfing the work
🛠️ Technical Changes
`matcher.js
Three things were added on top of the original file:
loadLocale(lang) — reads the correct locales/.json file at runtime, falls back to en.json if the language doesn't exist
translateEntry(entry, locale) — swaps out explanation, why, and fixes on a single database entry with the translated versions from the locale file
findError() now accepts a lang parameter (default "en"), loads the locale once, and runs every match through translateEntry before returning
and in index.js
Two things changed:
--lang
option added to both run and analyze commands, with "en" as defaultoptions.lang is now passed into every findError() call so the language flows through to the output
`
......🧪 Quality Assurance (QA)
npm run buildexecuted without errors.🖼️ Visual Evidence
If this PR affects the UI, drop a screenshot or GIF below:
📡 Developer Authorization
Authorized by: @YourUsername
Timestamp: {{ started 23 at 3pm to 24 2:30am}}
Summary by CodeRabbit
New Features
option to CLI commands to request explanations in different languages (default: English)Tests
Chores