fix(data-source): resolve detail i18n tokens via producing providerId

DataSourceDetail tokens (e.g. value.undergroundGarage) leaked as raw keys
because the client guessed the producing integration via a source-coverage
heuristic that ties when integrations share a generic source like "osm".
Stamp the producing provider id on the detail server-side and key both token
resolution and the attribution footer off it, retiring the heuristic to a
backward-compat fallback.

Author: Medformatik

apps/web/src/components/panels/place/DataSourceSections.tsx

@@ -208,12 +208,14 @@ function AttributionFooter({ detail }: { detail: DataSourceDetail }) {
   const tc = useTranslations("common");
   const registry = useIntegrationRegistry();
 
-  // Pick the data-source integration whose dataSources cover the most of
-  // detail.sources. Several integrations declare "osm" as a sourceId, so a
-  // first-match lookup would attribute a parking detail (sources include
-  // apag + nrw-mobidrom-parking + osm) to ev-charging just because that's
-  // the first integration whose dataSources mention "osm".
-  const meta = pickIntegrationForSources(registry.getByDomain("data-source"), detail.sources);
+  // Resolve the producing integration. The host stamps `providerId`, which is
+  // authoritative; fall back to the source-coverage heuristic only for details
+  // that predate the stamp or come from outside the data-source orchestrator.
+  // The heuristic ties when integrations share a generic sourceId like "osm"
+  // (parking, ev-charging, etc.), so it must not override a known providerId.
+  const meta =
+    (detail.providerId ? registry.get(detail.providerId) : undefined) ??
+    pickIntegrationForSources(registry.getByDomain("data-source"), detail.sources);
   const html = meta?.dataSources ? buildSourceAttribution(meta.dataSources, detail.sources) : "";
   const detailAttributions = detail.attributions ?? [];
 
@@ -298,7 +300,12 @@ export function DataSourceSections({ detail, domain }: Props) {
   const t = useTranslations("dataSources");
   const registry = useIntegrationRegistry();
   const meta = pickIntegrationForSources(registry.getByDomain("data-source"), detail.sources);
-  const resolveT = useDataSourceI18nResolver(meta?.id ?? domain);
+  // Scope token resolution to the integration that produced the detail. The
+  // host stamps `providerId`; fall back to `domain` (this panel's owning
+  // integration) before `meta` — `meta` is an attribution heuristic that ties
+  // when sources share a generic prefix (e.g. "osm") and can pick an unrelated
+  // integration, leaking raw token keys like `value.undergroundGarage`.
+  const resolveT = useDataSourceI18nResolver(detail.providerId ?? domain ?? meta?.id);
   const header = resolveSourceHeader(detail, domain);
   const structuredSections = detail.sections.map((section) =>
     translateStructuredSection(section, resolveT),

integrations/data-source/index.ts

@@ -86,8 +86,11 @@ export function setup(ctx: IntegrationContext): void {
         return;
       }
       reply.header("Cache-Control", `public, max-age=${Math.min(detailTtl, 300)}`);
+      // Stamp the producing provider id so the client resolves this detail's
+      // I18nTokens against the right integration catalog. Done on the way out
+      // (not inside the cached producer) so cached entries are stamped too.
       reply.send({
-        data: envelope.data,
+        data: { ...envelope.data, providerId: provider.id },
         attributions: envelope.attributions,
         freshness: envelope.freshness,
       });

packages/integration-framework/src/contracts/mobility-data-source-provider.ts

@@ -213,6 +213,15 @@ export interface OsmIdentity {
 export interface DataSourceDetail {
   id: string;
   sources: string[];
+  /**
+   * Id of the data-source provider that produced this detail (e.g. "parking",
+   * "ev-charging"). Stamped by the host's data-source route so the client can
+   * resolve this detail's `I18nToken`s against the correct integration string
+   * catalog. `sources` is unreliable for this — it lists upstream feeds (often
+   * a generic "osm") that several integrations share, so picking the catalog
+   * by source coverage ties and selects the wrong integration.
+   */
+  providerId?: string;
   name: string;
   coordinates: LngLat;
   /** Identity used by the place resolver to gate OSM snapping. See {@link OsmIdentity}. */