feat: add tray menu localization using system locale #446
Conversation
af786c1 to
9cd869b
Compare
|
ah nice i was going to do this in a second pass on localization so thank you only request is don't add a new dep and instead use tauri-os built in https://docs.rs/tauri-plugin-os/latest/tauri_plugin_os/fn.locale.html it would be good if it didn't require an app restart, but its okay for now. there might be a function already to refresh the tray, so that might need to be run when the setting changes |
69b288d to
571b24e
Compare
- add tray_i18n.rs module for tray menu translations - load translations from shared frontend JSON files at compile time - support 7 languages: en, es, fr, vi, de, ja, zh - add tray section to de, ja, zh translation files - use tauri-plugin-os::locale() for system locale detection - add refresh_tray_locale command for live tray updates - update AppLanguageSelector to refresh tray on language change - tray menu now updates immediately when app language changes - remove CLAUDE.md from repository
571b24e to
62cbe71
Compare
done! now using
i looked into this and also managed to refresh the cart on lang change, the function helped also added tray translations for german, japanese, and chinese (the new languages from #444) |
src-tauri/src/tray_i18n.rs
Outdated
| "vi" => "../../src/i18n/locales/vi/translation.json", | ||
| "de" => "../../src/i18n/locales/de/translation.json", | ||
| "ja" => "../../src/i18n/locales/ja/translation.json", | ||
| "zh" => "../../src/i18n/locales/zh/translation.json", |
There was a problem hiding this comment.
This mapping feels like it should not be hardcoded and should be imported from a config file or inferred from file paths?
Ignore me if there's a good reason for not doing this tho.
There was a problem hiding this comment.
As in... the need to say
//! NOTE: When adding a new language to the frontend (src/i18n/locales/),
//! remember to also add it to the load_translations! macro below.
feels like a smell here?
There was a problem hiding this comment.
the constraint here is rust's include_str! macro - it requires compile-time string literals, so there's no way to dynamically discover files without either~
- a build.rs script that scans the locales directory and generates the mapping
- a procedural macro that reads the filesystem at compile time
both add complexity that felt like overkill for just seven languages. the explicit list has the benefit of compile-time safety (missing file equals build error) and the NOTE comment documents the manual step
There was a problem hiding this comment.
I think build.rs script might be most appropriate just to reduce complications for new contributors. It would probably be a write once and forget about it forever piece of code which is probably a good thing. I don't think a comment is sufficient for new contributors if they haven't read the code at all. This either needs to be documented in a README or similar, or some alternative approach.
I'll have a think about the best way to approach this problem as well
There was a problem hiding this comment.
i can get a start on build.rs and push it in in a sec
There was a problem hiding this comment.
added -- let me know if this works!
|
Note to self for when I'm on a machine where I can build/run this:
|
|
Another misc comment is we almost certainly need to have a setting for the UI language to be persisted in the settings file itself. I believe right now it's a local-storage value in the browser (which is definitely a hack imo). We probably should remove that in favor of a json stored string, so that the backend and frontend can both have a good source of truth for the language. In regards to the auto detection of the language, I'm not 100% the best way of going about that. Since it would either need an 'auto' setting itself, or something like |
|
@VirenMohindra when/if you get a chance can you merge with main, I took care of the using the settings file. There should be an appropriate setting to be able to pull from on the rust side. Would guess it will even clean up the implementation a bit |
yeah thank you! will do right now. the build.rs implementation took a bit and wanted to land that to get some eyes on it before pinging ya |
|
thank you! no worries, just excited to get this one in :) |
- build.rs scans src/i18n/locales at compile time - struct fields derived from english json keys (camelCase → snake_case) - languages auto-discovered, no code changes needed for new locales - locales without "tray" section are skipped gracefully addresses review feedback on pr cjpais#446
summary
technical details
build.rsauto-generates tray translations at compile time from frontend locale filessrc/i18n/locales/directory - no code changes needed for new localestauri-plugin-os::locale()for os locale detectiontest plan