More efficient translations in small communities

[Marc4]

I think that small communities, with few translation resources, should have some way to prioritize certain plugins and themes.

I know that the ranking of plugins and themes exists, but I think it shows global data. Without data to back this up, I think the results would be different for each local community.

A couple of ideas:

1. Have a top 100/200 ranking based on the downloaded packages of themes and plugins for each local community, instead of using the global one on all sites.

What it solves: It would allow more efficient translations. With the same amount of time and effort on the part of the translators, a greater number of people will benefit.

2. A voting/request system that allows users to request the translation of a theme or plugin, creating a list ordered by votes/requests that can be consulted by community translators.

What it solves: This would still be more efficient than point 1 but I don't know to what extent people might or might not get involved in making these requests.

Why do this?

There are plugins in the top 10, 25 or 50 that are technical. It is possible that the technical profile that installs these plugins can work with them in English, since the documentation is generally in English and the developers "are used to it".

However, there are plugins or themes that are more focused on a less technical and less experienced audience, and I think that perhaps they should have priority in terms of translation in small communities.

It's just an idea, what do you think?

[tobifjellner]

I support an idea of adding manual comments/exclusions to the most popular list.
Another case where it might be useful to have possibility to adjust these lists: some plugins/themes actually don't even use the translations from translate.wordpress.org, at least for some locales.

But splitting the data per locale would create a need to maintain a huge number of additional datapoints, without adding much value. The installation counts just based on calls to the update API, and many installations won't be seen there, if they use other ways of keeping the sites updated.

[irinashl]

Great offer. But increase the number to 300-400.

[psmits1567]

I think categorising projects would be the first start. That would possibly mean that during import of projects a category needs to be provided. Now it is one big list of top 500 projects, but they are not categorised. Also most of the translators start because they found a usable project for there site, but it appears not to be translated. So a voting option with numbers might also make more clear which project needs to be translated first.

[Marc4]

Stats Priority

[Marc4]

Looking at the ranking I see that there are 452 plugins and 394 themes, does anyone know why the amounts are different? or why there is no round number?

@tobifjellner If manual comments/exclusions were added, which roles could do it, GTE?

@psmits1567 What do you mean by categorize? Can you give an example?

Voting system

I guess this could be made as complex and pretty as you like. However, a voting system in small communities that are not capable of completing the top 100, 200 or 500 may not have enough people to interact with the system either? I'm wrong?

This could be the best option, but that ranking should be given more prominence so that people with less experience can interact with the voting system.

I also think it would be ideal because the users themselves would decide which plugin or theme should have priority, and it would be the best reflection of people's real needs.

Simple option

I think an easy way to do it would be to add a new column to the current ranking, the priority column. This would not modify the current system excessively and it could continue to be ordered by the rest of the current options. (Attached example screenshot).

The question is who sets these priorities, the GTE team or the users?

GTE: It would be faster to implement because it requires few changes, but what would a GTE be based on to decide which plugins/themes should or shouldn't have priority? Does it make sense if we want the ordering of priorities to be a reflection of the real need of the local community?

It must also be taken into account that even in small communities, GTE is sometimes absent or has little availability.

Users: This brings us back to a voting system where users can push which plugins/themes they want to have priority.

I think a voting system with a bunch of people voting on which plugin they want translated first sounds good, but in small communities it might be not realistic.

What do you think?

[psmits1567]

@Marc4 with categorising I mean that you give a type to the project like "realestate", "automotive", "membership". It would require definition of a list to pick from.

With voting you do have an impression even in small communities. If no one bothers to vote, then it seems not to be that important. If implemented it should be prominent visible that this will help speeding up approval.

A GTE should not be the person to decide which project gets priority. To be able to do that he/she must be working in a company that deals with WordPress installations and knows which projects are commonly installed. But even then you would have the risc that a GTE prefers a project above one that is voted for.

[tobifjellner]

does anyone know why the amounts are different? or why there is no round number?

As far as I know, the initial query grabs a bigger number of items. But then some projects won't be shown for some reasons (like "not prepared for translation", etc.).

If manual comments/exclusions were added, which roles could do it, GTE?

GTE (or global mentor) would be a good choice. Nothing of this is programmed yet, but I have a feeling that trying to add "voting" and input "from anyone" may add too much complexity and gamification. (What if a plugin owner asks its users to "go and vote", trying to play the system?)

I think it would be useful, though, to have a two-layered approach, where adjustments could be made per locale, or globally, for all languages.

Still, as I think about this, my feeling is that it could be a worthwhile project if we figure out how to do it with minimal effort. We have a lot of more important things waiting for years. :)

By the way, @Marc4 if you would be able to join, we may briefly comment about this ticket in the Polyglots meeting today (Wednesday July 5) at 13:00 UTC, on Slack.

[Marc4]

@tobifjellner

The installation counts just based on calls to the update API, and many installations won't be seen there, if they use other ways of keeping the sites updated.

This would prevent test installations from being counted. The problem is that some plugins/themes are updated once a year and others several times a month. So relying on that alone would be a problem. Another thing would be to expand the data sources.

What if a plugin owner asks its users to "go and vote", trying to play the system?

Perhaps this could be a solution rather than a problem? This could be a valuable source of community feedback data, since if a plugin/theme has the ability to mobilize people to request a translation it is a perfect reflection that that plugin/theme is interesting for the people.

Also, this is already allowed today by plugin/theme creators who ask for star ratings on their plugins/themes. You could encourage to do the same "Do you like this plugin/theme? Would you like to use it in your language? Then ask for the translation here".

---

Voting system

• Implementation: medium/complex?
• Gaming the system ("many" people decide).
• Data accuracy: high.
• Community opinion: high ("many" people decide).
• Recursion/maintenance: low/medium

Roles

• Implementation: simple
• System gaming (few people decide).
• Data accuracy: based on the experience of these roles.
• Community opinion: medium/low (few people decide).
• Recursion/maintenance: high

It might be the easiest thing to implement. If there are doubts that certain roles can "game the system", as @psmits1567 said, or that it is a reflection of the community, perhaps the number of people who decide could be increased. GTE + PTE?

In the end this would still be a small scale voting, maybe instead of wordpress.org on Slack, but it also requires personal resources to manage it and must be repeated over time.

Language packages

• Implementation: medium/complex?
• Gaming the system: less probabilities.
• Data accuracy: depends on the amount of data points, currently low (updates).
• Community opinion: depends, with enough data points it could be high.
• Recursion/maintenance: low/medium

Increasing the data points extracted from the language packs could be an intermediate option? Less complex than a voting system and more accurate than a few people's choice? The problem here is how to do the "curation". Example: do not prioritize technical plugins.

---

How could we find a balance between these options?