Foundraising team should evaluate this issue; then depending on the chosen solution, some work will be needed in CentralNotice or in Translate.

WMF does use it too, I have just looked through my Meta ns8 contributions, and they do happen to be mostly hundreds of edits publishing the banner translations: https://meta.wikimedia.org/w/index.php?title=Special:Contributions&end=&namespace=8&start=&tagfilter=&target=Base&offset=20230302160107&limit=500 . Among those I have found at least ToU update and UCoC banners. And that is just the banners I have personally been publishing the translations for, there probably were more.

I parcially agree with the task in principle, it takes quite a lot of time for me as a translation admin to go through translations to publish. Just to illustrate that I have just visited Special:CentralNotice and found a multilingual banner, the Wikimania registration one, I published the new or newly edited translations it had. It took me in total 7 minutes. It might not be a lot, but when there is a new banner set up, perfectly one should check whether there are new things to publish at least several times a day. When it is a banner about a WMF thing as the 2 I have mentioned my expectation is actually that WMF would be doing that, it feels kind of frustrating to be dealing with these loose ends left by someone at WMF.

When publishing translations I look at two things. Whether the text *seems to be* in the correct language and whether there aren't any things I can spot (obvious vandalism, wrong dates, etc), and whether it is safe to approve it. By safe to approve I mean that we are dealing with raw HTML here, probably also with JS support (I am not sure if the translation text goes through some sanitisation or or whether it supports everything the banner code itself does), I am making sure there are no nasty surprises.

What I do not look at is whether the translation is correct. I do that for the 3 languages I speak, Ukrainian, Russian, English, but when it comes to other languages even if I understand them, I cannot verify whether there are no mistakes, such as I would not be able to tell whether Belarusian translation actually uses some Russian or Ukrainian words, I would just understand it just as usual. Perfect scenario would be to publish only translations that are in the Ready state, in practice that does mean that it is proofread by someone, in case of major languages that is often several people who have done the review. But I do not do it that way, I publish all the translations, because in case of most languages there actually aren't many translators active and the only way someone would see the error and care to fix them is if they see the banner with it in.

I feel like a lot of the time could have been saved if the workflow was more ergonomic. To approve the Wikimania banner translations just now I had to go through the following steps:

1. open Special:CentralNotice
2. visually identify multilingual campaigns and open them, there was only one this time
3. for each campaign open its banners, there was only one banner this time
4. in the banner, click on the text or text2 messages to end up in the aggregated group
5. in the aggregated group change the filters to show only the languages that have translations and not show the ones that do not. The default is the exact opposite
6. still in the aggregated group filters now select the Status column in the drop down (this is a new step I believe, someone has made it so that on narrow screen (I use desktop view on mobile) now the table is narrowed to view and extra columns, are hidden, the column shown by default is not useful)
7. visually locate languages that have status different from published and open a new tab per each of them
8. in each tab visually check the translation for the things mentioned above and publish it

Optionally 9) open my own contributions to verify that everything went through and did not get stuck because of an API error or something

I am sure the ergonomics can be fixes, perhaps by us ourselves in order to make it easier to skip the many steps and perhaps just be shown all the unpublished translations for all the banners that are currently running or are scheduled for the future. All of them on the single page or a single slideshow like view. I guess someone can write a script or a tool for it.

That said it would be helpful to get help. Unfortunately because of the safety considerations it cannot be an automatic approval of messages that are reviewed by 2+ people. It is easy to cheat that, and with the right timing one can probably make international headlines...

For this reason I am in support of a separate group. The status change has to have a dedicated permission for it created (all the groups that currently have it should have it, nothing should change for them), then I guess with editinterface, banner-protect, perhaps protect, not sure about that one, and most importantly oathauth-enable, it has to be a 2FA required group, probably thus with all the other related features like disabling access until 2FA is on, we would have a nice group for trusted translators to help.

CN administrator group has quite a high threshold as the person has to have some HTML/JS/CSS skills. For this new group only basic HTML knowledge would be required as well as an ability to just spot some of the other things.

Hopefully it won't be too difficult to extract the permission, but I haven't looked into the codebase myself.

// speaking of time spent, this comment is 50 minutes in total

Thanks for sharing your perspective Base.
You are correct: where I said "WMF does not use this", I meant the function is not used in the Fundraising banners. There have been quite a lot of community faced CN banners requested by WMF in the past year that were on the shoulders of volunteers to design and coordinate the campaign and banner for. The Sound of Wikipedia, several Movement Strategy banners, and Wikimania to name a few.

I have been working on the Wikimania banner in the past weeks and to give some additional context: this banner received 60+ translations within the first 36 hours that almost all needed to be checked and set to published by me. To complete this: after that first 36 hours, I paused the banner for some maintenance and the team requested an additional line of text for the banner, which means all updated translations have to be reviewed and to be published to live again.
In my review, I use common sense, google translate, some yandex, a little bit of Wikipedia, and sometimes a background-check of the on-wiki editor (from the dropdown in the Translatewiki service that leads to Meta) to see if the person is a known translator. If I am unsure of a translation I do not publish, especially not when they have not been reviewed by the "second set of eyes".
I can in general make sense of Latin languages, but for all others I need the help of a translation service if I want to check the translation, but helps when I know how the translations came into being. For the Wikimedia Sound Logo for instance, I knew it was first offered to WMF translators before the banner went live and the link for translation was not shared beyond that group. The Wikimania banner had a group of volunteers working on it first, so I could publish those also quite 'safe'.

It is interesting that you have now published to live all open translation for this banner btw: I never publish only partially translated banners (even if they have reviewed status), like now in the case of Hindi, farsi, yoruba.
And for Tetun: I concluded yesterday this language was misbehaving and switched it off for the Wikimania banner and filled a phab-ticket ([[T341413]]). I wonder if this last one could be a usecase for what could go wrong when we extend the group of users able to publish to live the banner translations, because all 6 translators must have thought to be doing a good thing when translating, but in fact there is a glitch here that was not too obvious.

Btw, I don't think HTML knowledge is needed for this specific task: while normal translations through Translatewiki can include HTML elements that need to remain untouched, the CN banners never have HTML elements in the banner texts as far as I have seen.

It is interesting that you have now published to live all open translation for this banner

Well I am trying to look at this from the perspective of someone who would not know English. What would you rather have — 2 lines in the language you do not speak, or just 1 with the other one giving you a good idea what it is about at the least. Of course the perfect way of handling this would be for the translation administrator to only enable the campaign for the languages that now have the translations. I have been enforcing it for some content enrichment campaigns back half a decade ago, but for such general banners as the Wikimania one that is indeed not a way to go, unfortunately.

As to Tetun, thanks for catching it, I saw it looked French, but I didn't check what the language was supposed to be, I have decided it is some kind of French creole. That is indeed an odd bug. I have now deleted the ns8 translations.

the CN banners never have HTML elements in the banner texts as far as I have seen.

I think I did see some with the links in them (or have myself set up them like this in the past :), that is also possible), and those of course would be the <a href=""> links rather than the normal wikicode ones. But even without it there usually, I think basic knowledge is needed is because people approving translations need to be able to recognise some odd code if there was included some. That said that is more of a governance issue of whom to handle the new flag which I am sure we will figure out once the flag starts to be an option :)

What about parsing the translations as wikitext by default, and resort to raw HTML only if really needed? This would allow wikitext translations to go out automatically (instantly or after being reviewed by other translators), and only the few raw HTML translations would need security review by trusted users (either CN admins or members of the to-be-created group). translatewiki.net works similarly: the vast majority of messages is wikitext and translatable by any translator, while raw HTML messages are protected and translatable only by certain trusted people.

@Tacsipacsi, well, it still have to be trusted users. Not to stray into BEANS too much, but in 2 weeks there are general elections in Cambodia and Spain. Imagine the Khmer and Spanish banner text saying something else during the right timing than the call for Wikimania registration. This is still a very sensitive access even without an ability to insert custom HTML let alone JS magic.

In T341414#8999648, @Base wrote:

It is interesting that you have now published to live all open translation for this banner

Well I am trying to look at this from the perspective of someone who would not know English. What would you rather have — 2 lines in the language you do not speak, or just 1 with the other one giving you a good idea what it is about at the least

In the case of Hindi, I asked the translator via their Meta page to also add the translation of the second line of text and was waiting for their response. (Farsi and Yoruba were not available when I last checked). I guess there is something to say for both approaches, and they are not mutually exclusive.

the CN banners never have HTML elements in the banner texts as far as I have seen.

I think I did see some with the links in them (or have myself set up them like this in the past :), that is also possible), and those of course would be the <a href=""> links rather than the normal wikicode ones. But even without it there usually, I think basic knowledge is needed is because people approving translations need to be able to recognise some odd code if there was included some. That said that is more of a governance issue of whom to handle the new flag which I am sure we will figure out once the flag starts to be an option :)

You are correct about the banners in the past when often the would be a link assigned to the banner text, but nowadays we only run full-click banners. Advantage of these are multiple, if only for those users clicking on the image instead of the text and arriving on the file page on Wikimedia Commons instead of the intended landing page.
As a CN admin, for me it means that I only have to enable/request protection of the landing page and not also go to Commons for the protection of the image(s) used in the banner - this is an easy step to forget.

But nevertheless: that we don't do this it does not mean it's not still *possible*, so I agree that it could be a requirement for the assignment of this right.

In T341414#8999686, @Base wrote:

@Tacsipacsi, well, it still have to be trusted users. Not to stray into BEANS too much, but in 2 weeks there are general elections in Cambodia and Spain. Imagine the Khmer and Spanish banner text saying something else during the right timing than the call for Wikimania registration. This is still a very sensitive access even without an ability to insert custom HTML let alone JS magic.

Imagine a CN admin who speaks no Khmer or Spanish and has no idea about these general elections. Is it more likely that they notice those “beans” than someone who speaks the language but has no extra permissions does? (Assuming then that translations go out only after they have been approved.) Yes, that second person could be a sock or meat puppet, but if no “trusted user” approval is required for that malicious translation to go through, no approval is required to revert or fix it, either – this is how wikis should work. So I don’t think that even in a worst-case scenario, the benefits of a trusted-user approval outweigh the costs of it; while in a best-case scenario, it’s obvious that they don’t.

I agree @Tacsipacsi - and I think @Base does as well.
It sounds important to keep the two separated in this exchange:

• Knowledge of the language
• Understanding of HTML

It seems there is nothing to change in the Translate extension. Moving to watching.

The idea of allowing any two users to approve translations for CN banners is not a workable idea. This would make global CN banners incredibly susceptible to vandalism on a global scale, and far less protected than any random translatable page.

In terms of creating a new "trusted translator" group...this effectively already exists: translation administrators. I don't believe that translationadmins, at present, can mark translations of CN banners as published.

We can modify this, though I'm not sure what user right we would need to add to the translation admin group. It may require some CN extension work, as I think the ability to mark CN translations as ready might be bundled under centralnotice-admin, which we do not want to give to every translationadmin.

In terms of community policy, if a change is made to allow translation admins to publish translations for CN banners, it may be possible to give banner requesters limited temporary translation adminship, specifically to handle translations for their banner.

I think that there are four distinct and actionable tasks here:

• Encourage the use of plain wikitext instead of HTML by default in banners
• Make the interface for approving banner translations simpler and more intuitive
• Allow translation administrators to approve banner translations
• Provide banner requesters with temporary, limited translation adminship (similar to limited adminship)

In T341414#9112530, @Frostly wrote:

I think that there are four distinct and actionable tasks here:

• Encourage the use of plain wikitext instead of HTML by default in banners

I'm a bit confused here; I don't think I've seen anyone including html markup in a banner translation unit. Generally, if there's a line of text, we'll just put a localizable message there, and then add the translations through the Translate extension. Because there's rarely differing formatting within a line, it's just one plain text line inside a <p> tag. Additionally, CN banners are not parsed as wikitext, it's just HTML.

• Make the interface for approving banner translations simpler and more intuitive

I'm also confused on this point. Approving translations are as simple as opening the drop-down (on the review page) and then clicking "publish" for each translation.

• Allow translation administrators to approve banner translations
• Provide banner requesters with temporary, limited translation adminship (similar to limited adminship)

These two should be relatively easy to implement, depending on how the CN and Translate extensions bundle actions into their relevant userrights. Once the former is done, the latter is just a matter of a Meta-Wiki RfC, if we think that's even necessary.

In T341414#9114107, @Vermont wrote:

In T341414#9112530, @Frostly wrote:

I think that there are four distinct and actionable tasks here:

• Encourage the use of plain wikitext instead of HTML by default in banners

I'm a bit confused here; I don't think I've seen anyone including html markup in a banner translation unit. Generally, if there's a line of text, we'll just put a localizable message there, and then add the translations through the Translate extension. Because there's rarely differing formatting within a line, it's just one plain text line inside a <p> tag. Additionally, CN banners are not parsed as wikitext, it's just HTML.

Oops, thanks for clarifying.

• Make the interface for approving banner translations simpler and more intuitive

I'm also confused on this point. Approving translations are as simple as opening the drop-down (on the review page) and then clicking "publish" for each translation.

I got the impression that the process wasn't very simple from Base's comment:

In T341414#8999601, @Base wrote:

I feel like a lot of the time could have been saved if the workflow was more ergonomic. To approve the Wikimania banner translations just now I had to go through the following steps:

1. open Special:CentralNotice
2. visually identify multilingual campaigns and open them, there was only one this time
3. for each campaign open its banners, there was only one banner this time
4. in the banner, click on the text or text2 messages to end up in the aggregated group
5. in the aggregated group change the filters to show only the languages that have translations and not show the ones that do not. The default is the exact opposite
6. still in the aggregated group filters now select the Status column in the drop down (this is a new step I believe, someone has made it so that on narrow screen (I use desktop view on mobile) now the table is narrowed to view and extra columns, are hidden, the column shown by default is not useful)
7. visually locate languages that have status different from published and open a new tab per each of them
8. in each tab visually check the translation for the things mentioned above and publish it

Optionally 9) open my own contributions to verify that everything went through and did not get stuck because of an API error or something

I am sure the ergonomics can be fixes, perhaps by us ourselves in order to make it easier to skip the many steps and perhaps just be shown all the unpublished translations for all the banners that are currently running or are scheduled for the future. All of them on the single page or a single slideshow like view. I guess someone can write a script or a tool for it.

In T341414#9119141, @Frostly wrote:

I got the impression that the process wasn't very simple from Base's comment:

In T341414#8999601, @Base wrote:

I feel like a lot of the time could have been saved if the workflow was more ergonomic. To approve the Wikimania banner translations just now I had to go through the following steps:

1. open Special:CentralNotice
2. visually identify multilingual campaigns and open them, there was only one this time
3. for each campaign open its banners, there was only one banner this time
4. in the banner, click on the text or text2 messages to end up in the aggregated group
5. in the aggregated group change the filters to show only the languages that have translations and not show the ones that do not. The default is the exact opposite
6. still in the aggregated group filters now select the Status column in the drop down (this is a new step I believe, someone has made it so that on narrow screen (I use desktop view on mobile) now the table is narrowed to view and extra columns, are hidden, the column shown by default is not useful)
7. visually locate languages that have status different from published and open a new tab per each of them
8. in each tab visually check the translation for the things mentioned above and publish it

Optionally 9) open my own contributions to verify that everything went through and did not get stuck because of an API error or something

I am sure the ergonomics can be fixes, perhaps by us ourselves in order to make it easier to skip the many steps and perhaps just be shown all the unpublished translations for all the banners that are currently running or are scheduled for the future. All of them on the single page or a single slideshow like view. I guess someone can write a script or a tool for it.

Step 1-7 is needed to navigate to the translations starting from the Admin panel, I think to remember this specific section of the interface is visible for all, just not every user has access to change anything (read-only, as to say). Vermont is referring to step 8 in the process in their comment.

Also note that we don't get notifications for pending translations: an admin or stewards has to proactively check for new translations with the navigation path as mentioned in steps 1-7. They are also displayed in the CentralNotice campaign when the campaign has a multi-lingual banner (but this imho is of little help because you still have to go through all the steps). This may be something for a next feature request. :-)
With banners that have been turned on before the translations were completed or with banners that target globally/all languages, it's easy to forget that more translations may come in and quite a hassle to do step 1-7 only for a check.

In T341414#9111043, @Vermont wrote:

In terms of creating a new "trusted translator" group...this effectively already exists: translation administrators. I don't believe that translationadmins, at present, can mark translations of CN banners as published.

I disagree: translation admins are not expected to be translation reviewers. They should understand source page language (mostly English), but they cannot understand all target languages.
We don’t have enough translation admins in all languages, and I would oppose to grant other users who know other language, but don’t know translate markup syntax.

In T341414#9119218, @Ciell wrote:

Step 1-7 is needed to navigate to the translations starting from the Admin panel, I think to remember this specific section of the interface is visible for all, just not every user has access to change anything (read-only, as to say). Vermont is referring to step 8 in the process in their comment.

Yes, but you don't need to do all 7 steps every time you want to check on a banner you're supporting. When you setup a message group, you'll have a link to translate the message group, often to be included in the banner. From that link, click message group statistics, change which boxes are checked, and then there's the list of translations which you can then review and approve. Yes it's technically 8 steps in from just the search bar, but I'm not sure if there's any better way to navigate to message group stats for a specific message group besides through that chain of related pages. I'm certainly interested to know if there are thoughts on a better layout for these pages, though. My opposition to changing this is largely because, if we do get any development time (volunteer or staff) put towards this problem, there are more pressing things to work on. It's not great, but it's usable.

In T341414#9120484, @Pols12 wrote:

I disagree: translation admins are not expected to be translation reviewers. They should understand source page language (mostly English), but they cannot understand all target languages.
We don’t have enough translation admins in all languages, and I would oppose to grant other users who know other language, but don’t know translate markup syntax.

Certainly, translation admins do not understand all target languages...no one does. My point was that translation admins in my view are sufficiently trusted to mark translations as approved, given that they are the people who mark pages for translation. It's likely easier to give that group the technical ability to mark banner translations as approved (which would cover a lot of languages) and give it out as a limited role and temporarily to people who need it, than to make an entirely new user right and user group with the sole purpose of approving banner translations. Depends on the setup and what sort of development time that can be put into this.

Although I agree with @Pols12 that translation admins are not supposed to be translation reviewers but I feel it to be alright if they have ability to mark translations as "published", for example, in the languages that they know. I know Urdu and if I believe a translation is perfect and should me marked as published, I should be allowed to do it, instead of me waiting for someone else to do it, stewards? I am not sure if we have one knowing Urdu language.

@Vermont, marking pages for translation is entirely a different task than what we are discussing here. It is weird to grant TA rights to people who do not know markup syntax, so, eventually, we should not be confusing the two. We are talking about TA's having the technical ability to mark translation status as "published". I would be happy to see this thing included in TA rights but I reiterate TA's are not the best people to do so (and they shouldn't be forced either) because they don't know each and every language. A TA might be able to mark a given translation as published if it appears to be in a language that they are aware of.

In T341414#9112530, @Frostly wrote:

I think that there are four distinct and actionable tasks here:

• Encourage the use of plain wikitext instead of HTML by default in banners
• Make the interface for approving banner translations simpler and more intuitive
• Allow translation administrators to approve banner translations
• Provide banner requesters with temporary, limited translation adminship (similar to limited adminship)

Per frostly, I briefly investigated the third of these tasks, "Allow translation administrators to approve banner translations" and it seems to be a fairly low hanging change to the code of the tool ( see definition of rights here) -- if there is community concensus (@Vermont @Aafi -@Ciell ?), it should be very doable. I also asked the Security team to review if their were any concerns if Translateadmins would being added to the publish group -- and there is none.

Thanks! I don't think there has been much community discussion about this (except in this task), as the issue only affects CN admins and hardly anyone else notices it. Leaving it to the few active CN admins to publish hundreds of translations every time there is a global banner for elections etc. is a huge burden – (translation) admins on metawiki should be trusted enough to allow them to publish banner translations.

I second Johannnes89’s reasoning. CN admins would appreciate it when metawiki translation admins would support them with publishing translations of banners!

I agree with both @DerHexer and @Johannnes89 but I must reiterate from my previous messages. Although translation admins should be allowed to mark such translations as published, they should not be necessitated to do it as they are unlikely the people who would be deciding on how good a translation is but if they know the languages, they must be trusted to push the publish button.

In T341414#10659206, @Aafi wrote:

Although translation admins should be allowed to mark such translations as published, they should not be necessitated to do it as they are unlikely the people who would be deciding on how good a translation is

That's even more true for the few active CN admins. We are elected to implement CentralNotice banners, that doesn't say anything about our ability to judge translation quality. When I publish translations, I'm using Google Translate to check if there are obvious errors and I take a quick look at the translating user's edit count to see if it's an established, trusted account or a new one. That's all we can do, we have to rely on the community to fix any errors which slip through.

Translation admins are *not* trusted for their language knowledge. Granting them this right is as reasonable as granting sysops that right. Actually, sysops are probably more trustworthy than translation admins.

In T341414#10670451, @Pols12 wrote:

Translation admins are *not* trusted for their language knowledge. Granting them this right is as reasonable as granting sysops that right. Actually, sysops are probably more trustworthy than translation admins.

Agree, metawiki sysops should be able to publish those translations as well. There is no reason why it’s limited to CN admins, our job is banners, not translations.

Following up on my previous comment, I am going to say that the emerging consensus is: add both Meta Admins and Translate Admins groups to the allowlist for publishing Central Notice translations.

I have posted on wiki in three more spaces, to see if there is any additional thoughts -- but based on this conversation: adding these groups is an uncontroversial devolution of a not-risky right to other trusted user groups. Please correct me if I am wrong.

@Astinson, Content Translators? That would mean giving an important deal in the hand of disruptive vandals - we have been talking here about Translation administrators, they are way different that "content translators". What's missed?

@Aafi you are correct, sorry I was writing it quickly, and had the wrong user group in mind -- fixed

@Ejegg Following up from our conversation, @Astinson has reviewed this change with security. Moving to +1

Hey, what's the current status here after the sprint? :)

Heya @DerHexer, no real update on this as our last couple sprints worth of time (iow: most/all of July) we've been pretty short staffed (vacations, sabbaticals, and sicknesses combined) and this was unfortunately not prioritized during that time.

Thanks for the update!