mwalker wrote:

The last time this came up; it was because we create the CentralNotice aggregate group -- which was not queried for when looking for translation tasks.

I know Phillipe has just been adding [ Help with translation ] links to banners to solve this problem.

@Niklas; I know I have some open tasks to retire translation groups that are no longer needed which I know was something we wanted so that translators were not presented with out of date content to translate. I'm guessing that still stands -- but if that was out of the way; do you have any thoughts?

Sorry didn't read the description completely. Will do that later. Just noting in that Special:NotifyTranslators was only implemented for translatable pages. The banners are not considered as translatable pages in Translate extension.

(In reply to comment #1)

The last time this came up; it was because we create the CentralNotice
aggregate group -- which was not queried for when looking for translation
tasks.

I know Phillipe has just been adding [ Help with translation ] links to
banners
to solve this problem.

Yes, we have been including these links routinely for a long time (e.g. https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/FDCpropreview20132v1 - but I seem to recall it was common practice in 2012 already). And they are usually good drivers of translations. But not always (I have run several country-specific FDC community review banners for 6-10 hours now without getting translations for the local languages in that country). Also, there is some kind of expectation that at least for major languages, it is preferable to already have translated versions available when launching the banners, instead of presenting them in English first. So the links don't quite solve this problem.

(In reply to comment #2)

Sorry didn't read the description completely. Will do that later. Just noting
in that Special:NotifyTranslators was only implemented for translatable
pages.
The banners are not considered as translatable pages in Translate extension.

Thanks, that was indeed my assumption in the tentative proposal above, so it's useful to have this confirmed (I also clarified the documentation on mediawiki.org in that regard).

@Tbayer is this still a problem? Thanks!

Yes, the situation hasn't changed.

Reading this bug and T87448, I'm increasingly convinced that banners *should* be translated pages. There's no good reason to translate each string as a separate message, it takes away from context and continuity. Banner messages are in this weird overloaded role anyway, where they are also used as variable parameters, and we should clear that up.

The historical reason for the banner message misstep was probably that most banners are heavily marked up with raw, unbalanced HTML and other junk, there are very long sections which would not be translated.

In T58187#1741289, @awight wrote:

The historical reason for the banner message misstep was probably that most banners are heavily marked up with raw, unbalanced HTML and other junk, there are very long sections which would not be translated.

I think there were concerns about only using translations which have been marked as reviewed. But that should be possible even with translatable pages with some effort. With regards to heavy markup, sensible use of <translate>...</translate> and tvars tags can hide that markup from translators.

As an additional bonus, you would be able to easily group messages on two levels: similar messages on one page (as different units), and similar pages on aggregate message groups (see glossary and documentation if you are not familiar).

Perhaps the notification special page should support aggregation groups? The banners already produce a group each, so it should be relatively straightforward from then on, at least for less complex banners (that do not reuse messages from other banners that accordingly perfectly need to be added to the to-translate notification as well)