Skip to content

Make highlighter controls translatable - #1261

Merged
SteveJonesDev merged 4 commits into
developfrom
codex/make-frontend-highlighter-elements-translatable
Nov 19, 2025
Merged

Make highlighter controls translatable#1261
SteveJonesDev merged 4 commits into
developfrom
codex/make-frontend-highlighter-elements-translatable

Conversation

@SteveJonesDev

@SteveJonesDev SteveJonesDev commented Oct 22, 2025

Copy link
Copy Markdown
Member

This pull request improves internationalization and accessibility for the frontend highlighter app by ensuring all user-facing text is properly localized using WordPress i18n functions. The changes replace hardcoded strings with calls to translation functions, making the interface fully translatable and more user-friendly for non-English users.

Internationalization and Localization Improvements:

  • Replaced all hardcoded English strings in tooltips, buttons, labels, and status messages with calls to the __, _n, and sprintf functions from @wordpress/i18n for proper localization throughout src/frontendHighlighterApp/index.js. [1] [2] [3] [4] [5] [6]

Accessibility and UI Enhancements:

  • Improved the summary text for detected issues (errors, warnings, ignored) to use pluralization and localization, ensuring correct grammar and translation in the summary panel.
  • Updated ARIA labels and other accessibility attributes to use localized strings, enhancing accessibility for screen reader users in different languages. [1] [2] [3]

These updates make the app more maintainable and accessible to a global audience.

https://linear.app/equalize-digital/issue/PRO-344/some-missing-translations-in-front-end-highlighter-and-open-issues

Fixes: https://linear.app/equalize-digital/issue/PRO-344/some-missing-translations-in-front-end-highlighter-and-open-issues

Summary by CodeRabbit

  • New Features
    • Added multi-language support to the Accessibility Checker application. All user-facing interface text, labels, buttons, and messages can now be displayed in different languages.

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @SteveJonesDev, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the internationalization capabilities of the frontend highlighter component. By making key UI elements like navigation buttons and documentation links translatable, and by refactoring the issue summary display to properly handle localized string formatting and pluralization, the changes ensure a more accessible and user-friendly experience for a global audience.

Highlights

  • Internationalization of Highlighter Controls: The 'Previous' and 'Next' navigation buttons within the highlighter panel have been made translatable using WordPress i18n functions.
  • Translatable Documentation Link: The 'Full Documentation' link text is now wrapped with i18n functions, allowing it to be translated into different languages.
  • Refactored Issue Summary Output: The logic for displaying the issue summary (e.g., 'X errors, Y warnings, and Z ignored issues detected') has been refactored to use sprintf with translatable strings, improving localization support for plural forms and sentence structure.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@coderabbitai

coderabbitai Bot commented Oct 22, 2025

Copy link
Copy Markdown
Contributor

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

The PR internationalizes front-end highlighter strings in src/frontendHighlighterApp/index.js, adding sprintf import and replacing hard-coded UI text (labels, aria-labels, status messages, summaries) with WordPress i18n helpers (__, _n, sprintf) and plural-aware assembly.

Changes

Cohort / File(s) Change Summary
Internationalization updates in Frontend Highlighter
src/frontendHighlighterApp/index.js
Added sprintf import from @wordpress/i18n. Replaced hard-coded UI strings (panel titles, buttons, tooltips, aria-labels, status messages, documentation link) with __(); used _n() and sprintf() for plural-aware fragments and interpolated labels (e.g., landmark, fix-button aria). Refactored showIssueCount to assemble localized, plural-aware summaries. No public API changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Potential focus areas:

  • verify showIssueCount pluralization and ordering of fragments
  • ensure sprintf placeholders match translation strings
  • confirm correct text domain (accessibility-checker) on all calls

Possibly related PRs

Suggested reviewers

  • pattonwebz

Poem

🐇 I nibble text and stitch it neat,

Strings once plain now sound complete.
Buttons, hints, and counts made bright,
Landmarks named in every light,
Hopping on — translations take flight.

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Make highlighter controls translatable' directly summarizes the main change: replacing hard-coded strings with i18n functions for localization throughout the frontend highlighter.
Linked Issues check ✅ Passed The PR comprehensively addresses PRO-344 by wrapping all user-facing highlighter UI strings (buttons, labels, tooltips, ARIA attributes, status messages) in i18n functions (__,_n,sprintf) to enable translation pickup.
Out of Scope Changes check ✅ Passed All changes are directly scoped to the localization objective: only src/frontendHighlighterApp/index.js was modified with i18n function additions and no unrelated modifications.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch codex/make-frontend-highlighter-elements-translatable

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 6caf025 and 0a9408a.

📒 Files selected for processing (1)
  • src/frontendHighlighterApp/index.js (6 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.js

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

All user-facing JavaScript strings must use wp.i18n for translation

Files:

  • src/frontendHighlighterApp/index.js
src/**/*

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Store source frontend assets (JS/CSS) in /src; do not commit edits directly to built files

Files:

  • src/frontendHighlighterApp/index.js
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
Repo: equalizedigital/accessibility-checker PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-29T11:15:35.151Z
Learning: Applies to **/*.php : All user-facing text in PHP must be translatable using the accessibility-checker text domain
Learnt from: CR
Repo: equalizedigital/accessibility-checker PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-29T11:15:35.151Z
Learning: Applies to **/*.js : All user-facing JavaScript strings must use wp.i18n for translation
📚 Learning: 2025-08-29T11:15:35.151Z
Learnt from: CR
Repo: equalizedigital/accessibility-checker PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-29T11:15:35.151Z
Learning: Applies to **/*.js : All user-facing JavaScript strings must use wp.i18n for translation

Applied to files:

  • src/frontendHighlighterApp/index.js
📚 Learning: 2025-08-29T11:15:35.151Z
Learnt from: CR
Repo: equalizedigital/accessibility-checker PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-29T11:15:35.151Z
Learning: Applies to **/*.php : All user-facing text in PHP must be translatable using the accessibility-checker text domain

Applied to files:

  • src/frontendHighlighterApp/index.js
📚 Learning: 2025-08-29T11:15:35.151Z
Learnt from: CR
Repo: equalizedigital/accessibility-checker PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-29T11:15:35.151Z
Learning: Prefer native HTML elements over custom widgets unless necessary; avoid overlays that mask issues

Applied to files:

  • src/frontendHighlighterApp/index.js
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: Integration Test: PHP 8.1 | WP latest (+ ms)
  • GitHub Check: Integration Test: PHP 8.2 | WP latest (+ ms)
  • GitHub Check: Integration Test: PHP 8.1 | WP 6.2
🔇 Additional comments (2)
src/frontendHighlighterApp/index.js (2)

7-7: LGTM: sprintf import added correctly.

The addition of sprintf to the i18n imports is necessary and correct for interpolating dynamic values into translated strings throughout the file.


7-7: Excellent i18n implementation throughout the file.

All user-facing strings have been correctly wrapped with WordPress i18n functions:

  • Simple strings use __() with the correct text domain
  • Plurals use _n() with proper singular/plural forms
  • Dynamic values are interpolated using sprintf()
  • ARIA labels and accessibility attributes are translatable

This implementation successfully meets the PR objective of making the frontend highlighter fully translatable. Based on learnings.

Also applies to: 289-289, 399-403, 408-410, 416-418, 421-422, 427-427, 524-524, 530-530, 534-534, 600-600, 696-696, 710-710, 715-715, 719-719, 722-722, 819-819, 840-840, 891-891, 1026-1026, 1195-1195, 1203-1203, 1211-1211, 1216-1216, 1222-1222, 1247-1247, 1252-1252, 1279-1279, 1291-1291, 1298-1298, 1317-1317, 1321-1321, 1326-1326, 1331-1331

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


Comment @coderabbitai help to get the list of available commands and usage tips.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Code Review

This pull request successfully adds internationalization support for several UI elements in the highlighter, including navigation buttons and the documentation link. It also refactors the issue summary generation to use translatable strings.

My review identifies a critical logic issue in the new summary generation. The implementation incorrectly includes issue types with a count of zero in the summary message, leading to confusing output for the user. I've provided a code suggestion to fix this by conditionally building the summary parts.

Comment thread src/frontendHighlighterApp/index.js Outdated
Comment on lines 952 to 968
const summaryParts = [
sprintf( _n( '%1$s error', '%1$s errors', errorCount, 'accessibility-checker' ), errorCount ),
sprintf( _n( '%1$s warning', '%1$s warnings', warningCount, 'accessibility-checker' ), warningCount ),
sprintf( _n( '%1$s ignored issue', '%1$s ignored issues', ignoredCount, 'accessibility-checker' ), ignoredCount ),
];

switch ( summaryParts.length ) {
case 1:
textContent = sprintf( __( '%1$s detected.', 'accessibility-checker' ), summaryParts[ 0 ] );
break;
case 2:
textContent = sprintf( __( '%1$s and %2$s detected.', 'accessibility-checker' ), summaryParts[ 0 ], summaryParts[ 1 ] );
break;
default:
textContent = sprintf( __( '%1$s, %2$s, and %3$s detected.', 'accessibility-checker' ), summaryParts[ 0 ], summaryParts[ 1 ], summaryParts[ 2 ] );
break;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

critical

The current logic for building summaryParts is flawed. The array is unconditionally populated with three items, regardless of whether their counts are zero. This causes the switch statement to always fall into the default case, producing a message that includes zero-count items, like "1 error, 0 warnings, and 0 ignored issues detected."

To fix this, summaryParts should be populated conditionally, only adding parts where the count is greater than zero. This ensures the switch statement correctly formats the summary string based on the actual number of issue types found.

			const summaryParts = [];
			if ( errorCount > 0 ) {
				summaryParts.push( sprintf( _n( '%1$s error', '%1$s errors', errorCount, 'accessibility-checker' ), errorCount ) );
			}
			if ( warningCount > 0 ) {
				summaryParts.push( sprintf( _n( '%1$s warning', '%1$s warnings', warningCount, 'accessibility-checker' ), warningCount ) );
			}
			if ( ignoredCount > 0 ) {
				summaryParts.push( sprintf( _n( '%1$s ignored issue', '%1$s ignored issues', ignoredCount, 'accessibility-checker' ), ignoredCount ) );
			}

			switch ( summaryParts.length ) {
				case 1:
					textContent = sprintf( __( '%1$s detected.', 'accessibility-checker' ), summaryParts[ 0 ] );
					break;
				case 2:
					textContent = sprintf( __( '%1$s and %2$s detected.', 'accessibility-checker' ), summaryParts[ 0 ], summaryParts[ 1 ] );
					break;
				case 3:
					textContent = sprintf( __( '%1$s, %2$s, and %3$s detected.', 'accessibility-checker' ), summaryParts[ 0 ], summaryParts[ 1 ], summaryParts[ 2 ] );
					break;
			}

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Nitpick comments (1)
src/frontendHighlighterApp/index.js (1)

289-289: Consider internationalizing remaining user-facing strings.

Several other user-facing strings throughout the file are not yet using wp.i18n for translation:

  • Line 289: aria-label with template literal
  • Lines 408, 410, 416, 417, 418: Panel UI labels ("Accessibility Checker Tools", "Close", "Accessibility Checker", "Loading...")
  • Lines 524, 530, 534: Status messages ("The element is not visible...", etc.)
  • Line 710: "Fix Issue" button text
  • Line 1032: "Landmark:" label

While these are outside the current PR scope, the coding guidelines require all user-facing JavaScript strings to use wp.i18n for translation.

As per coding guidelines.

Also applies to: 408-408, 410-410, 416-416, 417-417, 418-418, 524-524, 530-530, 534-534, 710-710, 1032-1032

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 5cd4433 and 4215cb4.

📒 Files selected for processing (1)
  • src/frontendHighlighterApp/index.js (4 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.js

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

All user-facing JavaScript strings must use wp.i18n for translation

Files:

  • src/frontendHighlighterApp/index.js
src/**/*

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Store source frontend assets (JS/CSS) in /src; do not commit edits directly to built files

Files:

  • src/frontendHighlighterApp/index.js
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
PR: equalizedigital/accessibility-checker#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-29T11:15:35.151Z
Learning: Applies to **/*.js : All user-facing JavaScript strings must use wp.i18n for translation
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: Integration Test: PHP 8.2 | WP latest (+ ms)
  • GitHub Check: Integration Test: PHP 8.1 | WP latest (+ ms)
  • GitHub Check: Integration Test: PHP 8.1 | WP 6.2
  • GitHub Check: Integration Test: PHP 8.1 | WP latest (+ ms)
  • GitHub Check: Integration Test: PHP 8.2 | WP latest (+ ms)
🔇 Additional comments (3)
src/frontendHighlighterApp/index.js (3)

7-7: LGTM! Import statement is correct.

The addition of sprintf to the existing @wordpress/i18n imports is necessary for formatting the localized issue count messages.


421-422: LGTM! Button labels properly internationalized.

The Previous and Next button labels are correctly wrapped with the __() function using the proper text domain.


716-716: LGTM! Documentation link properly internationalized.

The "Full Documentation" text is correctly wrapped with the __() function.

Comment thread src/frontendHighlighterApp/index.js Outdated

@pattonwebz pattonwebz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

The translations here seem good to me. It's much nicer seeing them using sprintf for positional replacements instead of just inline string literals.

I did have 2 comments about some logic changes around counting error, warning, and ignore, and about how readable the switch statement added for those changes is.

Comment thread src/frontendHighlighterApp/index.js Outdated
// Remove the trailing comma and add "detected."
textContent = textContent.slice( 0, -2 ) + ' ' + __( 'detected.', 'accessibility-checker' );

if ( ignoredCount > 0 ) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This here and the error and warning count checks were changed from greater than or equal to 0 to be just greater than 0. Is that intentional so that the messages don't output if there's 0 items?

Comment thread src/frontendHighlighterApp/index.js Outdated
Comment on lines +966 to +975
switch ( summaryParts.length ) {
case 1:
textContent = sprintf( __( '%1$s detected.', 'accessibility-checker' ), summaryParts[ 0 ] );
break;
case 2:
textContent = sprintf( __( '%1$s and %2$s detected.', 'accessibility-checker' ), summaryParts[ 0 ], summaryParts[ 1 ] );
break;
default:
textContent = sprintf( __( '%1$s, %2$s, and %3$s detected.', 'accessibility-checker' ), summaryParts[ 0 ], summaryParts[ 1 ], summaryParts[ 2 ] );
break;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

For easier parsing, I would prefer that there be a case covering 3 here. It could just defer to the default but it wasn't immediately clear to me why there wasn't a 3 and the default assumed it had 3 length.

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.

2 participants