The short descriptions task is basically complete.
Please provide feedback on my suggestions.
IMO, short descriptions are a task very suited for Promo to make applications more attractive, so feedback on this "marketing" should help as well.

KDiff3 and Kompare have the same short description because they overlap a lot.

I would say other changes are questionable too: Personal Finance Manager for KMyMoney is appropriate, for example. In general, IMHO, the short description is not the place where to showcase capabilities.It is what happens in the menus. Features are showcased by the longer description metadata from the software center, unless you want to make the default menus too long.

It's a delicate balance. You want the short name to us useful and not totally generic, or else it doesn't have much value. But as @ltoscano says, it also can't be too long.

I think the general goal of this task is good, but some of the proposals are too long--as are some of the existing ones. At the minimum, would recommend remove filler terms like "simple", "user-friendly", "advanced" etc. These don't communicate anything.

I agree that KMyMoney's existing short description is probably fine. But I like your idea of mentioning that Skrooge offers double-entry bookkeeping as a way to differentiate it from KMyMoney though.

As an end-user, I usually get frustrated when I search for a tool on Discover and most results do not differ significantly either by name or description due to how generic they are; that's the case when you want to search for a utility that's available on multiple DEs. You have to click on each instance on Discover and read the long description in order to determine which DE it belongs to. An example of this is when you search for file managers. This is particularly bad with GNOME and GNOME-based (MATE, Cinnamon) applications, while XFCE does it generally well.

I also think a more... descriptive description is more attractive. Say a user needs a tool but is uncertain which to download, so they search through Discover. What would make them interested enough in a KDE application so as to click it instead of the first generic one they encounter?

I think the best is to follow that the specification recommand.

<summary /> A short summary on what this application does, roughly equivalent to the Comment field of the accompanying .desktop file of the application.

https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html#tag-dapp-summary

Comment: Tooltip for the entry, for example "View sites on the Internet". The value should not be redundant with the values of Name and GenericName.

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys

for kde.org/applications we used X-KDE-GenericName from the desktop file with the comment // FIXME: summary is a bad fit for this as it can be rather long so actually the summary is never displayed and only the generic name.

Thanks for looking at this. Do you have any example patches ready to see if we can get some committed?

So I was taking a look on Invent projects (like kdiff3 and labplot) to see where these short descriptions are stored, since it's a fairly straightforward process to send short, one-file MRs. Am I correct in assuming the changes I must do should be in the GenericName section of the .desktop file and nowhere else?
If so, what happens to the translations? If I just change the original GenericName, will e.g. GenericName[pt_BR] show up as fuzzy for translators?

Yes it should be in the GenericName section, and if you change it all the translations will be fuzzy.

Something important to mention, the short description should be the generic name of the application and should just include that the user is. This information is also available in the launcher and you can search by generic name (very helpful when you don't know the brand name of all the applications.

So instead of saying User-Friendly IRC Client, I would just use IRC Client and in the long description available add more information about what you can do with it.

Also, I wouldn't include user-friendly/simple/frontend/KDE in the description of the applications.

I gave this some more thought and I think I found a fundamental issue with updating these descriptions.

@ltoscano mentioned:

• [Short descriptions are] not the place where to showcase capabilities.
• Features are showcased by the longer description metadata from the software center.

@ltoscano and @ognarb mentioned:

• [Short descriptions are] what happens in the menus.
• [Short descriptions are] also available in the launcher and you can search by generic name

@ngraham and @ognarb mentioned:

• Remove filler terms like "simple", "user-friendly", "advanced"
• I wouldn't include user-friendly/simple/frontend/KDE

There's the XDG specs:

In T12810#223195, @ognarb wrote:

I think the best is to follow that the specification recommand.

<summary /> A short summary on what this application does, roughly equivalent to the Comment field of the accompanying .desktop file of the application.

https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html#tag-dapp-summary

Comment: Tooltip for the entry, for example "View sites on the Internet". The value should not be redundant with the values of Name and GenericName.

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys

for kde.org/applications we used X-KDE-GenericName from the desktop file with the comment // FIXME: summary is a bad fit for this as it can be rather long so actually the summary is never displayed and only the generic name.

And there's stores like Discover:

• I usually get frustrated when I search for a tool on Discover and most results do not differ significantly either by name or description due to how generic they are
• I like the idea of mentioning that Skrooge offers double-entry bookkeeping as a way to differentiate it from KMyMoney

That is, the main issue here is we have two conflicting expectations: the XDG specs for GenericName conflict with how application stores currently make use of it.

Descriptions available through the menu have different use-cases than the store. Typically the user would have only one application already installed to serve a specific purpose, it would be unlikely for them to have both Konversation and Hexchat (both have GenericName="IRC Client") at the same time; XDG covers for such usage. There's no need to promote an application if it's already installed, and thus there's no need for a GenericName longer than 2 or 3 words. Descriptions should only show what they are for, not what they have that others don't.

In a store however that's not the case, if you search for IRC client you'd find several potential IRC clients to install. Imagine if all available irc clients strictly followed the XDG specs without caring to show their capabilities, you'd end up having like 10 irc clients described as IRC Client, it would be useless information to display on the front page of a store to begin with. In addition to being hubs to install applications, they also serve as a means for applications to promote themselves. That is, descriptions may not only show what they are for, but also show what they have that others don't.

So this is a matter of what the standard for the short descriptions should be.
Namely: what's the minimum and maximum of words per description? Should there really be no promotion (showcase of capabilities) of any kind?

In T12810#224120, @jriddell wrote:

Thanks for looking at this. Do you have any example patches ready to see if we can get some committed?

https://invent.kde.org/kde/kamoso/-/merge_requests/2

https://invent.kde.org/kde/labplot/-/merge_requests/10

The GenericName is not displayed in store only the summary in the AppStream file. The fact that the kde.org/applications doesn't use the Summary is because they are mostly too long.

In T12810#228939, @ognarb wrote:

The GenericName is not displayed in store only the summary in the AppStream file. The fact that the kde.org/applications doesn't use the Summary is because they are mostly too long.

I see, so my assumption up there was completely wrong for GenericName, but it might be useful for updating Summary then. Those should be split up tasks as they have different goals.

Separating both tasks makes this one quite shorter I'd say.

I removed the suggestions that had anything to do with promoting the app and which were fine by default according to XDG standards.

I think your proposal for the following GenericName are good: GCompris, LabPlot, K3B, Calligra Sheets, Calligra Stage, KRFB, LSkat, Kollision (but remove the "simple"), Artikulate, Smb4K (but removed the "advanced").