De-prioritize plugin changelog translation

[Nao]

Problem

Plugin changelog strings tend to be long and detailed but translating them adds a little benefit to end users. However, since (new) translation contributors have no easy way of knowing this fact, they tend to try to spend time completing translation. The effort should be directed to translating UI strings and other parts of readme.

(​Slack discussion)

Solution (Suggestion)

Quick & Easy/Temporary Fix

Show a text banner that says something like this:

Translators: Changelog strings should be given low priority. Please translate other ones first.
PTE/GTE: Please set changelog strings as "Priority: Low".

"Real" Fix

There are a couple of ways to really solve the issue.

A: Automatically set low priority

1. Keep the current project structure and automatically mark changelog strings as low priority upon import into translate.wordpress.org.
2. Implement #4251 (Don't count low/hidden priority strings toward translation percentage).

B: Changelog as a separate sub-project

@garrett-eclipse suggested we could also try separating changelog strings into its own sub-project.

There will be these sub-projects:

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

He said:

By segregating makes it easier to get the readme to 100% without leaving a bunch of low priority untranslated changelog strings.

I'd say we'll still need to either mark all changelog sub-project low priority or show a text banner saying the changelog strings are low priority.

[Nao]

Example of Quick & Easy fix: notification banner text

[dd32]

Replying to Nao:

A: Automatically set low priority

1. Keep the current project structure and automatically mark changelog strings as low priority upon import into translate.wordpress.org.

That already happens.

The Description is marked high, changelog is marked low, and all others are normal.

For example, Akismets readme Pages 5.5~19 are all marked low priority: ​https://translate.wordpress.org/projects/wp-plugins/akismet/stable-readme/en-au/default?page=6

[Nao]

@dd32 Oh, that's great! We (polyglots) were not aware of this, but that already takes care of most of the issue.

I'm curious, how come some of the recent strings are not marked low priority?
​https://translate.wordpress.org/projects/wp-plugins/akismet/stable-readme/en-au/default?filters%5Bterm%5D=Release+Date+-&filters%5Buser_login%5D=&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filter=Filter&sort%5Bby%5D=priority&sort%5Bhow%5D=desc

[dd32]

In 8412:

Pligin Directory: i18n Import: Attempt to fix the priority setting for imported readme strings.

Apparently this broke 3 years ago shortly after being introduced in [3507] + [3549].

See #4252.

[dd32]

In 8413:

Plugin Directory: i18n Import: Fix a typo not marking the 'Short Description' as a high-priority string.

See #4252.

[dd32]

@Nao Well that explains why you weren't aware of it.. Turns out it hasn't been working :)

I've fixed that code and tested it out, new changelog entries are imported as low priority, short descriptions will now import as high priority (along with plugin names).. as it was originally intended.
I'll fix up the other ~20k short descriptions and !! ~half a million changelog entries which are marked as normal shortly.

[Luciano Croce]

Replying to dd32:

@Nao Well that explains why you weren't aware of it.. Turns out it hasn't been working :)

I've fixed that code and tested it out, new changelog entries are imported as low priority, short descriptions will now import as high priority (along with plugin names).. as it was originally intended.
I'll fix up the other ~20k short descriptions and !! ~half a million changelog entries which are marked as normal shortly.

WOW -- Thank you so much @dd32 big work! :)

[Luciano Croce]

@dd32 about the B proposal (separate change log into a sub-project) what do you think?

Could it be a possible change?

In this case (for example) for plugins you would have three separate files:

plugin.php
readme.txt
changelog.txt

The current Detailed Plugin Guidelines already recommend to separating the change log from the readme.txt (for example) in a separate changelog.txt file but this has not yet become a definitive standard.

For example, I have planned to do it in my plugins, starting from the next new versions (taking inspiration from the gutenberg plugin) and leaving only the current change log in the readme.txt.

As a developer, the change log help me to search the features/changes that I need for a new plugins or in troubleshooting (for example) but I don't think it's at all useful to preserve all old changes since release 0.1 this is why I believe that the separation can be a useful solution, and splitting the whole change log, in my opinion, could be a better solution.

[dd32]

Replying to Luciano Croce:

@dd32 about the B proposal (separate change log into a sub-project) what do you think?

Could it be a possible change?

Possible yes, but it's not something that I'm jumping to support.

Changelog data may not be as important to those who can translate (and therefore read multiple languages) but it certainly would be valuable to those who can't (Or are not as fluent at) read English.

To me, a proposal to split changelogs into a separate project is almost a request to cease translations of them entirely.
I'm aware that's not the intention here, but it certainly feels like it is.

I do agree that keeping ten years of changelogs is useless though, and translating those old logs is a waste of everyone's time.

From a technical perspective, anything is possible, but segregating it into a new protect would add a fair bit of hidden extra logic and code, it's not as simple as it may first appear.

I think I'd rather invest in better tooling, perhaps where the priority tagging is more effective than it currently is, perhaps stats of percentage of high priority strings are translated rather than focusing on full projects, etc.
#1078 is something that could help greatly with translating the readmes, but probably also increase the approval workload.

[Luciano Croce]

@dd32 Thanks again for the answer/clarification and for the new reflections that derive from it, but if it is possible to you, evaluate the best solution with in mind (also) the fallibility/variation of this request, and if you follow this discussion in slack ​https://wordpress.slack.com/archives/C02RP50LK/p1551904234128100 you will see that many other veteran translators also agree the @Nao proposal. ;)

[garrett-eclipse]

Replying to dd32:

Changelog data may not be as important to those who can translate (and therefore read multiple languages) but it certainly would be valuable to those who can't (Or are not as fluent at) read English.

To me, a proposal to split changelogs into a separate project is almost a request to cease translations of them entirely.
I'm aware that's not the intention here, but it certainly feels like it is.

I do agree that keeping ten years of changelogs is useless though, and translating those old logs is a waste of everyone's time.

From a technical perspective, anything is possible, but segregating it into a new protect would add a fair bit of hidden extra logic and code, it's not as simple as it may first appear.

I think I'd rather invest in better tooling, perhaps where the priority tagging is more effective than it currently is, perhaps stats of percentage of high priority strings are translated rather than focusing on full projects, etc.
#1078 is something that could help greatly with translating the readmes, but probably also increase the approval workload.

Thanks @dd32, I tend to agree with you there. Segregation very well may end in abandonment which would be negative as many users find the most recent changelog entries to be very useful in determining if they should upgrade and how thorough their testing prior to upgrade needs to be.

An additional thought might be along your priority tagging route is to introduce a lower priority than low which applies to changelog entries 1+ years old which would keep the more recent changes slightly higher priority as they're more useful to translate while those ancient version strings aren't as useful to users anymore.

Appreciate you addressing those changelog priorities already.

Cheers

[fernandot]

Totally disagree. For public the changelog is very important to know what change in every new update, specially if it's a Ecommerce related plugin.

It's a huge work but a necessary work

Replying to Nao:

Problem

Plugin changelog strings tend to be long and detailed but translating them adds a little benefit to end users. However, since (new) translation contributors have no easy way of knowing this fact, they tend to try to spend time completing translation. The effort should be directed to translating UI strings and other parts of readme.

(​Slack discussion)

Solution (Suggestion)

Quick & Easy/Temporary Fix

Show a text banner that says something like this:

Translators: Changelog strings should be given low priority. Please translate other ones first.
PTE/GTE: Please set changelog strings as "Priority: Low".

"Real" Fix

There are a couple of ways to really solve the issue.

A: Automatically set low priority

1. Keep the current project structure and automatically mark changelog strings as low priority upon import into translate.wordpress.org.
2. Implement #4251 (Don't count low/hidden priority strings toward translation percentage).

B: Changelog as a separate sub-project

@garrett-eclipse suggested we could also try separating changelog strings into its own sub-project.

There will be these sub-projects:

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

He said:

By segregating makes it easier to get the readme to 100% without leaving a bunch of low priority untranslated changelog strings.

I'd say we'll still need to either mark all changelog sub-project low priority or show a text banner saying the changelog strings are low priority.

[Nao]

Hi @fernandot

Copying ​my comment from Slack:

I’m not saying changelogs should go away or made untranslatable, but just talking about relative priority here. I’d rather have translators spend time on other parts of plugins that are higher priority, than giving them false belief that they have to translation all of readme in order to complete the plugin to be 100%.

@dd32

Thank you for the fixes!
I think we can close this ticket since #4251 can exist on its own - unless there are more to be done here.

[dd32]

Replying to Nao:

Thank you for the fixes!
I think we can close this ticket since #4251 can exist on its own - unless there are more to be done here.

I think you're right, I left it open to continue discussion incase it wasn't the ideal solution, but it seems acceptable, with the focus on the other areas that can be helped.
We can always re-open it if that doesn't end up being the case.