4 Commits

Include renames

Author	SHA1	Message	Date
tajniak81andClaude Opus 5	dc6febf815	Phone App: finish the admin screen; translate the last English strings ... Three loose ends from the last two commits, each of which was named as deliberately-not-done and none of which is worth carrying further. The phone's create-user sheet had no organization picker. The endpoint has taken an `organization` since orgs existed and the Web App has offered the choice all along, so a superadmin on the phone could only ever create accounts in their own org - a silent restriction rather than a stated one. The sheet now loads the orgs and offers them to a superadmin, with the same blank "no organization" option and the same hint as the web. An admin still gets no picker, because the server forces its own org on their members and a picker that cannot change the outcome is a lie. The listing is manager-only and can fail, in which case the picker offers only "no organization" rather than blocking the form. A locked role picker or delete action was greyed out with no reason given. The web has explained itself in a title attribute since those guards existed, and the sentences - admin.cantChangeOwnRole and the rest - have been sitting translated in the phone's own language files since the screen was translated. Hover has no touch equivalent, so the two controls take different routes: a long-press on the role picker shows the reason as a tooltip, and the overflow menu carries it under the action, because a disabled menu item cannot be long-pressed and silently greying it out is the thing being fixed. settings.integrations.* and charging.control.* were English-only in *both* apps - 70 keys, identical text, identical key sets - so they are translated once and land in all four language files. OCPP and CSMS are protocol names and stay; product names (Toyota Connected, MyToyota, Anker Solix, Lexus) stay; everything else follows the wording already in each language's file. The Web App's files are edited as text rather than round-tripped through a JSON dump, because they keep a blank line before every nested block and a dump flattens it - a 900-line translation file is hard enough to read without losing its paragraphs. Both diffs are purely additive as a result. Both apps now have every key in all three languages: 738 in the web, and the phone reports zero fallbacks. A new test locks that in - every key en.json carries must exist in pl.json and da.json - and it was checked by deleting a key and watching it fail, because a guard that cannot fire is not a guard. Verified by flutter analyze (clean), flutter test - 21 pass, 1 of them new - flutter build apk --debug, and npm run build for the Web App. The key checker reports 575 static t() keys in the phone and 738 in the web resolving with no fallbacks in either language. Not verified: still nothing run against a live API Server or on a device. In particular the organization picker's happy path - a superadmin creating an account into a chosen org - has not been exercised end to end; it is the one piece here that touches the API rather than only the language files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 22:13:37 +02:00
tajniak81andClaude Opus 5	4372b870ac	Phone App: take the admin users screen off hardcoded English ... The last screen the phone rendered in English regardless of the language picker. Its strings are the web AdminUsers.vue's, which have been translated since b6bb6b1, so the admin.* subtree is copied across the same way the rest were and Polish and Danish arrive complete. Two strings are the phone's own, and only because the two UIs confirm differently: the web deletes behind a browser confirm(), which supplies its own title, and reports a password reset by closing the modal. The phone has a dialog title and a snackbar to fill, so admin.deleteTitle and admin.passwordUpdated are new. The role picker printed its values raw - Text(r) over "user"/"admin"/ "superadmin" - which happened to read as English because the API's enum is English. It goes through admin.roles.* now, like the web's, and the new lookup is covered by the catalogue test alongside the other dynamic ones. The Web App needed nothing: AdminUsers.vue was already fully translated, including the role options and the tooltips explaining why a locked row cannot be edited. Checked rather than assumed - it has 31 t() calls and no bare text nodes in the template. Two differences from the web turned up while reading them side by side, both feature gaps rather than translation ones, and both left alone here: the phone's create-user sheet has no organization picker for a superadmin (the server puts the account in the creator's org), and the phone disables a locked role dropdown or delete action without saying why, where the web explains it in a title attribute. The strings for that explanation are now sitting in the phone's language files, so it is a small change if wanted. Verified by flutter analyze (clean), flutter test - 20 pass, 1 of them new - and flutter build apk --debug. The key checker reports all 568 static t() keys resolving in en.json. Not verified: still nothing run against a live API Server or on a device. TRANSLATIONS.md and the Phone App README both listed this screen as outstanding; the only gap either records now is settings.integrations.* / charging.control.*, which is the web app's too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 21:58:00 +02:00
tajniak81andClaude Opus 5	a2d9efec7e	Phone App: take the car screen off hardcoded English ... The previous commit left the car screen half translated: its tab labels went through t(), and everything underneath them did not. A Polish user opening a car got translated tabs over English tiles, English forms and English dialogs, which is worse than either extreme because it reads as a bug rather than as a missing translation. So the whole screen and everything it opens now reads from the language files: the record tiles, the share and delete-car dialogs, the service and part sheets it hosts, record_form_sheets.dart, car_form_sheet.dart, and the attachment field whose buttons surface inside all of them. Almost none of these strings are new. The Web App has said all of this in three languages since b6bb6b1, so forms.*, enums.*, attachment.* and errors.* are copied out of its language files the same way car.* was, and Polish and Danish arrive complete. What is written here is only what the phone alone needs, and the categories are worth naming because they are the reason the two apps' files are not identical: tooltips, because the web labels its buttons; the tiles' running prose, because the web lays the same data out as table columns; client-side validation, because the web leans on the browser's `required`; and the snackbars. Three things changed shape rather than just wording. The per-record delete prompts were one template with a noun slotted in - "Delete this $what?" - which does not survive translation into a language that inflects the noun. Each collection now names its own confirmation string, which is what the web already had. The delete-car dialog counted with a hand-rolled `"$n $noun${n == 1 ? '' : 's'}"`. Polish has three plural forms, so that could not be translated at all; it now goes through the CLDR plurals in car.delete.*. It also only ever named service records and parts, while the cascade takes maintenance, fuel, charges and documents too - the translated body names all six, so it is now passed the whole data set rather than two counts. The enum labels (fuel types, maintenance type/status, document and reminder types) were four const maps duplicated between the tiles and the pickers. They are one lookup against enums.* now, with an unknown value falling back to the raw key rather than a blank - the server owns that enum, and a value added there should stay legible in an app that has not caught up. Found and fixed while testing: the view picker rendered the literal string "car.tabs.provider" as a row label on an unlinked car. That key does not exist by design - a linked car's tab is named after the service, an unlinked one falls back to car.tabs.connected - and the picker was the one caller that did not know it. Verified by flutter analyze (clean), flutter test - 19 pass, 7 of them new - and flutter build apk --debug. The new tests cover what the analyzer cannot see: the lookups built from a key at render time (car.tabs.$key, enums.fuelType.$v, the delete dialog's plural counts, the connected service's readings) are checked to have a real label in all three languages, so a catalogue entry with no translation fails a test instead of reaching a screen as a raw key path. That is the check that caught the bug above. A one-off script also confirmed all 550 static t() keys resolve in en.json. Not verified: still nothing run against a live API Server or on a device. Known gaps, deliberately left: admin_users_screen.dart is still English, and settings.integrations.* / charging.control.* exist in en.json only. The second one is not the phone's alone - the Web App has exactly the same gap, so translating that OCPP and connector vocabulary belongs to both apps in one pass rather than letting the phone run ahead of the app the strings are copied from. Both are now recorded in TRANSLATIONS.md, which had claimed the car screen as untranslated and the web app as complete. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 21:49:48 +02:00
tajniak81andClaude Opus 4.8	b6bb6b1df0	Add a language-switch system with per-language files ... Introduce a hand-rolled i18n layer across all three UIs, each reading its text from per-language JSON files (English base + Polish + Danish). Nothing in the converted screens hardcodes English any more. - Web App (Vue): src/i18n/{en,pl,da}.json + index.js exposing t()/tSplit(), reactive to the signed-in profile locale. Every view, component, form and the status labels in lib/format.js go through t(). - API Server panel (Vue): src/i18n/ with its own localStorage-persisted language (the panel has no user profile) and a header language picker. Chrome, cards, login and API section titles translated; endpoint reference descriptions intentionally kept in English. Rebuilt embedded dist. - Phone App (Flutter): assets/i18n/ + lib/i18n.dart loaded at startup, driven by AppSettings.locale. Nav, login, lock, dashboard, the full Settings panel (incl. language picker) and format.dart status labels translated; remaining detail screens fall back to English. Language = the language half of the existing BCP-47 locale; the region half still drives date/number/currency formatting. Missing keys fall back to English, and plurals use Intl.PluralRules / Intl.plural so Polish gets the correct one/few/many forms. Settings flags languages without a translation. Tests updated to assert the localized (Polish) status wording; all pass. See TRANSLATIONS.md for the format and how to add a language. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 20:07:48 +02:00