Now all escaping required for the C++ code generation is done when the
.cpp/.h files are generated. Previously, only newlines were escaped
automatically. This was a) inconsistent and b) leaked c++ details into
the xml data.
In addition, the escaping is now done in one central place, harmonizing
the three previous implementations.
Pre-existing c++ escape sequences in the XML files have been replaced by
their literal equivalent so that the resulting python doc sting remains
unchanged.
* [Base] Add hasExtension for multiple values
* [Gui] Use hasExtension for multiple values
* [Drawing] Use hasExtension for multiple values
* [Fem] Use hasExtension for multiple values
* [Import] Use hasExtension for multiple values
* [Mesh] Use hasExtension for multiple values
* [Part] Use hasExtension for multiple values
* [TechDraw] Use hasExtension for multiple values
===============================================
With the new console extension, the translation state is coded separatedly.
Therefore, it is possible to code a Notification as translated without needing a specific type.
Additionally, any other message, such as Error of Warning can be translated.
It does not make sense to leave this message, if only for reasons of coherence and to simplify
maintainance of code.
==================================================================================
Limitations of the current framework:
- Codes the translated state only for TranslatedNotification as part of the type.
- Does not code the intended recipient (user, developer, ...)
Problems:
- Some errors are intended for developers, some errors may only be intended for users,
if, for example, there is another developer error which already contains all the information.
The current framework may lead to information duplication or to showing to the user developer
information, which is perceived as annoying.
- Logs shall be in English (report view), while every message to the user (UI) shall be translated.
The current framework can only differentiate where to report based on subscription (legacy logs do not
subscribe to notifications), and for notifications, whether it is translated or not depends on the type.
It is not possible to code errors or warnings that are already translated.
Solution:
- To extend the ILogger interface with additional metainformation, indicating the intended recipient
(User, Developer, All), and the content of the message (translated, untranslated, untranslatable). The latter
is useful for dynamic strings that won't find a match in the translation framework.
Bonus:
- This extended version allows to do away with translatednotification, as now any message can be independently
marked as translated or untranslated or untraslatable.
- It is now possible to provide the right icon of severity (error, warning, info), even when it is only user intended
and already translated.
