Add Support for Error Message Translations in Different Languages

[DanielSurf10]

Description:

Currently, Norminette provides code norm error checking for C, but the error messages are only available in English. This proposal aims to enhance the accessibility and usability of the project, allowing users who do not speak English to understand and address issues identified by the tool.

Proposed Implementation:

Introduce support for error and warning message translations in different languages, using dedicated JSON files for each supported language. This flexible approach allows future expansion to other languages, making Norminette more inclusive.

Suggested Steps:

1. JSON File Structure:

• Create JSON files for each supported language.
• Each file should map error codes to their respective translated messages.

Example (file en_us.json):

{
    "SPC_INSTEAD_TAB": "Spaces at beginning of line",
    "TAB_INSTEAD_SPC": "Found tab when expecting space"
    // ... other messages ...
}

2. Norminette Modification:

• Modify the Norminette code to read messages from the corresponding JSON file based on the configured language or use the default messages.

3. Language Configuration:

• Add configuration options to allow users to choose their desired language.

Example:

norminette --language=en_us file.c

Or find a way to make it persistent without needed the flag --language=en_us.

Adicional context

I've created a reference implementation available here #450. However, I'm facing challenges in determining the precise location to insert the new files—the JSON files and configuration files (for testing, I placed them in "~/.local/share/norminette/en_us.json")—and how to seamlessly integrate this functionality into the existing Norminette workflow.

I am willing to collaborate to ensure a smooth integration of this feature.

Thank you for your attention and consideration of this proposal. I look forward to feedback and guidance on how to proceed with the implementation.

[NiumXp]

Hello, @DanielSurf10!

Instead of using JSON (which is not appropriate for I18N), why not use the built-in library gettext?

[DanielSurf10]

Hello, @NiumXp!

Thank you for your feedback! I appreciate your suggestion to use gettext for internationalization. At the time of implementation, JSON seemed like the closest and easiest option for me to integrate. However, I value your recommendation, and I'll certainly consider refactoring the implementation to incorporate the gettext library for a more robust I18N solution. Your insights are invaluable, and I'm open to enhancing the project accordingly. Thanks again!