2 Commits

Include renames

Author	SHA1	Message	Date
Florian Schmidt	bfa0b537ee	i18n: ship the UI in English and German ... The last open item on the M7 list. Number and currency formatting was already locale-aware, but every string in the UI was an English literal, so a German instance read half in each language -- German data, English chrome. This translates all of it and adds the machinery to keep it translated. Strings live in Localization/Strings.resx (English, neutral) and Strings.de.resx. The neutral file generates a strongly-typed accessor at build time, aliased as S in _Imports.razor, so components reference compiled properties -- @S.Common_Save, not a string key. That choice is the point: across 4,500 lines of markup, a key lookup that silently falls back to its own name is a defect you find in production, while a renamed property is a build error. Generation runs in MSBuild rather than the IDE designer, so dotnet build alone reproduces it anywhere. Resource fallback is the hazard here. Ask for a key the German satellite lacks and ResourceManager quietly serves the English one -- correct at runtime, disastrous at release time, because a half-translated build looks perfectly healthy. StringResourceTests reads each satellite with tryParents: false, which is the only way to see what one actually contains, and fails on a missing or blank translation, a placeholder that changed arity, an orphan, or a key nothing references. Three things needed more than substitution: - Domain enums reached the screen as bare identifiers. They stay bare in the model -- they are persisted as text and appear in the REST API, so their names are part of the data contract -- and DisplayNames is now the single place that decides how each value is spoken. Every arm ends in a fallback returning the identifier, so a value added later cannot throw mid-render; EnumDisplayNameTests is what stops that safety net quietly becoming the shipping behaviour. - Infrastructure was writing display text: FlowService's "Other (X)", MeterPeriodView's "Generation"/"Consumption", the HA connection-test verdicts, the updater's snackbar, the CSV importer's row warnings. Each now returns an outcome value and the UI supplies the words, which is where the reader's language is known. Diagnostics that are not ours -- an HTTP status, systemd's stderr, an exception message -- are passed through untranslated, and every English summary is kept alongside the outcome so log lines never move with the UI language. The UpdateRunner change is additive only; no gate was touched. - Importer warnings carry their arguments rather than a finished sentence, so the numbers inside them pick up the reader's grouping. A register that reads 2.940,19 everywhere else must not read 2940.19 only inside a warning. Switching language is a redirect through /culture/set followed by a full reload, not an interactive state change: a Blazor Server circuit is fixed to the culture of the request that opened it. That makes the endpoint a redirector taking its target from the query string, so anything but a local path is refused rather than followed. Preference order is the cookie, then Accept-Language, then MeterVault__Locale -- an instance can be pinned to one language and a reader can still switch. Locale keeps its documented default of "en". Format now follows CurrentCulture instead of a hardcoded de-DE, so an instance with nothing configured and a browser asking for English will show English number formatting where it previously showed German; set MeterVault__Locale=de to pin the old behaviour. The importer's de-DE parsing is untouched and stays that way -- that dialect is a property of the spreadsheets, not of whoever is looking at the dashboard. Anything that comes from the database -- meter names, energy-type display names, category names -- is user data and is never translated. Claude-Session: https://claude.ai/code/session_0112ezeWqaZ85kTj5bYu9JHx	2026-08-13 16:36:25 +02:00
schmidt.florian	7e34aeccc8	Meter chain topology + per-energy-type flow (Sankey) pages ... Adds a meter hierarchy and a flow view: a downstream meter is a *subsection* of an upstream one (not an addition), so you can see where a main meter's flow divides — e.g. official water → garden, pool, other; grid/battery → all → car. - MeterLink (schema + migration AddMeterLinks): a directed from→to flow edge. Multi-parent allowed (a merge, e.g. grid + solar → house); multi-child is a split. Cascade-deletes with either endpoint; unique + distinct-endpoint checks. - FlowService: per energy type + period, builds a Sankey graph — nodes = meters sized by consumption; link value = downstream meter's consumption, split proportionally across multiple upstreams; unaccounted remainder under a meter becomes a synthetic "Other" node; depth via topological longest-path. - SankeyChart.razor: hand-rolled inline-SVG Sankey (ApexCharts has no Sankey type) — columns by depth, nodes stacked by value, bezier ribbons sized by flow, left→right, theme-aware, HTML-encoded labels, tooltips. Built as a MarkupString to sidestep Razor's <text> element clash. - /energy/{id} page (one per energy type): KPIs (consumption + cost), the flow Sankey, and the meter list. NavMenu now lists a link per energy type (Electricity, Water, Gas, …) loaded from the DB. - Meters admin: cycle-safe "Sub-meter of (upstream meters)" multi-select (descendants excluded to prevent cycles); reconciles meter_link rows on save. - Reference data seeds a demo chain (Haus → Auto) so electricity flow shows Haus dividing into Auto + Other. Tests: FlowServiceTests (single-parent remainder; two-parent proportional split); render test now asserts the flow chain + covers /energy/{id}. 69 Core + 47 Integration = 116 green. Live-verified: Haus 95,450 kWh → Auto 51,909 + Other 43,541 (flow conserved), all 5 energy-type pages render. Claude-Session: https://claude.ai/code/session_01Lz2RqAsnQhetqWNoCDfexK	2026-07-14 14:02:16 +02:00