MSC4270: Matrix Glossary #4270
MSC4270: Matrix Glossary #4270
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- None feasible
| * UK English | ||
| * US English (where different from UK English) | ||
| * French | ||
| * German |
There was a problem hiding this comment.
this list is very much an open question
There was a problem hiding this comment.
Maybe the selection could be supported by usage statistics from clients (where those exist)?
| * French | ||
| * German | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
The SCT not having native speakers for all supported languages creates the risk of low-quality or, though less likely, harmful translations creeping in. I think this proposal should provide more detail around how the SCT will prevent this. Paid translation services alone don't feel like a great solution because those will most likely not have any understanding of Matrix technicalities. Maybe we could use trusted native community members or a community voting scheme for reviewing the translations.
There was a problem hiding this comment.
Given updates to translations would need to be done via MSCs, i'd have thought we can require that FCP will only pass once a trusted reviewer who natively speaks the language has signed it off. Trust could mean professional translator, or a community member who's accrued trust, etc.
| * To define words, phrases, and terminology that implementations SHOULD use to provide consistent | ||
| user experience, especially when users are switching between implementations. |
There was a problem hiding this comment.
It might be helpful to clarify whether this includes only end users or everyone interfacing with an implementation (such as server admins). I suppose "user" here is meant to be user as defined in the glossary itself?
|
|
||
| ## Proposal | ||
|
|
||
| A new specification document titled "Glossary" is established, residing next to or near the existing |
There was a problem hiding this comment.
I think the term "glossary" doesn't make it clear enough that these terms are supposed to be used in a client's UI – especially because the spec currently contains mostly technical requirements and only very few things that impact UI or UX. As somebody implementing the spec I might mistake this section as something that is supposed to help me understand the spec and neglect it. Maybe "End user glossary" or something similar would be better?
There was a problem hiding this comment.
Tbh reading this so far i assumed that this is going to just be an appendix in spec for the words used in spec... I never even assumed this would be about enduser communication 🤔 so imho its definetly not clear if it is enduser (aka client user, sdk user,...) or people directly implementing from spec (devs building an sdk, writing a hs or similar)
There was a problem hiding this comment.
yeah, agreed. I wonder if this whole thing should be renamed "Consistent user-facing terminology" to make it clear on what we're trying to solve? It then means that encryption-specific terminology as per #4161 will also be less out of place.
There was a problem hiding this comment.
The key thing being that we're trying to define consistent terms so that if users mix clients, they don't get completely lost (how come fluffychat is prompting me to enter a security code, but element x is prompting me to enter a recovery passphrase? or whatever)
There was a problem hiding this comment.
This sounds better than "glossary" to me. 👍
It'll require two lines in the menu .. but I'm not sure that really matters.
Rendered
I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published with my role as a member of the SCT.