Due to the number of possible patterns, and user-submitted strings, it's going to grow quickly and become hard to prioritise certain patterns over another.
I believe we should split patterns strings into two GlotPress projects: Core (WordPress.org "official" patterns) that should get a high-priority on translations, and Community (Every string ever submitted by all creators).
Additionally, it may make sense to create a third project for either Popular Patterns, or for "Common Strings" (Either popular strings, or a set of 'suggested' strings for use within patterns).
Note: GlotPress projects do already have a 'priority field' for individual strings, which could be used here as well, but I feel that's more relevant when it's used for a small / select few strings within a project, not as a blanket Official-vs-Community distinction.
The text was updated successfully, but these errors were encountered:
Currently, the patterns sent to WordPress sites are those with the internal keyword "Core", or the category "Featured". Grabbing both should be good for an "official" set. But there are no community patterns in either, so we could also use "patterns by wordpressdotorg" as the "official" list, since eventually all patterns will be sent to WordPress sites (but the browsing UI needs to be updated first, so I don't know a timeline there).
I should note, that I don't think this is a launch blocker of any form.
Currently, the patterns sent to WordPress sites are those with the internal keyword "Core", or the category "Featured". Grabbing both should be good for an "official" set [...] could also use "patterns by wordpressdotorg" as the "official" list
Ah, I had thought that the list of patterns sent to WordPress sites was much larger than that.. Especially considering the number of "patterns by wordpressdotorg" that exist outside of those two groups.
I guess in my mind, it'd be split in two: Core (for lack of a better term) and Community (once again...). The notion being that "Core" patterns are a higher priority to translate, and not including the long-tail of all submitted strings.
The options I can see:
Core = ( patterns by wordpressdotorg )
Core = ( internal-keyword: Core OR patterns by wordpressdotorg )
Core = ( internal-keyword: Core OR Category: Featured )
Core = ( internal-keyword: Core OR Category: Featured OR patterns by wordpressdotorg )
Using Category: Featured in there (3/4) makes the assumption that we'd not be be moving patterns in/out of them though.. But I guess authorship & internal-keywords could change too..
So maybe number 1, using authorship is the simplest option? As long as the authorship is set before publish? Which I don't think we can rely upon.
Currently the translations code doesn't support a pattern being unpublished #452 and similarly won't handle being moved between projects & retaining translations.
Perhaps my original suggestion of splitting it into separate projects isn't yet warranted, but the priority field that I disregarded is maybe indeed maybe the better option for now.
Set the priority to high for strings used in patterns owned by wordpressdotorg, in the Core internal keyword, or in the Featured category. Otherwise, leave it as normal.
Describe the bug
Currently all Pattern strings are added to the https://translate.wordpress.org/projects/patterns/core/ GlotPress project.
This was a decision made here and here.
Due to the number of possible patterns, and user-submitted strings, it's going to grow quickly and become hard to prioritise certain patterns over another.
I believe we should split patterns strings into two GlotPress projects: Core (WordPress.org "official" patterns) that should get a high-priority on translations, and Community (Every string ever submitted by all creators).
Additionally, it may make sense to create a third project for either Popular Patterns, or for "Common Strings" (Either popular strings, or a set of 'suggested' strings for use within patterns).
Note: GlotPress projects do already have a 'priority field' for individual strings, which could be used here as well, but I feel that's more relevant when it's used for a small / select few strings within a project, not as a blanket Official-vs-Community distinction.
The text was updated successfully, but these errors were encountered: