Don't mix UI with technical jargon #207

New issue

Open

opened 2022-08-06 18:11:23 +00:00 by ilja · 1 comment

ilja commented

2022-08-06 18:11:23 +00:00

Member

This came up when talking to @fristi

On the one hand we have technical terms, like the name of a module. On the other hand you have settings where you activate said module. Currently admin-fe uses the name of the modules instead of a more human friendly name/description.

This should be improved so that it's more clear what each setting does and what it's about. Terms that are used should be widely known and accepted by end-users. E.g. We shouldn't talk about "status" and "activity". "post" is now the most universally accepted word for a regular message on the timeline.

This came up when talking to @fristi On the one hand we have technical terms, like the name of a module. On the other hand you have settings where you activate said module. Currently admin-fe uses the name of the modules instead of a more human friendly name/description. This should be improved so that it's more clear what each setting does and what it's about. Terms that are used should be widely known and accepted by end-users. E.g. We shouldn't talk about "status" and "activity". "post" is now the most universally accepted word for a regular message on the timeline.

fristi commented

2022-08-11 20:39:09 +00:00

Member

To further elaborate on what I spoke about with @ilja ,

One of the main problems I was facing with writing translations is that pleroma-fe, and to an extend admin-fe, tend to mix up various terminology for similar things. Sometimes rightly so, but usually it's not needed. One of the more notorious examples is how posts seem to be described with no less than 4 synonyms; "post", "message", "status", and on occasion even "activity". This is confusing to the end-user, as they will wonder if these are 4 different things. This was especially troublesome when translating, as for instance in dutch some of these words make no sense, or have no direct translation.

Thus my solution so far has been to categorize if a particular context requires technical jargon or not. In pleroma-fe, it's usually not recommended, and it is there that I've opted to translate things to more user-friendly synonyms. The above mentioned synonyms for posts have all been translated as "Bericht" (literally Message) because it makes sense there. Technical jargon like status and activity have only been literally translated in areas normally seen by an admin, who I would think has at least minimal understanding of these terms and how they differ.

tl;dr for frontend translations, try to stick to consistent terminology and try not to use technical jargon that would be confusing for end-users.

P.S. on another issue, @ilja also noted to me about a certain difficulty naming something in regards to regular posts and chat messages from the pleroma chat system. I would say this is also an example of naming difficulties and perhaps inconsistent use of terminology within pleroma, where posts and messages may be confused with each other by the end user. In this particular case I suggested to try to separate these systems more to make it clearer where their differences lie, however whatever solution is chosen, I think most important is to at least remain consistent. Even in non-ideal circumstances, end-users can learn what is what if the terms used in the software remain consistent.

To further elaborate on what I spoke about with @ilja , One of the main problems I was facing with writing translations is that pleroma-fe, and to an extend admin-fe, tend to mix up various terminology for similar things. Sometimes rightly so, but usually it's not needed. One of the more notorious examples is how posts seem to be described with no less than 4 synonyms; "post", "message", "status", and on occasion even "activity". This is confusing to the end-user, as they will wonder if these are 4 different things. This was especially troublesome when translating, as for instance in dutch some of these words make no sense, or have no direct translation. Thus my solution so far has been to categorize if a particular context requires technical jargon or not. In pleroma-fe, it's usually not recommended, and it is there that I've opted to translate things to more user-friendly synonyms. The above mentioned synonyms for posts have all been translated as "Bericht" (literally Message) because it makes sense there. Technical jargon like status and activity have only been literally translated in areas normally seen by an admin, who I would think has at least minimal understanding of these terms and how they differ. tl;dr for frontend translations, try to stick to consistent terminology and try not to use technical jargon that would be confusing for end-users. ---- P.S. on another issue, @ilja also noted to me about a certain difficulty naming something in regards to regular posts and chat messages from the pleroma chat system. I would say this is also an example of naming difficulties and perhaps inconsistent use of terminology within pleroma, where posts and messages may be confused with each other by the end user. In this particular case I suggested to try to separate these systems more to make it clearer where their differences lie, however whatever solution is chosen, I think most important is to at least remain consistent. Even in non-ideal circumstances, end-users can learn what is what if the terms used in the software remain consistent.