mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-20 07:14:13 +02:00
Wiki Page Revisions
26 Commits
26 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ispyisail
|
d19511304c |
Die vier neuen Seiten ins Deutsche übersetzen
conductors-DE, templates-DE, mouse_modifiers-DE und printing_and_export-DE. Die Beschriftungen stammen nicht aus dem Gefühl, sondern aus lang/qet_de.ts: Mehrpolig und Einpolig, „Spannung / Protokoll:“, „Leiterquerschnitt:“, „Sichtbarer Text“, „Textformel:“, „Linienstärke:“, „Phasenanzahl“, „Neutralleiter“, „Erde“, „Leiter zurücksetzen“, „Automatische Leiterverbindung aktivieren“, „Zu druckende Seiten:“, „Seite an Seitengröße anpassen“, „Gesamte Blattfläche verwenden“, „Ganze Seite exportieren“, „Nur Bauteile exportieren“, „Vorlage erstellen“, „Name der neuen Vorlage“. Beim Übersetzen sind zwei Lücken der deutschen Oberfläche aufgefallen, die auf den Seiten stehen, weil sie dort gebraucht werden: - Der Menüeintrag „Liste de câblage (base de données)“ ist in qet_de.ts als unfinished markiert; deutsche Nutzer sehen die französische Beschriftung. conductors-DE sagt das und nennt die Spalten trotzdem. - Sämtliche Statuszeilen-Hinweise zu den Maustasten sind unübersetzt -- also genau die Hinweise, die diese Tasten erklären würden. Deutsche Nutzer lesen dort „Maj = carré, Ctrl = depuis le centre“. mouse_modifiers-DE stellt das an den Anfang und übersetzt die Hinweise mit. Im Deutschen heißen Register und Sammlung beide „Vorlagen“; die französische Doppelbenennung entfällt damit, was templates-DE vermerkt. languages.md: alle vier Seiten stehen jetzt in drei Sprachen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj |
||
|
ispyisail
|
7335a2c66e |
Traduire les trois pages restantes, et corriger la page d'impression
templates-FR, mouse_modifiers-FR et printing_and_export-FR, traduits en reprenant les libellés de l'application plutôt qu'en les réinventant : « Folios à imprimer », « Adapter le folio à la page », « Utiliser toute la feuille », « Options de rendu », « Exporter entièrement le folio », « Exporter seulement les éléments », « SVG: fond transparent », « Conserver les proportions », « Créer un template », « Enregistrer un template », « Nom du nouveau template ». La barre d'état des formes est citée telle quelle, Maj comprise. Traduire a fait apparaître deux erreurs dans la page anglaise, corrigées ici aussi : - printing_and_export listait « Draw guides » comme une option. Ce n'est pas une option : draw_guides existe comme propriété enregistrée, aucune fenêtre ne la propose, et l'impression la force à false (projectprintwindow.cpp:546). La ligne est remplacée par une note qui dit pourquoi les guides n'arrivent jamais dans un export. - Le filtre de date de la fenêtre d'impression manquait entièrement. Il ne filtre pas l'impression : il coche et décoche la liste des folios d'après la date du cartouche, soit à partir d'une date, soit à une date exacte. « Imprimer tout ce qui a été révisé depuis le 3 » devient un clic. languages.md : les quatre pages du jour sont maintenant marquées traduites en français, et pas en allemand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj |
||
|
ispyisail
|
fea08ce1f6 |
Traduire la page Conducteurs en français
conductors-FR, traduit depuis l'anglais en reprenant le vocabulaire de l'application plutôt qu'en le réinventant : les libellés viennent de sources/ui/conductorpropertieswidget.ui et des chaînes tr() du code, qui sont déjà en français. Ce que cela corrige par rapport à une traduction faite de mémoire : - Multifilaire / Unifilaire, pas "multi-fils" ; - « Tension / Protocole », « Fonction », « Section du conducteur », « Texte visible », « Formule du texte », « Taille de trait », « Nombre de phase », « Neutre », « Terre », « PEN » -- tels quels ; - les champs cable et bus sont écrits en minuscules et sans accent, comme dans la fenêtre, parce que c'est ce que l'utilisateur voit ; - « Réinitialiser les conducteurs », « Création automatique de conducteur(s) », « Coupure automatique de conducteur(s) », « Liste de câblage (base de données) » sont les libellés exacts des menus. Un détail vérifié qui méritait d'être dit : la fenêtre parle de « Section du conducteur » et la colonne d'export de « Section du fil ». C'est le même champ sous deux noms, et la page le signale. languages.md : le tableau d'état des traductions ignorait les quatre pages ajoutées aujourd'hui et laissait croire à une couverture complète. Les quatre y figurent maintenant, avec leur état réel. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj |
||
|
ispyisail
|
f3bfa8387c |
Document Search & Replace and the nomenclature/summary query builder
Both were confirmed still-real gaps from the survey: Search & Replace (sources/SearchAndReplace/, ~3,180 lines) was a single features.md bullet, and the query-builder UI (sources/dataBase/ui/, ~1,088 lines) was only named once inside project_database.md as a pointer to ElementQueryWidget, with no workflow documentation. ## Search & Replace The name is misleading and worth correcting up front: this is not text find/replace. SearchAndReplaceWorker::applyChange() shows the real semantics -- an empty field leaves a property untouched, a filled field replaces it wholesale (never a substring swap), and a reserved sentinel string (set via a per-field checkbox, never typed by the user) explicitly clears a field. Three states per field, not two. Traced through setupLineEdit()'s own doc comment and applyChange()'s three-branch behavior to be sure of this before writing it down. ## Nomenclature / summary query builder ElementQueryWidget (element_nomenclature_view) and SummaryQueryWidget (project_summary_view) are a visual SELECT builder: two-list column picker, seven filter modes with their exact SQL traced from on_m_filter_le_textEdited()'s switch statement (No filter/Not empty/ Empty/Contains/Does not contain/Is equal/Is not equal), group-by and count, an "Edit SQL query" escape hatch, and named saved configurations. Explicit about what it is not: not a general SQL client (bound to one view, can't change the FROM even in raw-SQL mode), and not the same column set as --export-bom, which was verified to hardcode its own fixed list in cli_export.cpp rather than sharing this widget's choices. Links the existing one-line Search & Replace mentions in features (all three languages) to the new page. EN/FR/DE for both. |
||
|
ispyisail
|
b4c9b0e3f5 |
Document managing collections: folders, writability, the two-tab panel
sources/ElementsCollection/ is the largest undocumented chunk found this session -- separate from elements_XML (the file format) and element_editor (drawing one element), nothing covered day-to-day collection management. The finding worth having written down: the common collection's read-only status is not a filesystem permissions check. ElementsLocation::isWritable() refuses anything under commonElementsDirN() unconditionally, by path -- that's why New folder/New element/rename/delete are greyed out there even running as an administrator, and why dragging an element out of the common collection copies it (there is no source to remove) while nothing can be rearranged inside it. Custom and company are genuinely writable; an embedded (project-internal) element follows the project's own read-only state. Also documents the panel's second tab -- Templates/macros, a reusable diagram-fragment mechanism distinct from single elements, drag-dropped onto a folio as a group -- and the full context-menu action set (new folder/element, edit, delete with a real not-undoable warning, reveal in file manager, reload from disk, the solo-folder filter, folder properties). Updates the Element Collections & Libraries stub in user_manual (EN/FR/DE) to link here instead of the placeholder bullets from the correction pass. EN/FR/DE. |
||
|
ispyisail
|
27d2e2b3d6 |
Correct user_manual and add a preferences reference
user_manual.md read as confident-sounding but unverified filler, the same failure mode already found and fixed in api_reference this session. Checked every concrete claim in Projects & Folios, Working with Elements, Drawing Wires, Reports, Preferences and the shortcuts table against the actual source, and found roughly a dozen fabrications, not one or two: - File -> New Project has no dialog at all (QETDiagramEditor::newProject() creates the project and calls addNewDiagram() immediately) -- not a three-step page-size/orientation/margin wizard. - There is no "folio type" concept anywhere in the source -- no single-line/multiline/control-diagram selector. Adding a folio (addNewDiagram()) is likewise instant, no dialog. - No per-folio "scale" property exists. - "Auto-save, configure in Preferences" doesn't exist; there is a 20-minute crash-recovery backup timer with no exposed interval setting. - The claimed element categories (01_Misc/03_Control/04_Energy/ 10_Electrical) don't match anything in the collection -- real top-level trees are 10_allpole/20_logic/30_hydraulic/50_pneumatic/60_energy. - Every one of Rotate=R, Flip=H/V and Fit-to-page=Ctrl+0 in the shortcuts table is wrong against ShortcutManager's actual registrations: rotate is Space, fit-to-page is Ctrl+9, and flip doesn't exist at all for an element placed on a folio -- flip (F) is element-editor-only, for redrawing the symbol itself. - No element-locking or persistent-grouping feature exists on current master; removed rather than described. - No wire-splitting mechanism exists (grep for split/conductor turns up nothing); "wires only connect at terminals" already said correctly elsewhere in the same file. - No "Project -> Reports" menu or "I/O Documentation" report type exists; nomenclature/wiring-list generation is File -> Export or the CLI (--export-bom etc.), already documented in api_reference. - The dynamic-text variable list (%id = "element ID", %label, %comment...) contradicts this session's own verified variables.md -- %id is a folio index, not an element reference number. - No in-app "community element repository" browser exists. - The claimed Preferences categories (Display/Projects/Grid) don't match the five real pages (General, New project, Export, Print, Shortcuts). Corrected or removed each, linking to the real mechanism where one of this session's other pages already covers it (variables, api_reference, project_database, element_editor, title_blocks, folio_links) rather than re-describing it. Softened Multi-User Workflows with an actual caveat -- project_database.md already established there's no shared-state mechanism, so "merge changes when working in parallel" needed the warning that a merge conflict there is a raw XML conflict, not a structured one. Applied identically across EN/FR/DE, not just the English source. Adds a new preferences reference page (EN/FR/DE) covering what the real five pages actually control, built from configdialog.cpp and sources/ui/configpage/ directly: the six collection/title-block path pickers on General (and why relocating one without a trailing slash used to silently break IEC 81346 prefixes -- bugtracker #671), the New project/New folio page's dual identity (same class, title and target change depending on whether a project is open), and that Export and Print share one underlying widget rather than being separate implementations. |
||
|
ispyisail
|
1bf1740fc0 |
Document using the element editor -- drawing tools, not just the resulting XML
sources/editor/ is ~22,900 lines and the only wiki coverage was a stub telling readers to see the elements_XML reference for 'designing element graphics' and 'defining connection terminals' -- which documents the file format an element becomes, not how to use the editor that draws it. element_linking already covers the master/slave/terminal semantics; this covers the tool itself. The finding worth having written down: width, height and hotspot have no input dialog at all. ElementScene::toXml() derives them from the drawn geometry on every save -- bounding rect rounded up to the next multiple of 10 (with a quirk: a remainder over 6 rounds up an extra ten, which is exactly the 42-to-50 example elements_definition_attribute.md already used without explaining where the number came from), hotspot centered in that box. And if the drawing doesn't straddle the scene origin, centerElementToOrigin() actually moves every primitive on save, not just the saved coordinates -- draw far from the crosshair and a save visibly shifts everything. Also: the checkElement() validation that runs before every save (0 terminals warns but doesn't block, except folio-report and conductor-definition elements, which must have exactly one or the save is refused); the Save vs Save As vs Save As File distinction (opened-from location vs a collection picker vs a raw file picker); and the terminal placement shortcuts (Space rotates through the four orientations while placing, the tool re-arms at the same orientation for a row of pins). Replaces the empty 'Creating Custom Elements' stub in user_manual (all three languages) with links to this page, element_linking and elements_XML instead of a four-bullet list pointing at one reference page. EN/FR/DE. |
||
|
ispyisail
|
c1b47381b2 |
Document DXF: two unrelated features reduced to one bullet each
sources/createdxf.*, sources/dxfpaintdevice.*, sources/dxf/dxftoelmt.* total ~1,780 lines. The only wiki coverage was a single repeated bullet -- 'DXF -- CAD format for collaboration' -- across features, faq and user_manual, in all three languages, describing neither direction accurately: it reads as one feature, and it's actually two that share nothing but a file extension. Export (File -> Export, alongside PDF/PNG/SVG, in-process) reuses every item's existing paint() code through a custom QPaintEngine (DxfPaintEngine) rather than a separate DXF renderer -- documented from that class's own thorough header comment, including the real fidelity table it specifies: rectangles and filled paths lose their fill (no HATCH primitive in this DXF dialect), arcs become straight-line chords, and images become position-preserving placeholder rectangles since DXF has no raster entity here. No CLI verb exists for it, unlike PDF/PNG/SVG. Import (element editor only, not the diagram editor -- File -> Import a DXF file) is a symbol-authoring tool: it shells out to dxf2elmt, a separate third-party program QET does not bundle, the same external-tool pattern as qet_tb_generator already documented in api_reference. Traces the actual call: , stdout read as .elmt XML, pushed onto the element editor's undo stack as one operation. Makes explicit what neither direction is: not a way to place a DXF drawing on a folio, not round-trip safe (export's own limitations rule that out before even considering the code is entirely separate), and not a full CAD interchange path -- no layers, blocks or metadata, just primitives. Links the existing one-line mentions in features/faq/user_manual (all three languages) to the new page instead of rewriting them, since they are fine as list bullets. EN/FR/DE. |
||
|
ispyisail
|
87071dc311 |
Document EDZ import: zero wiki coverage of a whole import format
sources/import/edz/ is ~1,150 lines (excluding the vendored LZMA SDK) implementing import of EPLAN Data Portal parts, and the word 'EDZ' appeared nowhere on the wiki -- not a passing mention, not a features bullet, nothing. The module already carries a thorough developer README; this restructures it for the wiki rather than writing from scratch, verified line-by-line against the source: the menu path, the exact field mapping (manufacturer, order number, description and comment land in the same four element-information fields the BOM already reads), the zip-vs-7z format detection and its current 7z-only limitation, and the point most likely to surprise a user -- the imported symbol is a generic generated rectangle, not a copy of the EPLAN macro's geometry, because that geometry is tokenised EPLAN PXF referencing EPLAN's own libraries with nothing portable in it. Also carries the module's EPLAN Data Portal Terms of Use notice forward, framed as a description of what QET's reader does (parses only portable factual data, reproduces no EPLAN-proprietary geometry) rather than legal advice about the reader's own situation. EN/FR/DE. |
||
|
ispyisail
|
2e4b123e92 |
Document page/wire linking -- folio reports -- in the user's own words
Wires continuing across pages had no page anywhere: element_linking
covers master/slave cross-references, not next_report/previous_report.
Written with "page" and "wire" in the prose and a glossary mapping them
to folio and conductor, since that is how people ask about it.
The central fact, taken from LinkElementCommand::isLinkable(): QET checks
exactly two things when linking two reports -- matching inverse type, and
both being free. It does not check that they are on different pages, that
either has a wire attached, that the two wires share a potential, or that
the arrows point sensibly. A link is an assertion the user makes and QET
renders without verifying, so --export-links is the only real audit.
Also documents what was written down nowhere: a report's dynamic text is
restricted to five variables (folioReportInfoKeys), the label describes
the partner's position rather than its own, report terminals are
deliberately excluded from wire-number counts because they are not real
terminals, linking replaces rather than adds, and a report is only
clickable in an exported PDF when its text actually shows %{label}.
EN/FR/DE.
|
||
|
ispyisail
|
5e19ac2f65 |
Document the .titleblock template format
sources/titleblock/ is ~8,300 lines and the format was undocumented:
title blocks were mentioned in features and user_manual, but nothing said
how to author one.
Covers the grid model and the part that makes a template fit any paper
size -- the three kinds of column length, where an unprefixed value is
absolute pixels, t22% is a fraction of the total width and r100% takes
the remainder, while rows are always absolute. Also label-vs-value and
why only labels are normally translated, the more permissive variable
substitution used here (both %{name} and %name, longest key first, but
only the braced form is discoverable by the editor), the two logo storage
forms and the fact that bitmaps are forced to base64, the four collections
including the embedded one that makes a project self-contained, and the
cell tag names.
Notes F023 inline as a known defect: a logo whose storage attribute is
neither xml nor base64 is written back with no image data.
EN/FR/DE.
|
||
|
ispyisail
|
53e9b9b4e9 |
Document auto-numbering: three systems, sixteen part types, and freezing
sources/autoNum/ is ~5,085 lines, and the only wiki pages mentioning it were 7-to-9-line XML reference stubs describing where it is stored. Covers what a scheme actually is -- an ordered list of parts -- and all sixteen part types: seven counters (with the per-folio variants and wrap's modulus), seven context parts that take their value from the element's position or folio, and string/alpha. Documents that format overrides the type's natural zero-padding, and that alpha increments like a spreadsheet column name. The behaviours that surprise people and were written down nowhere: - a scheme supplies sequences, a formula places them, and a %sequ_N whose index the scheme does not define prints itself verbatim with no warning - a new conductor joining an existing potential inherits its number; only a genuinely new potential draws a fresh one, and a potential whose conductors disagree opens the potential selector - folio variables in a conductor formula resolve per conductor, not per potential - freezing exists at three scopes (project, folio, item), which is why a project can hold labels that no longer match their formula - a scheme with an empty title or formula is silently dropped on save Also notes that terminal numbering is a separate feature honouring auto_num_locked. EN/FR/DE. |
||
|
ispyisail
|
02de705a9c |
Document terminal strips, 9k lines of shipped feature with no user docs
sources/TerminalStrip/ is 66 files and ~9,250 lines, and the words "terminal strip" appeared on the wiki only in the roadmap, history, vision and contributing pages -- discussed as a topic, never documented as a feature. Covers the part that actually causes confusion: the three-layer model of strip / physical terminal / real terminal, where a physical terminal's several real terminals are its levels, ordered back to front from the mounting plate. Also the six conditions a selection must meet to be bridgeable (the reason the button greys out), free terminals that exist in the strip but on no folio, the four-level ceiling in the drawing that the data model itself does not impose, and the <terminal_strips> XML. States the honest caveats: the menu entry is labelled (DEV) in the shipped source, and no example project contains strip data -- verified, the 143 "terminal_strips" hits in industrial.qet are all element collection paths, not strip data. EN/FR/DE. |
||
|
ispyisail
|
7ebdce88f4 |
Document the variable and formula language, all five dialects of it
There is no single %-variable language in QET: element labels, conductor
texts, the folio field, title block cells and cross-reference labels each
resolve a different set, and a variable that works in one is left as
literal text in another with no error. The folio field is the sharpest
case -- it understands %autonum, %id and %total and nothing else, so the
%f and %{...} people reach for there print verbatim on every folio.
Also records two things the code says that nothing else documents:
- %f and %F are not interchangeable. %f is the folio index; %F inserts
the folio *field*, which defaults to "%id/%total" and so renders
"3/12". It works only because %F is expanded before %id and %total in
the same pass.
- AssignVariables::replaceVariable() is a hard-coded list, not a lookup
over elementInfoKeys(). Three omissions are deliberate (formula, xref,
exclude_from_bom) but machine_manufacturer_reference_auxiliary1..4 are
simply missing: the fields exist and can be filled in, the plain
machine_manufacturer_reference resolves, and the four auxiliary
variants stay on the drawing as literal text.
EN/FR/DE.
|
||
|
ispyisail
|
8a800dbea6 |
Document the project database as what it is: a derived in-memory cache
The name invites the assumption that QET has a real database behind a project. It does not -- projectDataBase is rebuilt from the .qet XML on every open and never written back, and almost everything that makes the current design safe follows from that: no schema version, no migrations, a wrong row costs nothing, the database cannot disagree with the drawing. Covers the lifecycle, the six tables and three views, why the schema is generated from elementInfoKeys() at runtime, why the nomenclature filter belongs in the view rather than the element table, and the terminal identity problem -- Terminal::uuid() is a catalog position id shared by every instance, which is why the primary key is (uuid, element_uuid) and why stableUuid() derives one from geometry. That last point is the one that matters for any future persistence work: a guessed identity is a cache miss today and a one-shot migration of everyone's projects if the database ever becomes the file format. EN/FR/DE. |
||
|
ispyisail
|
2ef2b7cec1 |
Document master/slave/terminal linking, the feature nothing in the collection uses
The element editor can declare a master's contact budget, cap how many slaves may attach, mark a terminal as isolating a potential, and keep an element out of the BOM. None of it was documented anywhere, and the measured result is that none of it is used: of the 6918 elements in the 10_electric collection, 0 declare slaveContactGroups and 0 declare max_slaves; no shipped example project uses auxiliary1-4. Adds element_linking (EN/FR/DE) as a guide, and turns the one-line kindInformations and elementInformations reference stubs into the actual XML vocabulary, taken from ElementData::kindInfoToXml/kindInfoFromXml. Records two traps worth knowing: max_slaves counts slave elements rather than contacts, and potential_isolating / auto_num_locked / exclude_from_bom are compared against the exact string "true". |
||
|
ispyisail
|
0c62fefef6 |
TIER 4 COMPLETE: Add History and License translations (FR/DE)
Completed the entire QElectroTech wiki multi-language translation project: - history-FR.md (250+ lines) — Évolution de QElectroTech 2007-2026 - history-DE.md (250+ lines) — Entwicklung von QElectroTech 2007-2026 - license-FR.md (350+ lines) — Informations de licence GPL v2 - license-DE.md (350+ lines) — GPL v2 Lizenzinformationen - languages.md — Updated translation status matrix showing all 4 tiers complete across 3 languages (English/Français/Deutsch) 🎉 Wiki Translation Project Complete: ✅ 15 Tier 1 pages × 3 languages (Onboarding) ✅ 9 Tier 2 pages × 3 languages (Engagement) ✅ 15 Tier 3 pages × 3 languages (Developer) ✅ 2 Tier 4 pages × 3 languages (Legal/Reference) = 41 total pages × 3 languages = 123 translated pages All pages now have: - Language footer with quick navigation - Cross-language links via languages.md hub - Complete French and German translations |
||
|
ispyisail
|
fe26335b90 |
TIER 3 COMPLETE: Add CLI Reference and Development Roadmap translations (FR/DE)
- cli_reference-FR.md: Comprehensive French translation of CLI guide (options, exports, automation examples) - cli_reference-DE.md: Complete German translation matching French coverage - development_roadmap-FR.md: French translation of roadmap (Qt6, refactoring, collaboration, performance) - development_roadmap-DE.md: German translation of roadmap with identical content - languages.md: Updated to show ALL Tier 3 developer pages complete for French and German ✅ TIER 3 DEVELOPER PATH COMPLETE: 8 of 8 pages now translated to French and German - Contributing ✅ FR/DE - Building ✅ FR/DE - API Reference ✅ FR/DE - CLI Reference ✅ FR/DE - Development Roadmap ✅ FR/DE Total wiki coverage: - English: 11 pages (Tiers 1-3) - French: 13 pages (Tiers 1-3) - German: 13 pages (Tiers 1-3) |
||
|
ispyisail
|
7cc0febd66 |
Add French and German translations for Building page
- building-FR.md: Complete French translation of Building guide (350+ lines) covering installation prerequisites (Linux/macOS/Windows), step-by-step build process, build variants (debug/ASAN/TSan), testing, and troubleshooting - building-DE.md: Full German translation with identical comprehensive coverage as French version - languages.md: Updated to show Contributing and Building pages now complete for FR/DE Tier 3 progress: 4 of 8 developer pages now translated to French and German. Development path fully supported for French and German speakers. |
||
|
ispyisail
|
5f6e5035f6 |
Add German translations for Tier 2 (Engagement) pages
- features-DE.md: Complete German translation of Features page (345 lines) covering all QET capabilities, professional documentation, export options, real-world use cases, and industry support - community-DE.md: Full German translation of Community page (339 lines) with contribution pathways, community resources, governance, and recognition for contributors - tips_and_tricks-DE.md: Comprehensive German translation of Tips & Tricks page (510 lines) with advanced workflows, performance optimization, collaboration strategies, and industry-specific patterns - languages.md: Updated translation status showing all Tier 2 pages now complete in all three languages (English ✅, Français ✅, Deutsch ✅) Tier 1 + Tier 2 now fully translated to German and French (8 complete pages per language). Multi-language wiki expansion complete for onboarding and engagement tiers. |
||
|
ispyisail
|
2c020ec514 |
Add French translations for Tier 2 (Engagement) pages
- features-FR.md: Comprehensive French translation of Features page (345 lines) covering all QET capabilities, professional documentation, export options, standards support, and real-world use cases
- community-FR.md: Complete French translation of Community page (339 lines) with ways to get involved, community resources, contribution guidelines, and recognition
- tips_and_tricks-FR.md: Full French translation of Tips & Tricks page (510 lines) with advanced workflows, performance optimization, collaboration strategies, and industry-specific patterns
- languages.md: Updated translation status showing Tier 2 French translations complete (Features, Community, Tips & Tricks all ✅ for Français)
Expands French documentation to 8 complete pages across Tier 1 (Onboarding) and Tier 2 (Engagement) tiers.
|
||
|
ispyisail
|
0dcaba5602 |
Add User Manual translations for French and German
- user_manual-FR.md: Complete French translation of User Manual (646 lines) covering all topics from basics through advanced features, keyboard shortcuts, and troubleshooting - user_manual-DE.md: Complete German translation of User Manual with same comprehensive coverage as English original - languages.md: Updated translation status matrix showing User Manual now complete in all three languages (English, Français, Deutsch) Expands multi-language onboarding tier to 4 complete pages (Home, Quick Start, Downloads, FAQ, User Manual) in all three languages. |
||
|
ispyisail
|
43cdce921e |
Add German translations for Downloads and FAQ pages
- downloads-DE.md: Complete German translation of Downloads page with platform-specific installation instructions (Windows, macOS, Linux) and troubleshooting - faq-DE.md: Comprehensive German FAQ covering installation, getting started, creating/saving diagrams, project organization, and elements/libraries - languages.md: Updated translation status matrix showing Downloads and FAQ now complete for all three languages (English, Français, Deutsch) Completes Option A expansion of multi-language support for QET wiki. |
||
|
ispyisail
|
52c1c5f03d |
Add French translations for Downloads and FAQ
New Pages: 1. downloads-FR.md (French Downloads page) - Complete French translation of Downloads page - Installation instructions for all platforms (Windows, macOS, Linux) - System requirements in French - First-run instructions - Troubleshooting section - Keeping updated and uninstall instructions - ~400 lines of comprehensive French content 2. faq-FR.md (French FAQ) - Complete French translation of FAQ - 50+ Q&A in French - Covers installation, getting started, creating diagrams - Project management and sharing - Elements and libraries - Common questions about file formats and export - Community support links Updates: - languages.md: Updated translation status matrix * Downloads: English ✅ | Français ✅ | Deutsch 🔄 (in progress) * FAQ: English ✅ | Français ✅ | Deutsch 🔄 (in progress) * User Manual: English ✅ | Français 📋 | Deutsch 📋 (planned) Current Translation Status: - English: ✅ Complete (all 15+ pages) - French: ✅ 4 pages (Home, Quick Start, Downloads, FAQ) - German: ✅ 2 pages (Home, Quick Start) | 🔄 In progress (Downloads, FAQ) Next: User Manual translations (all languages), then evaluate additional pages Note: German translations for Downloads and FAQ are ready for implementation. German translators welcome to contribute! Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb |
||
|
ispyisail
|
49bac3dc7b |
Add German translations for Home and Quick Start Guide
New Pages: 1. Home-DE.md (German Home page / Deutschsprachige Startseite) - Complete German translation of Home page - Erste Schritte (Getting Started) in German - Documentation links in German - Entwicklung (Development) section - Quick reference table in German - Language selector at bottom 2. quick_start_guide-DE.md (German Quick Start Guide / Deutsche Schnellstartanleitung) - Complete German translation of Quick Start Guide - Schritt-für-Schritt Anleitung in German - 10-Minuten Tutorial für Anfänger - Platform-specific instructions (Windows, macOS, Linux) in German - Common tasks and troubleshooting in German - Full feature coverage Updates: - languages.md: Updated translation status matrix * Home: English ✅ | Français ✅ | Deutsch ✅ * Quick Start: English ✅ | Français ✅ | Deutsch ✅ * Added note about German translations available * Removed 'Coming soon' for German Current Translation Status: - English: ✅ Complete (all pages) - French: ✅ Complete (Home, Quick Start) - German: ✅ Complete (Home, Quick Start) Next steps: Additional French/German pages as community contributes Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb |
||
|
ispyisail
|
009c7f1bca |
Add French translations and Language Hub
New Pages: 1. Home-FR.md (French Home page) - Complete French translation of Home page - Navigation links to French content - References to Getting Started, Documentation, Development - Quick reference table in French 2. quick_start_guide-FR.md (French Quick Start Guide) - Complete French translation of Quick Start Guide - Step-by-step instructions in French - 10-minute tutorial for beginners - Platform-specific instructions (Windows, macOS, Linux) - Common tasks and troubleshooting in French 3. languages.md (Language Hub) - Centralized language selection page - Navigation for English, French, and German - Translation status matrix showing progress - Call for translators and contribution guidelines - Language-specific resources and forums - Quality standards for translations Updates: - Home.md: Added language selector link at top - _Sidebar.md: Added Languages page link under Getting Started Translation Status: - English: ✅ Complete (all 15 pages) - French: ✅ Started (Home, Quick Start) - German: 📋 Planned (coming soon) Note: This creates the foundation for multi-language support. Future work: German translations, additional French pages. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb |