Having looked at the code and not tested yet I have a couple of questions:

1. This requires you to have something selected. If not you just get an error message. Is this intentional? I think you should still be able to report an error in that case. You'd just need to enter the word manually.
2. There's no validation of the selection. You can selected multiple words or only part of one for instance. I think it would be better to check against tokens in utterances. You should be able to reuse logic from the selection player or the highlighter for this. You probably also want the selected text to be in an editable field.
3. Did you try building context using the utterance of the selected word? Again the logic in the highlighter should be usable here.

Everything is done in the frontend. Did you look at what could be done in the backend instead? This would offload the users device. It may be tricky to do with the gadget solution. Perhaps it's worth weighing pros and cons of having the feedback page on the producer wiki instead of under the extension page.

In T395320#11156931, @Sebastian_Berlin-WMSE wrote:

Having looked at the code and not tested yet I have a couple of questions:

1. This requires you to have something selected. If not you just get an error message. Is this intentional? I think you should still be able to report an error in that case. You'd just need to enter the word manually.
2. There's no validation of the selection. You can selected multiple words or only part of one for instance. I think it would be better to check against tokens in utterances. You should be able to reuse logic from the selection player or the highlighter for this. You probably also want the selected text to be in an editable field.
3. Did you try building context using the utterance of the selected word? Again the logic in the highlighter should be usable here.

In T395320#11206051, @Sebastian_Berlin-WMSE wrote:

Everything is done in the frontend. Did you look at what could be done in the backend instead? This would offload the users device. It may be tricky to do with the gadget solution. Perhaps it's worth weighing pros and cons of having the feedback page on the producer wiki instead of under the extension page.

I’m a bit unsure where I should focus my efforts next, since your two latest comments point in somewhat different directions:

• Your first comment focused on improving the UX and frontend functionality
• The second one raised a more backend question

Is the idea to explore both directions in parallel, or would you prefer I focus on one before the other?

Let me know what you think makes most sense as a next step!

I didn't mean that you should remove the frontend entirely. I still think that is useful to make it easy to use.

There is some logic that could live in the backend to offload the users device. For instance there's a request that sends the entire page content. You could instead have request that takes a small number of parameters (word, language, page etc.) and have the backend deal with adding it to the correct place. This would be a new API action.

Another thing to consider is how to do it when you only have one wiki. Even though what we have in production at the moment (and for the foreseeable future) uses producer and consumer wikis, the primary way to use Wikispeech should arguably be on a single wiki. If it proves too much work to cover that now we could to stick with supporting what we run now. In that case you should make sure that you don't build something that will be difficult to adapt to a single wiki.

Now I have implemented a bit better on the frontend part, even though I can see the logic may a bit messy regarding validation of the selected word through tokens and utterances, but I couldn't figure out how to do in in another way. Feel free to comment on this code on gerrit.

I have not started on the backend part of this task though, but I will investigate what you proposed regarding maybe creating a new API-action, and by creating a new API-action I would have to create a ned API-module right?

Yes, a new action would mean a new API module.

As for now, the new Api-module doesn't include consumerUrl.. Probably want that

Now it should include logic for consumer-url.

How do you trigger this? When I click the feedback button I'm just redirected to the page Extension:Wikispeech/Pronunciation_errors/ (on the local wiki).

There is no point in "making it easier to report pronunciation errors" as the bottle neck seems to be the handling of already reported errors. ;-)

I am still waiting for a response and frequent status reporting on the planned actions for the pronunciation errors that I reported between June and August 2021, i.e. four years ago, on the page https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors/sv
See also:

• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-06#Testa_Wikispeech
• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-10#Uppdatering_av_Wikispeech-test
• https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Larske/Testsida11

In T395320#11364961, @Larske wrote:

There is no point in "making it easier to report pronunciation errors" as the bottle neck seems to be the handling of already reported errors. ;-)

I am still waiting for a response and frequent status reporting on the planned actions for the pronunciation errors that I reported between June and August 2021, i.e. four years ago, on the page https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors/sv
See also:

• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-06#Testa_Wikispeech
• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-10#Uppdatering_av_Wikispeech-test
• https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Larske/Testsida11

Hi! The reason we’re working on improving the reporting process is precisely because the current way of handling pronunciation errors has proven inefficient.
By creating a better structure for collecting and managing reports, we aim to make it easier to address issues more effectively over time.

Wikispeech is still under development, and we’re doing our best with the resources available.
That said, you’re absolutely right that we can and should improve how we communicate progress and updates, especially in places like the discussions and pages you linked. We’ll take that on board going forward!

Appreciate your continued engagement!

It looks like this only works on the wiki where Wikispeech is installed. That's good as the default, but the way we have it set up now we'd want to use a page on an external wiki. Is that something you plan for this task or will that be a follow up?

In T395320#11373428, @Sebastian_Berlin-WMSE wrote:

It looks like this only works on the wiki where Wikispeech is installed. That's good as the default, but the way we have it set up now we'd want to use a page on an external wiki. Is that something you plan for this task or will that be a follow up?

Yes exactly! I was planning on having that as a follow up, since we don't really have that external wiki yet

In T395320#11373429, @Viktoria_Hillerud_WMSE wrote:

[...] we don't really have that external wiki yet

Weren't we going to stick with https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors?

In T395320#11373445, @Sebastian_Berlin-WMSE wrote:

In T395320#11373429, @Viktoria_Hillerud_WMSE wrote:

[...] we don't really have that external wiki yet

Weren't we going to stick with https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors?

Hmm.. yes, but it would need some refactoring. But you meant how to link to that page in the code I understand now.
So this is what you meant in config variable in extension.json?

Yes. When you specify the error page it could be either a local one or one on another wiki. In case of the former you'd use the logic you have in the patch. In the latter you'd use the other wikis API.

Of course it's best to keep as much code as possible common. I'd imagine that all the logic for creating the wikitext should be the same for example.

I see, then it sounds best if I fix all of this in this patch

I have been poking around in the code quite a bit now, to separate the logic from when locally reporting and externally reporting an error.

I've gotten it to work locally. It required creating the page first and adding the table to it. Before that I received non-specific error: "Pronunciation error report could not be saved.". I think it would be easiest to just add some instructions for this for now. I may be wort to automate to some extent in the future.

When I tried from a consumer it doesn't work. Looks like it's trying to make the request to the local wiki instead of the producer. I haven't looked too closely at the code yet. Would you say that it's reasonable to use the new API on the producer wiki or would it be better to implement it in the frontend as you started with? Even if there are advantages with the former we also need to take into account how complex it makes the code.

In T395320#11383017, @Sebastian_Berlin-WMSE wrote:

I've gotten it to work locally. It required creating the page first and adding the table to it. Before that I received non-specific error: "Pronunciation error report could not be saved.". I think it would be easiest to just add some instructions for this for now. I may be wort to automate to some extent in the future.

Yes exactly, I must have forgot to tell you that this must be done in order for it to work, and I think it is a good idea to in the future automate it, but for now make instructions for it in some way.

When I tried from a consumer it doesn't work. Looks like it's trying to make the request to the local wiki instead of the producer. I haven't looked too closely at the code yet. Would you say that it's reasonable to use the new API on the producer wiki or would it be better to implement it in the frontend as you started with? Even if there are advantages with the former we also need to take into account how complex it makes the code.

A question regarding this, how do you try from consumer? What settings do you make to test it?

And regarding the new API-solution: I think using the API on the producer makes sense, even if it could be complex.
The previous frontend-only flow (e.g. editing the report page manually) isn’t used anymore. The current UI submits via the API directly.

Finally I understood the complexity of consumer vs producer. When adding gadget-template.js (from the repo) to the User:<your-name>/global.js and set producerUrl = 'http://localhost:8080/w'; we're explicitly telling the consumer wiki (e.g. Wikipedia) where the producer is located. Testing this setup on Wikipedia, I was able to reproduce the issue where the request was incorrectly sent to the local wiki API instead of the producer.

This led me to realize that the request was being made using mw.Api(), which always only targets the local wiki. The correct approach is to use mw.ForeignApi() when the producer is located on a different domain.
After updating the implementation to use ForeignApi(), and setting $wgWikispeechProducerMode = true; I confirmed that the reporting functionality now works as expected!

Next steps: I’ll explore whether Wikispeech’s existing RemoteWikiPageProvider can be reused to handle remote edits. Most likely, I’ll need to extend it with support for editing pages (e.g. fetching CSRF tokens, posting updates), since it currently only supports reading. Do you think this is a good idea? @Sebastian_Berlin-WMSE
Right now, this logic is inside ApiWikispeechReportPronunciation:saveToExternalWiki()

After further reflection, I think its better not to extend RemoteWikiPageProvider with editing functionality.

Instead, I’m keeping the editing logic (token fetching, editing etc) within ApiWikispeechReportPronunciation::saveToExternalWiki(), where it’s directly related to the API's purpose, reporting pronunciation errors.

I think that this separation keeps RemoteWikiPageProvider focused only on reading remote pages

I disagree.

I think having a class that handles communication with a remote wiki makes sense. It's possible that we want to do this more in the future.

We should also try to avoid putting logic into the APIs that isn't strictly for the APIs (e.g. reading parameters and formatting output). We recently broke out logic from the listen API because it was needed elsewhere. If for instance we decide that we want make a maintenance script that does some cleaning up on error page we'd have to do that again here.

That's true. I think in that case that the function saveToExternalWiki() (that now lives in the API), then instead should live in RemoteWikiPageProvider, but the helper method: insertRowIntoReportTable() should be in a separate helper class.

I can’t get $this->getConfig()->get('WikispeechPronunciationErrorReportPage') to read the value from extension.json.
I always get a "missingtitle" error, but if I hardcode the page title in the ApiWikispeechReportPronunciation.php, it works as expected.
So, config loading via extension.json seems broken for this variable, and I don’t understand why.

I still plan to refactor insertRowIntoReportTable and saveToExternalWiki into RemoteWikiPageProvider, but I need the config reading to work first.

Any ideas what could be wrong or what to try next? @Sebastian_Berlin-WMSE

What does the code look like where you use the config variable? What does getConfig()->get() return?

My bad! Seems I had set it an extra time in Localsettings.php (no idea why) so now it works with getConfig()->get()
Now I can continue breaking it out to RemoteWikiPageProvider

I was finally able to finish what I started last week regarding breaking logic out from ApiWikiSpeechReportPronunciation to RemoteWikiPageProvider and also created a helper class for inserting a row to a table end.
This new class is pretty small, so it maybe a bit unnecessarily to have it, but I can't really think of having it anywhere else.

I think that size alone doesn't disqualify from having a separate class. If the logic is distinct enough it can be worth it even if there are only a few functions. This makes improves the structure. It's also possible that we want to expand it at some point and if we wait until it's Big Enough™ it'll probably be more work figuring out what bits should go where.

(Having worked on the frontend in T182289 I have fresh experience of how confusing it can be with unclear separation. And that's code that I've probably written most of myself 🙈)

At the moment I'm getting errors because of missing pages (I think). Can you give me a run down on what's needed to make this work? We'd also need to include instructions somewhere how to use this for maintainers, so it could be a starting point for that.

I see! Before using the API, we need to have the page Extension:Wikispeech/Pronunciation errors/en to exists on our local wiki and to contain a wikitext table that ends with |}, for example:

{| class="wikitable sortable"
! Date !! Word or expression !! Page !! Context !! Additional information !! Status
|}

I hope this is what you meant?

We talked about this in person, but yes, that looks about right.

After today we discussed that it would be better to set a config value, regarding the interwiki-link in the LocalSettings.php, of a wiki.
This is currently set in ApiWikispeechReportPronunciation:execute():

$isExternal = $consumerUrl !== null;

if ( $isExternal ) {
	$pageNameRaw = 'mediawikiwiki:' . $pageNameRaw;
}

I’ll look into how to make this configurable, so the correct wiki can be set per installation.

Furthermore, I’m still debugging why my edits from a wiki to an external wiki (e.g from localhost) fail with centralauthtoken errors. It looks like localhost:8080 isn’t recognized as an authorized user for making edits on the target wiki.

The error occurred again. First time was no issue when reporting, but from now on I get this:

error	{ code: "internal_api_error_Exception", info: "[9d630c08d88158e46e3e1964] Exception caught: We are temporarily limiting logged-out editing from your location. Please [//www.mediawiki.org/w/index.php?title=Special:CreateAccount&campaign=temp-rate-limit create an account] to edit, or try again later.", errorclass: "Exception", … }
code	"internal_api_error_Exception"
info	"[9d630c08d88158e46e3e1964] Exception caught: We are temporarily limiting logged-out editing from your location. Please [//www.mediawiki.org/w/index.php?title=Special:CreateAccount&campaign=temp-rate-limit create an account] to edit, or try again later."
errorclass	"Exception"
*	"Exception at /var/www/html/w/extensions/Wikispeech/includes/Segment/RemoteWikiPageProvider.php(168)\nfrom /var/www/html/w/extensions/Wikispeech/includes/Segment/RemoteWikiPageProvider.php(168)\n#0 /var/www/html/w/extensions/Wikispeech/includes/Api/ApiWikispeechReportPronunciation.php(120): MediaWiki\\Wikispeech\\Segment\\RemoteWikiPageProvider->saveToExternalWiki()\n#1 /var/www/html/w/includes/Api/ApiMain.php(2054): MediaWiki\\Wikispeech\\Api\\ApiWikispeechReportPronunciation->execute()\n#2 /var/www/html/w/includes/Api/ApiMain.php(957): MediaWiki\\Api\\ApiMain->executeAction()\n#3 /var/www/html/w/includes/Api/ApiMain.php(928): MediaWiki\\Api\\ApiMain->executeActionWithErrorHandling()\n#4 /var/www/html/w/includes/Api/ApiEntryPoint.php(138): MediaWiki\\Api\\ApiMain->execute()\n#5 /var/www/html/w/includes/MediaWikiEntryPoint.php(184): MediaWiki\\Api\\ApiEntryPoint->execute()\n#6 /var/www/html/w/api.php(30): MediaWiki\\MediaWikiEntryPoint->run()\n#7 {main}"

The request was:

action	"wikispeech-report-pronunciation"
format	"json"
origin	"https://sv.wikipedia.org"
centralauthtoken	"227bb1bb49681a600f31f15b311f41a849c69a5a"
lang	"sv"
page	"Katt"
date	"2026-02-02"
row	"|-\n|+2026-02-02+||+enkla+||+[[Katt]]+||++||++||\n"
word	"enkla"
context	""
extra	""
consumer-url	"https://sv.wikipedia.org"
token	"+\\"

So it indeed seems like the token can't be verified from localhost:8080

In T395320#11573745, @Viktoria_Hillerud_WMSE wrote:

Furthermore, I’m still debugging why my edits from a wiki to an external wiki (e.g from localhost) fail with centralauthtoken errors. It looks like localhost:8080 isn’t recognized as an authorized user for making edits on the target wiki.

Note that it's localhost only on your machine. For any other server it'll be your IP number.

I see. I have now added logging, to easier see when it fails. If you want, you can try and see if you get the same behaviour as me when trying to edit more times. Otherwise, it has to be something with my IP that is blocked, even though I have checked the blocking list, and my IP doesn't seem to be in that list.

The problem seems to be that the frontend need to prove to the backend to authorize the edit. The proper way seemed to be this: Manual:Edit_token
But when trying this it still did not work on consumer, since it says:

csp-report	{…}
blocked-uri	"http://localhost:8080/w/api.php?action=query&format=json&origin=https%3A%2F%2Fsv.wikipedia.org&centralauthtoken=e83195c3e7dddee6898be0922d2a92f649c69a5&meta=tokens&type=9b682d0225f7a767e93b665069b305d5698d9319%2B%5C"
effective-directive	"connect-src"
line-number	129
original-policy	"script-src 'unsafe-eval' blob: 'self' https://meta.wikimedia.org https://*.wikimedia.org https://*.wikipedia.org https://*.wikinews.org https://*.wiktionary.org https://*.wikibooks.org https://*.wikiversity.org https://*.wikisource.org https://wikisource.org https://*.wikiquote.org https://*.wikidata.org https://*.wikifunctions.org https://*.wikivoyage.org https://*.mediawiki.org 'unsafe-inline'; default-src 'self' data: blob: https://upload.wikimedia.org https://commons.wikimedia.org https://meta.wikimedi…ommons.wikimedia.org https://meta.wikimedia.org https://*.wikimedia.org https://*.wikipedia.org https://*.wikinews.org https://*.wiktionary.org https://*.wikibooks.org https://*.wikiversity.org https://*.wikisource.org https://wikisource.org https://*.wikiquote.org https://*.wikidata.org https://*.wikifunctions.org https://*.wikivoyage.org https://*.mediawiki.org https://wikimedia.org 'unsafe-inline'; object-src 'none'; report-uri https://sv.wikipedia.org/w/api.php?action=cspreport&format=json&reportonly=1"
violated-directive	"connect-src"

And when I read more closely on the edit token documentation I can see this:

This proves to the server that the user has requested the change directly from the site and not from an external site, as external sites do not have access to the edit tokens of the user.

So it seems it's not approved when it comes to cross-site editing. I'll check more if there is some discussion on this topic, otherwise maybe we can look at this task together some time.

Since this has taken a lot more time then wanted, and we obviously need to lookup more about how to make cross-wiki edits, we decided in making this low priority, and instead make a sub task from this task that focuses on handling this ONLY on the frontend, since that should work, see patchset 5 that handled this.

We chose to switch to backend handling because it can significantly offload the users device. That's why we will keep this task for the future.

Change #1239659 had a related patch set uploaded (by Viktoria Hillerud WMSE; author: Viktoria Hillerud WMSE):

[mediawiki/extensions/Wikispeech@master] Frontend solution on reporting pronunciation errors

https://gerrit.wikimedia.org/r/1239659

When adding a link in the "Page" it points to the wiki with the error page, not the source wiki. E.g. in https://www.mediawiki.org/w/index.php?title=User%3ASebastian_Berlin_(WMSE)%2FTmp%2Fen&diff=8229646&oldId=8229645&oldid=8229645 the page is on ENWP.

Ah yes, I had built the URL wrong, now it works, but it looks quite messy, is there a better way of doing this?:

	const server = mw.config.get( 'wgServer' );
	const articlePath = mw.config.get( 'wgArticlePath' );
	const pageName = mw.config.get( 'wgPageName' );
	const fullUrl = server + articlePath.replace( '$1', pageName );

I think that looks good. As far as I know there's no way to get the whole URL to a page easier.

Another way could be to use location, but then you'd have to handle things like URL fragments to not end up with weird looking URLs. I think your way of building it from config variable is better.

In T395320#11365238, @Viktoria_Hillerud_WMSE wrote:

In T395320#11364961, @Larske wrote:

There is no point in "making it easier to report pronunciation errors" as the bottle neck seems to be the handling of already reported errors. ;-)

I am still waiting for a response and frequent status reporting on the planned actions for the pronunciation errors that I reported between June and August 2021, i.e. four years ago, on the page https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors/sv
See also:

• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-06#Testa_Wikispeech
• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-10#Uppdatering_av_Wikispeech-test
• https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Larske/Testsida11

Hi! The reason we’re working on improving the reporting process is precisely because the current way of handling pronunciation errors has proven inefficient.
By creating a better structure for collecting and managing reports, we aim to make it easier to address issues more effectively over time.

Wikispeech is still under development, and we’re doing our best with the resources available.
That said, you’re absolutely right that we can and should improve how we communicate progress and updates, especially in places like the discussions and pages you linked. We’ll take that on board going forward!

Appreciate your continued engagement!

After more than four months since your reply I haven't seen any improvement when it comes to "communication about progress and updates" targeted towards the svwp community. Now you have changed the priority of this specific task to "Low" and put it as "Waiting" if I read correctly.

• What are you waiting for?
• When can we expect the reports on examples of "poor pronunciation" to be acted upon?
• Do you have any statistics to share when it comes to the number of "Wikispeech plays" per month triggered from svwp (exluding your own testing)?
• Is it time to remove the Wikispeech gadget from the Swedish Wikipedia? (currently it seems to be broken/dead)

• What are you waiting for?
• When can we expect the reports on examples of "poor pronunciation" to be acted upon?
• Do you have any statistics to share when it comes to the number of "Wikispeech plays" per month triggered from svwp (exluding your own testing)?
• Is it time to remove the Wikispeech gadget from the Swedish Wikipedia? (currently it seems to be broken/dead)

Hi, and thank you for your follow-up and for raising these questions. To address your questions:

What are you waiting for?

A big part of the delay is due to internal changes over time, including staff changes and reorganization, which has affected our continuity. In addition, we have needed to prioritize other urgent tasks within the project, which has unfortunately delayed work overall.

When can we expect the reports on examples of "poor pronunciation" to be acted upon?

We acknowledge that these reports have not been handled as they should have been, a lot due to the above explanation. However, to clarify, this specific task does not involve correcting pronunciation errors directly.

We will begin going through the existing reports in the coming days, and the intention is to address them in the speech synthesis. We will also start updating the “Status” column on the report pronunciation error page to reflect progress on each item.

Do you have any statistics to share when it comes to the number of "Wikispeech plays" per month triggered from svwp (exluding your own testing)?

Here are the statistics for the last twelve months. We don't have a way to exclude the ones we've generated at the moment.

Is it time to remove the Wikispeech gadget from the Swedish Wikipedia? (currently it seems to be broken/dead)

The issue with Wikispeech not functioning on SVWP was identified recently and is currently being actively worked on. As you have seen, it is already tracked here: Wikispeech doesn't work on SVWP. Since Wikispeech is still under development and testing, temporary disruptions can occur, but resolving this issue is currently our top priority.

At the moment, ensuring that Wikispeech is functioning properly on SVWP needs to have top priority. Without a working system in place, improvements to pronunciation will not be noticeable to users. Once functionality is restored, addressing reported pronunciation issues will have a meaningful impact.

Change #1239659 merged by jenkins-bot:

[mediawiki/extensions/Wikispeech@master] Frontend solution on reporting pronunciation errors

https://gerrit.wikimedia.org/r/1239659