Skip to content

[plugin][smartling]: ENG-12315 Smartling custom component list field#4555

Open
anaghav2023 wants to merge 4 commits into
BuilderIO:mainfrom
anaghav2023:ENG-12315-smartling-custom-component-list-field
Open

[plugin][smartling]: ENG-12315 Smartling custom component list field#4555
anaghav2023 wants to merge 4 commits into
BuilderIO:mainfrom
anaghav2023:ENG-12315-smartling-custom-component-list-field

Conversation

@anaghav2023

@anaghav2023 anaghav2023 commented May 7, 2026

Copy link
Copy Markdown
Contributor

Description

Currently, if we have fields of type 'list' in a custom component, then they don't get translated in smartling. This PR fixes the issue.

Issue:https://www.loom.com/share/30f2aa1ca4e840539a7bac796b79bd85
Fix: https://www.loom.com/share/422f8147f69d46e4bc7b939b5bcb85df


Note

Medium Risk
Medium risk because it changes how translation keys are extracted and applied for localized custom component inputs, including reconstructing nested list/object values from leaf paths; mistakes could lead to missing or misapplied translations.

Overview
Fixes Smartling translations for custom component localized inputs whose values are lists/objects (not just strings).

getTranslateableFields now flattens nested structures into per-leaf translation keys via extractStringLeaves, and applyTranslation can reconstruct the locale value by stitching translated leaf paths back into the Default structure; string inputs keep the prior direct behavior.

Bumps versions (@builder.io/utils to 1.1.30-0, Smartling plugin to 0.1.1-0) and updates the Smartling plugin to depend on the new utils prerelease.

Reviewed by Cursor Bugbot for commit 6b2c0f2. Bugbot is set up for automated code reviews on this repo. Configure here.

@anaghav2023 anaghav2023 requested review from a team and midhunadarvin and removed request for a team May 7, 2026 13:36
@changeset-bot

changeset-bot Bot commented May 7, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 6b2c0f2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@nx-cloud

nx-cloud Bot commented May 7, 2026

Copy link
Copy Markdown

View your CI Pipeline Execution ↗ for commit 6b2c0f2

Command Status Duration Result
nx test @e2e/qwik-city ✅ Succeeded 7m 51s View ↗
nx test @e2e/nextjs-sdk-next-app ✅ Succeeded 7m 3s View ↗
nx test @e2e/angular-17 ✅ Succeeded 6m 30s View ↗
nx test @e2e/nuxt ✅ Succeeded 6m 4s View ↗
nx test @e2e/hydrogen ✅ Succeeded 5m 30s View ↗
nx test @e2e/react-sdk-next-pages ✅ Succeeded 4m 54s View ↗
nx test @e2e/react-sdk-next-14-app ✅ Succeeded 5m 5s View ↗
nx test @e2e/angular-19-ssr ✅ Succeeded 5m 2s View ↗
Additional runs (38) ✅ Succeeded ... View ↗

☁️ Nx Cloud last updated this comment at 2026-05-08 04:37:38 UTC

@nx-cloud

nx-cloud Bot commented May 7, 2026

Copy link
Copy Markdown

🤖 Nx Cloud AI Fix Eligible

An automatically generated fix could have helped fix failing tasks for this run, but Self-healing CI is disabled for this workspace. Visit workspace settings to enable it and get automatic fixes in future runs.

To disable these notifications, a workspace admin can disable them in workspace settings.


View your CI Pipeline Execution ↗ for commit 07fdf6b

Command Status Duration Result
nx test @snippet/react ❌ Failed 3m 38s View ↗
nx test @e2e/angular-17 ✅ Succeeded 12m 7s View ↗
nx test @e2e/angular-19-ssr ✅ Succeeded 8m 53s View ↗
nx test @e2e/qwik-city ✅ Succeeded 8m 2s View ↗
nx test @e2e/remix ✅ Succeeded 8m 1s View ↗
nx test @e2e/solid-start ✅ Succeeded 8m 2s View ↗
nx test @e2e/vue ✅ Succeeded 6m 53s View ↗
nx test @e2e/nextjs-sdk-next-app ✅ Succeeded 7m 1s View ↗
Additional runs (38) ✅ Succeeded ... View ↗

☁️ Nx Cloud last updated this comment at 2026-05-07 13:52:07 UTC

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 07fdf6b. Configure here.

const localeValue = JSON.parse(JSON.stringify(inputValue?.Default ?? []));
subEntries.forEach(([k, entry]) => {
const subPath = k.slice(exactKey.length);
set(localeValue, subPath, unescapeStringOrObject(entry.value));

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Leading dot in subPath corrupts object translation placement

Medium Severity

When extractStringLeaves processes object properties, it builds paths like basePath.key. During reconstruction, subPath = k.slice(exactKey.length) produces a string starting with . (e.g., .key1). Lodash's set interprets a leading dot as path ['', 'key1'], so it creates localeValue['']['key1'] instead of localeValue['key1']. This silently places translated values under a spurious empty-string key, corrupting the output for object-type LocalizedValues in custom components. Array-type values (paths starting with [) are unaffected.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 07fdf6b. Configure here.

if (typeof value === 'string') {
results[path] = { value, instructions };
} else if (value?.['@type'] === localizedType) {
extractStringLeaves(value.Default, path, results, instructions);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Nested LocalizedValues always use Default, ignoring source locale

Low Severity

extractStringLeaves doesn't accept a sourceLocaleId parameter. When it encounters a nested LocalizedValue inside a list or object, it always extracts value.Default (line 106) instead of preferring value[sourceLocaleId]. This is inconsistent with recordValue (used for Symbols), which correctly checks sourceLocaleId first. If nested LocalizedValues have different text for the source locale vs Default, the wrong source text gets sent for translation.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 07fdf6b. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants