-
[ ] API breaking change
The file previously exported a default language pack. That export was removed and only logging is re-exported now. Consumers that imported the language pack or translation utilities from this module will break unless the PR provides a compatibility re-export or all call sites were updated to the new package (@apache-superset/core). Verify all imports across the monorepo and extensions are updated, or add a proxy re-export to preserve backward compatibility.
-
[ ] Mixed core packages
The file now imports t from @apache-superset/core but still imports DTTM_ALIAS, QueryColumn, and QueryMode from @superset-ui/core. Mixing two core packages can produce duplicate runtime instances, inconsistent types, or diverging implementations of shared utilities. Confirm these symbols intentionally remain in @superset-ui/core and ensure both packages are compatible (same versions / singletons) to avoid subtle runtime or bundling issues.
-
[ ] ID / key safety
DOM id and React key are derived directly from val (including JSON.stringify(val) and tab-${val}). If val is an object, array, or contains characters not valid in an id, this can produce invalid/duplicate ids or unpredictable keys. Use a stable stringification or index-based fallback to generate safe ids/keys.
-
[ ] Translation substitution
The translated accessibility string uses a label value that can be a ReactNode (not necessarily a string). Passing a non-string as the translation placeholder can yield incorrect output (e.g. "[object Object]") or lose meaningful label text. Ensure the substituted value is converted/sanitized to a user-visible string before calling t.
-
[ ] Reset does not clear implicit singleton
If getInstance() is called before configure(), a Translator is created and assigned to singleton while isConfigured remains false. resetTranslation() only clears singleton when isConfigured is true, so the implicitly-created singleton will not be cleared. This can lead to stale state across tests or when trying to reconfigure the translator.
-
[ ] Missing runtime dependency risk
Moving t import to @apache-superset/core can cause runtime module resolution failures if the new package isn't added to this package's dependencies or isn't present at runtime. Ensure @apache-superset/core is a declared dependency (or peerDependency) and is bundled/published where this plugin runs.
-
[ ] Dependency change
The translation function t is now imported from @apache-superset/core. Verify that this package is added to the package.json (or the consuming package's dependencies) and that the monorepo build and bundler configuration are updated so the new package is available at runtime. Missing/incorrect dependency changes will cause runtime/module resolution failures.
-
[ ] i18n runtime compatibility
Ensure the t implementation exported from @apache-superset/core is API-compatible with prior usage (same signature and runtime behavior). Also confirm translations are loaded/initialized correctly in environments that consume this plugin (extensions, tests, storybooks).
-
[ ] I18n import change
The PR moves t and tn imports to @apache-superset/core/ui. Confirm that the new exports behave identically to the previous @superset-ui/core implementations (pluralization, interpolation, runtime side-effects). Also ensure there's no mixed usage elsewhere in the repo that would import translations from the old package, which could lead to inconsistent translations at runtime.
-
[ ] Inconsistent imports
The PR moves translation t to @apache-superset/core while validators (validateInteger, validateNonEmpty) remain imported from @superset-ui/core. This creates mixed core packages in the same module and can cause runtime/packaging inconsistencies if validators are also moved to the new core or re-exported differently. Verify the canonical source for shared utilities and align imports across the repo.
-
[ ] Export / resolution risk
Ensure t is actually exported from @apache-superset/core in the version used by the app and that moving it did not create circular dependency or runtime resolution issues. Also verify tree-shaking / bundle size implications and update any consumers that still import t from @superset-ui/core.
-
[ ] Swallowed errors during image fetch
The new logic catches fetch errors when checking the image, treats a 404 as "not ready", but silently swallows all other errors (no rethrow). That can cause non-404 failures to be treated as if the image was ready (or simply ignored), preventing proper retry/failure handling and logging. Ensure non-404 errors are propagated so retries/failure handling and logging behave as intended.
-
[ ] Module initialization side effects
The code calls getExtensionsRegistry() at module scope (top-level) which can run during module evaluation. This may trigger side effects too early (e.g., during server-side rendering, tests, or before runtime initialization). Consider delaying registry resolution to component render or using lazy initialization to avoid ordering issues.
-
[ ] Logging API shape
The code calls logging.error(error). Confirm that the logging export from @apache-superset/core exposes an error method with the expected signature. If the logging API changed during refactor, adapt the calls or wrap the new logger to preserve behavior.
-
[ ] Feature flag source
Ensure FeatureFlag and isFeatureEnabled are still meant to be imported from @superset-ui/core. If the "move translations to new core" refactor also relocated feature-flag utilities to @apache-superset/core, this import will break at runtime or cause inconsistent behavior. Verify the canonical source and update imports accordingly.
-
[ ] Error surface/visibility
The catch block clears state but does not surface the error to the user or log it. Consider logging the caught error and/or showing a danger toast so failures to fetch metadata are visible to users and debuggable in logs.
-
[ ] Mixed core package imports
This file now imports t and logging from @apache-superset/core while SupersetClient remains imported from @superset-ui/core. Having core utilities split across two packages can introduce duplicated runtime instances (i18n, logging singletons) or incompatible versions. Validate that these packages are intentionally split, that peerDependencies/aliases will dedupe them at build/runtime, and that no re-exports were intended so everything resolves to a single implementation.
-
[ ] Mixed core packages
The PR imports translation (t) from @apache-superset/core while still importing SupersetClient and getClientErrorObject from @superset-ui/core. This can lead to shipping two overlapping "core" packages, duplicate runtime code, and inconsistent exports across the app. Verify whether SupersetClient and getClientErrorObject should also be re-exported from @apache-superset/core (or vice versa), and ensure all callers are updated consistently to avoid bundle duplication or runtime mismatches.
-
[ ] Import inconsistency
The PR moved t and logging to @apache-superset/core but left SupersetClient imported from @superset-ui/core. This mixed sourcing can cause duplicate/core-version mismatches, subtle runtime differences, or larger bundles. Verify which package is the single source-of-truth for core utilities and make imports consistent.
-
[ ] Packaging / bundle size risk
Importing related utilities from two different packages risks pulling both packages into the client bundle (duplicate code). Confirm whether @apache-superset/core re-exports SupersetClient and, if so, consolidate imports to avoid duplication and ensure consistent runtime behavior.
-
[ ] Mixed import sources
The PR moves logging and t to @apache-superset/core while keeping SupersetClient (and many other UI components) imported from @superset-ui/core. Mixing the old and new packages for related runtime utilities may cause version mismatches, duplicate instances, or context differences (e.g., different singletons for logging or translation state). Verify the packages are aligned and the same logical implementations are used across the app.
-
[ ] Translation import location
t is now imported from @apache-superset/core/ui. Ensure the translation registry and message catalogs remain wired properly after the move so translations resolve the same way. Confirm there are no duplicate t implementations still referenced elsewhere.
-
[ ] Translation import path
The t function was moved from @superset-ui/core to @apache-superset/core/ui. Verify that the new import path is correct and that @apache-superset/core is present in this package's dependencies (or a top-level workspace) so the module resolves at runtime. Confirm that other plugins were updated consistently to avoid mixed imports.
-
[ ] Dependency / build changes required
Moving t to @apache-superset/core likely requires changes to repository-level package.json and build config (new dependency, possible storybook/test config updates). Ensure CI and consumers (extensions) add the new package and that rollouts are coordinated to avoid missing import errors.
-
[ ] Dependency duplication / compatibility
Adding @apache-superset/core while @superset-ui/core remains used for ChartPlugin/ChartMetadata may create two sources of truth for shared utilities. Verify there are no conflicting implementations/version mismatches that could lead to duplicate bundles or inconsistent behavior.
apache
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
![codeant-ai-for-open-source[bot] avatar](https://avatars.githubusercontent.com/u/151810221?v=4 "Published by a pub.dev verified publisher"){kind=small}
