Open ninavizz opened 3 years ago
Took me a moment to realize you were not talking about internal message passing :rofl:.
Trying to understand what this means. Is the result supposed to be a giant list of text strings? Is it only the text that appears in a dialog box (or similar), not just all the text the user sees in the OS (e.g., in config panels)?
Took me a moment to realize you were not talking about internal message passing .
I think this is because of the phrase "system-level," which usually describes the low-level internals of the system.
I have no doubt this will not be an easy thing to tackle for Qubes, mostly because it is a Linux system that can use any number of distros, desktop environments, software applications, and whatever else may spawn system-level messages.
Out of curiosity, what would be the point of documenting non-Qubes text if we can't change it (or would be unwilling to do so, e.g., because it would require us to maintain our own fork)? In any case, perhaps we should just start with Qubes-specific text first.
@andrewdavidwong I made this issue cuz you suggested I do as much in 2019, lol. My intent with this issue, is to log any text that is included in a status, alert, success, or error or "toast" message. Not the actual text within dialog boxes that says "Hey, would you like to do x?"
Agreed, no need to audit the messaging that is built into other distros or apps. I do not know what is unique to Qubes and what is from other projects, however. Mostly only created this issue to take the next steps needed for #4532, as I was poking through UX issues earlier today to try to see where design or research activities are needed.
@andrewdavidwong I made this issue cuz you suggested I do as much in 2019, lol.
Oh. 😂
As you may have noticed, I have a terrible memory.
My intent with this issue, is to log any text that is included in a status, alert, success, or error or "toast" message. Not the actual text within dialog boxes that says "Hey, would you like to do x?"
Gotcha.
Agreed, no need to audit the messaging that is built into other distros or apps. I do not know what is unique to Qubes and what is from other projects, however.
That's fine. I'm sure I and others can help to point that out.
I generally know which components are ours and which are from upstream, but I don't know in exactly which files in exactly which repos each of our text strings lives. I'm guessing it's scattered throughout the source code. Since you likely care mainly about manager/widget messages, perhaps @marmarta could help? (I would also like to know so I can submit PRs for language improvements.)
Mostly only created this issue to take the next steps needed for #4532, as I was poking through UX issues earlier today to try to see where design or research activities are needed.
Sounds good.
From @marmarta in #5525
Unfortunately there's no single file for (toast messages) - they are basically in https://github.com/QubesOS/qubes-desktop-linux-manager/tree/master/qui , scattered in various files, findable through:
- emit_notification or send_notification functions
- self.notify in the clipboard.py widget
findable through:
- emit_notification or send_notification functions
- self.notify in the clipboard.py widget
Hm, I'm not familiar with this. I wonder how hard it would be (e.g., whether it requires a dedicated Qubes OS dev environment).
Might just have better luck combing through https://github.com/QubesOS/qubes-desktop-linux-manager/tree/master/qui and visually finding the English strings while ignoring the Python code.
Affected component(s) or functionality (if applicable) All messages
Brief summary In order to shape accurate, clear, plain-language, and easy to understand messages for users to be guided by in Qubes, we need a central human-consumable place for all that messaging to be documented. Likewise, I suspect such an artifact would help in translations.
Additional context As a first step towards resolving #4532, this is needed for error messages.
All messages spawned by actions initiated in the AppMenu, Qube Manager, the Updater, Split GPG, Device Manager, Policy Manager, Print Manager (CUPS?), etc., should live in such
I have no doubt this will not be an easy thing to tackle for Qubes, mostly because it is a Linux system that can use any number of distros, desktop environments, software applications, and whatever else may spawn system-level messages.
Windows and MacOS are walled garden experiences, which sucks on a number of ethical levels and makes for far easier security exploits—but doggone it makes tasks like this exponentially easier.
Relevant documentation you've consulted Nope, this is just a ux best practice for software teams. :)