Add new sorting filters to Plugins tab in the Translate WordPress dashboard

[YordanSoares]

Currently available filters for plugins and themes

The two tabs with the most translation projects on the translation platform dashboard (Translate WordPress), which are also the ones most used by translators, are Themes and Plugins tabs.

Each of these tabs has 11 different options for filtering plugins or themes with different criteria:

• Untranslated Favorites, Remaining Strings (Most first)
• My Favorites
• Remaining Strings (Most first)
• Remaining Strings (Least first)
• Waiting + Fuzzy (Most first)
• Waiting + Fuzzy (Least first)
• Waiting + Fuzzy (Newest first)
• Waiting + Fuzzy (Oldest first)
• Percent Completed (Most first)
• Percent Completed (Least first)
• 100% Translations

A view of the current filters in the Plugins and Themes tab

What filters can and cannot do

These sorting filters are enough to work with themes, as them only have one translation project and work perfectly when you want to sort the results according to the tasks you have planned: translate themes from 0%, complete plugins with few strings, etc.

The same is not happening with plugins. A plugin generally have four translation projects:

• Development (trunk)
• Development Readme (trunk)
• Stable (latest release)
• Stable Readme (latest release)

The platform counts the strings by calculating the sum of the strings from all the projects, including the Readmes. The issue with this is that translators generally give priority to the Development/Stable strings that are applied to the plugin itself, while the Readme strings refer to the information shown on the plugin page at WordPress.org and the changelog, which is usually of lower priority.

At es_VE locale we have many plugins 100% translated, but some of them still have strings pending in the Readme projects (over 1000 in some). So when you use the current filters, there's no way to filter out plugins with pending or 100% finished strings for only the Development/Stable projects. This makes it difficult for you to translate the new strings in the updated plugins because the results you get are not accurate when including the Readme projects.

As an example, if at this moment you use the ​Percent Completed (Most first) filter to see the new strings added to the updated plugins in order to complete them, the results will be return plugins that are currently already at 100%, but have pending strings in the Readme projects.

Example of results when using the Percent Completed (Most first) filter: The plugins shown are already translated.

The proposal: add 4 new filters

An improvement that would significantly enhance the translators' experience is the addition of 4 new filters that allow to skip readme projects from the results. The proposed filters are the following:

• Remaining Strings - Development/Stable (Most first)
• Remaining Strings - Development/Stable (Least first)
• Percent Completed - Development/Stable (Least first)
• Percent Completed - Development/Stable (Most first)

A sketch of the proposed filters.

[maximejobin]

I totally agree something like this would help a lot.

That being said, I'm not sure about the "Development/Stable" purpose. What I want to know if the "Stable" branch only. I'm not interested in the Development branch as it is not a priority.

I know some plugins, for instance, have only one branch. I do think it's considered the "Stable" branch even if it is a DEV branch that comes from an old structure.

If it makes sense, I need a filter where approving strings will make it published.

I had a ​discussion on Slack where it was pointed to me that :

The treshold for the FIRST language pack to be created is 90% (not 95 anymore). Once a language pack has been created, even if it would drop to e.g. 60%, any string validations would result in the creation/update of the language pack.

That means that the completion percentage is not an indicator anymore (was it before?).

[Nao]

We (GTEs) keep wanting to make sure when "Waiting" translations exist in Dev sub-project, not because we care to make Dev 100% all the time but new translation contributors sometimes start from Dev.
So if GTEs completely ignore Dev sub-projects, suggested translation may sit there forever without any review.

Similar discussion in #5368.

10159 will lower the rate of the mistake in the future, though not 100% of the time.

[maximejobin]

@Nao My point was not clear. I think there should be separate filters for Stable and Dev and not have "Stable/Development" as one filter.

[YordanSoares]

Replying to maximejobin:

@Nao My point was not clear. I think there should be separate filters for Stable and Dev and not have "Stable/Development" as one filter.

@maximejobin in most plugins the Development and Stable project has the same strings, and currently when you send or approve a string whether in Development or Stable project, it immediately is copied to the another.

On the other hand, many plugins only have the Development project (because the developer don't keep older versions in "tags"), so in practice the main translation used by the plugin is Development. If you're looking for just Stable, you'll miss out on maintaining plugins that are using the strings directly from Development project. By searching for both project at the same time you "free two birds with one key".

[maximejobin]

Thank you for the clarification @YordanSoares.

I get all that.

As an "approver", I'm not really interested about projects that did not meet the requirements (minimal strings). I would like to know what is the missing count to make the translations published.

Getting a number that is a "mix" of Dev and stable is not something that makes sense for me. If, by "Stable/Development", you meant the "right" branch depending on how the plugin/theme is structured, I totally agree with that.

My only question would be: is the label "Stable/Development" clear enough?