feat: add internationalization support and shell configuration UI #300
Conversation
|
- Introduce internationalization (i18n) infrastructure: - Add i18n scaffolding and translation resource loading utilities. - Provide runtime locale detection and a language switcher component. - Wire common UI strings through translation keys to enable multi-language support. - Add configuration UI for the shell: - New settings panel to configure shell preferences (appearance, behavior, and locale). - Persist user preferences and apply them at runtime. - Accessible, responsive controls integrated into the shell UI. - Implementation details: - Register i18n provider at the app root and update components to use localized strings. - Add helper functions for retrieving and updating locale and other settings. - Include basic tests and example translation resources to validate integration. - Notes: - No breaking changes to existing public APIs. - Future work: expand translation coverage, add additional locales, and refine UX for preference syncing.
|
Thanks! I'm busy working on another project so it might take a few days for me to review this PR. |
|
Is the work done by LLMs, btw? |
|
Yes, you can go through the process I did on my repo. Since C and C++ side is way out of my league. |
Can you fix the three points I mentioned? |
|
@std-microblock I am not able to find your comments? Can you guide me where to find it? |
It's here
|
What the hell is github upto I can't seem to find it!!!
|
There was a problem hiding this comment.
It's weird to extract the i18n file every time into the disk. If it's not configurable, why don't load it in-memory? If not, why override it every time?
There was a problem hiding this comment.
More of a short tearm approach since I though if i18n to be vaible for this project it will be required to move into a seperate repo as most project do for multi-language support to their apps. That will requires dropdowns and other things in UI for both config and the main breeze app. Also this helps a user to play with the translations present in the config folder, future scope should be extract only the required language, in memory or disk to keeps things less cluttered on the user end
|
what about now |
Thanks now it is here!
|
Replace the JSON parsing backend from yyjson to reflect-cpp (rfl) for locale file handling, simplifying the codebase with better type safety and more ergonomic API. Changes: - Introduce LocaleFile and LocaleMetadata structures with rfl annotations for declarative JSON parsing in i18n_manager.cc - Migrate load_locale() and load_plugin_locales() to use rfl::json::read with improved error messages and validation - Add js_traits specializations for std::map and std::unordered_map in quickjspp.hpp to support generic map conversions - Remove custom map<string, Value> traits from binding_qjs.h (now handled by generic quickjspp.hpp traits) - Remove yyjson dependency from xmake.lua - Clean up config_page exports by removing unused languages identifier The new reflect-cpp approach provides compile-time type checking and reduces boilerplate while maintaining all existing security checks (path validation, canonicalization) and plugin key override protection.
2 participants
Introduce internationalization (i18n) infrastructure:
Add configuration UI for the shell:
Implementation details:
Notes:
Allow english translation #299