Verify the forum's wire-label-printing workflow and document it properly
The user pointed at forum mentions of a "wire printing feature" -- checked
the actual QET forum (viewtopic.php?id=1496, "Discussion sur la liste des
fileries") rather than re-grepping source, since that's a source of truth
grep can't see. It confirms the earlier correction rather than
contradicting it: QET has no built-in wire-marker/ferrule label printer.
What the forum actually discusses is exporting the wiring list as CSV
(Joshua's own words, quoted on the thread: "Project menu -> export the
list of conductor names") and feeding it into a label printer's own
software -- Brady, WAGO Smart-Printer, Phoenix Contact tools, and Cembre's
SW-code/.FNR system were all named. A professional panel builder reported
the export lacks quantity consolidation (duplicate rows instead of one row
with a count), costing him real time on a large job.
Verified the exact menu wording against source rather than trusting the
forum's paraphrase: qetdiagrameditor.cpp's Project menu has "Exporter la
liste des noms de conducteurs" (-> ConductorNumExport, the CLI's
--export-wires) and "Exporter le plan de câblage" (-> WiringListExport,
the CLI's --export-cables/--export-wiring) -- so the GUI menu items and
the CLI verbs already documented in api_reference are the same underlying
export, not two different things.
Enriches api_reference (EN/FR/DE) with this as a "Worth knowing" bullet:
the real menu names, the real printer brands people actually feed this
into, and the verified duplicate-row limitation. Tightens the
user_manual.md printing-diagrams note (which already correctly said QET
has no such feature) to point here for the concrete workflow instead of
just gesturing at "an external tool."
Correct the automation docs: QET has no Python scripting and no plugins
api_reference stated "QElectroTech supports Python scripting" and
"QElectroTech supports plugins for deep integration", and told readers to
install plugins into ~/.local/share/QElectroTech/plugins/ and platform
equivalents. None of it exists: there is no QPluginLoader anywhere in
sources/, no plugin ABI, and every Python reference in the tree is the
launcher for qet_tb_generator -- a separate PyPI program QET starts as an
ordinary child process. QET never reads those plugin paths.
cli_reference had the mirror-image error, calling the shipped headless
export "Future CLI Features (QET 2.0)" and sending readers to the
scripting that does not exist. The FR/DE CLI pages additionally invented
a --dpi option and QET_PLUGIN_PATH / QET_ELEMENT_PATH, and documented an
argument order the parser cannot accept.
Rewrites api_reference (EN/FR/DE) around what is actually there: the 13
CLI verbs with their real positional syntax and exit codes, the real .qet
and .elmt XML (the old skeletons were invented -- no <diagrams> wrapper,
element has no id, uuid is an attribute), qet_tb_generator, and the C++
source. Adds a section naming what does not exist, so the claim does not
come back.
Also corrects the same claims where they had spread: features, history,
faq, user_manual (EN/FR/DE) and the sidebar.
Add French and German translations for API Reference
- api_reference-FR.md: Complete French translation of API Reference guide covering scripting (Python), plugins, XML manipulation, and developer resources
- api_reference-DE.md: Full German translation with identical comprehensive coverage
Tier 3 progress: 6 of 8 developer pages now complete (Contributing, Building, API Reference in FR/DE)