AI ETS project translation preview
The preview shows the project translation workflow: choose a target language, translate labels, review changes and keep rollback available before Control4 export.
Why translation matters in KNX to Control4 work
A valid ETS project can still be difficult for a Control4 installer or client to understand. Room names, device labels and group address patterns may be in German, Spanish, Italian or an installer-specific shorthand.
If those labels are copied directly into Composer, the final project can look unfinished even when the technical mapping is correct. Translation should happen while the KNX source and generated Control4 structure are still easy to compare.
- Client-facing room and device names should match the handover language.
- Installer abbreviations should be expanded before they become Composer devices.
- Technical KNX evidence should remain visible during the naming review.
What should be translated
The platform focuses on labels in the reviewable Control4 structure: project names, rooms, areas, lines and device names. The ETS source remains the reference context; the goal is not to rewrite a commissioned ETS project blindly.
This keeps translation useful but controlled. The installer can compare original KNX naming with the translated Control4 output before the package is exported.
- Project and building labels used in the generated Control4 structure.
- Rooms, lines and areas that need a client-readable naming convention.
- Supported device labels for lights, blinds and gateway context.
- Ambiguous or technical names flagged for manual review instead of silent translation.
Review and rollback before export
AI translation is useful only if the installer can review the result. Bulk translation should be reversible because a single wrong convention can affect many rooms or devices at once.
CoduWorks keeps translation inside the pre-Composer review layer, so the installer can accept, adjust or roll back naming changes before the .codu is produced.
Cleaner Composer handoff
Composer should receive a package with names that are already readable for the project team. That reduces cleanup after creation and avoids rebuilding devices just to fix language or naming inconsistencies.
The .codu remains a reviewed build package: KNX context, generated Control4 structure and translated labels are checked before the driver creates anything.
What translation does not replace
Translation does not validate DPTs, feedback, gateway routing or physical commissioning by itself. Those checks still matter. Translation is one layer of project cleanup, not a substitute for KNX review.
The safest workflow is import, AI processing, mapping review, naming translation, final check and then .codu export for Composer.
Official references checked
Technical claims on this page are kept close to official KNX, Control4, or manufacturer documentation.
Related tools and documentation
FAQ
Can CoduWorks translate a German ETS project before Control4?
Yes. It can translate reviewable project labels such as rooms, lines and device names before export, while keeping the original KNX context visible for checking.
Does translation change the original ETS project?
No. The workflow uses ETS as the source context and prepares translated labels for the Control4 structure before the .codu export.
Can translation be rolled back?
Yes. Translation belongs in the review layer, so the installer can review and roll back changes before Composer receives the package.
Should group address technical meaning be translated automatically?
Not blindly. Technical labels should remain traceable to the KNX source, and ambiguous names should be reviewed manually before export.
Translate names before Composer
Upload the .knxproj, process the KNX project with AI, translate the generated labels and export .codu only after review.