In T337398#8904912, @ppelberg wrote:

@Nardog can you please say more what "inconvenienced" might mean in this context? You described the impact of this issue in the description (thank you!) [i] and you sharing the above about ja.wiki leads me to be wonder whether there are other implications I might not yet be aware of/considering.

They're even looking to expand this to all namespaces, see T313636#8174638 and T315893.

Thanks. I assume you mean @matmarex, not @Batorsz.

The list should definitely be refreshed at least in the normal live preview (i.e. clicking "Show changes").

@ssastry @matmarex Any update? If you're not fixing it anytime soon I suggest that a User-notice is in order.

In T336763#8895970, @Aklapper wrote:

@Nardog: Please criticize ideas, not people. Thanks.

Replied on MW wiki because replying here would be off-topic.

I hope this means you're dropping TTS support entirely from the tag. What you should have been developing from the beginning IMHO are an inline player and a tool to easily upload TTS audio to Commons.

It's a widely visible feature across projects, and it was broken for hours if not more. It definitely deserves an entry in Tech News.

Attribution to text-to-speech has not been implemented. You may choose not to work on it but it's certainly not resolved.

Instead, it should immediately display the whole templates-used list, and then progressively fix up each item with the additional info. This would still mean that there are visual changes, but no extra list items would be added so it'd be a much smoother display. Non-existing templates would still be displayed as redlinks initially, as this info is available from the first action=parse API call.

Yes, please. I've found it frustrating that the list of templates does not appear immediately since T321032.

@ssastry What do you mean by "heuristics for some use cases"? Surely we can't leave VE's existing support for sortkeys (in the dialog) broken, and while we might as well remove it for the time being, VE must support sortkeys one way or another, or communities like jawiki would continue to be heavily inconvenienced by its absence.

Almost all articles on jawiki has custom sortkeys fwiw. insource:"defaultsort" and insource:"デフォルトソート" returned 1,307,925 out of all 1,374,785 articles. I'm sure there are other such languages.

Seems to have caused T337081: "Add interlanguage link" shows a bubble: "An unknown error occurred"

The skin doesn't seem to matter.

The obvious solution to me is to save the preference only when the checkbox is clicked (i.e. not through the URL).

(Examples from https://en.wikipedia.beta.wmflabs.org/wiki/Phonos_Natural4 and https://en.wikipedia.beta.wmflabs.org/wiki/Phonos_Natural3)

Some users may have already concluded that the ability to edit in the ways that were affected was simply removed, so I think we should tell them it's been fixed. We don't have to go into what those ways were and we can just say something along the lines of "From April xx to yy, you could not save certain kinds of edits on the mobile version of a wiki. This has been fixed."

Through what channel, may I ask?

Thanks for the fix. Shouldn't this be in User-notice?

Likely caused by this change:

In T334799#8783825, @Izno wrote:

Same symptom as T334797: Impossible to edit without JS or undo an edit on mobile site (414 URI Too Long)

Why is T334518 the parent task? Did you mean the other way around?

@Umherirrender @matej_suchanek Can you please look into T148533 as well?

Or maybe a bigger button that only appears when hovering?

I've thought of that, and although it's an enticing idea, I can't think of a neat way. Anything that reflows the rest of the paragraph would be disruptive (if it's at the end of a visual line, it could wrap to the next, making it never clickable), and position:absolute (or something akin to it) could stick out of the content. So AFAICS the only thing that's satisfactory both visually and UX-wise is something that pops up vertically.

Again, "🔊ⁱ" is far too small to even notice or click and could pose an accessibility issue. The button is already relatively short (the height of the text) so anything shorter would be too short. And since both the 🔊 icon and the text following it make up one button, a superscript inside (or after) it is invariably awkward. I bet use of any text is problematic given it'll be embedded within prose (how are screen readers going to read it?).

In T319690#8419538, @Pginer-WMF wrote:

Thanks for sharing your perspective. I agree that Wikidata cannot be a complete alternative for 100% of the cases. However, I think that the fragmentation a setting like this introduce has a cost. Especially when users will have the languages they look for right there in the "suggested languages" section (and searching is the most common access path when they don't). I think the efforts to maintain two separate versions would be better spent towards making the default version faster instead.

When ipa is passed (or wikibase, where IPA is rendered), the "i icon" should instead indicate the audio was machine-generated.

Is this to be done in a popup (PopupButtonWidget)? If so it would be nice if the editor could customize the message in the tag, such as "Report problems here" linking to a noticeboard. (If it's just a link instead of a popup, at least make the destination customizable.)

Please let it be a button. The superscript "i" is so small you can barely click it and enwp did away with it a long time ago.

I don't know if this means you're actually going with the bonkers decision that is reducing the supported languages (which would rip my heart out), but at any rate I just want to note just because the wikis are in the respective languages doesn't mean Phonos couldn't have wide application on them. This is especially true for the Wiktionary.

This displays a fundamental misunderstanding of what the CWS wish was. They weren't asking for a tool that generated audio from IPA as editors. They were asking for a feature that made trying to read IPA redundant as readers. It doesn't make a lick of difference whether the audio is actually generated from IPA as input, as long as competent human editors heard and put it. Even if it didn't support any IPA input it would still be a satisfactory solution.

I mean, what are you even rolling it out on Afrikaans Wiktionary and Arabic Wikipedia for if you're not going to support Afrikaans or Arabic?! The fact you chose them as pilot wikis tells me you weren't thinking this through. As long as you're using Google and don't intend to exclude dozens of widely spoken and minoritized languages, you have to make IPA optional.

If the goal was never to support generic text-to-speech, then you chose the wrong TTS. Google supports IPA in only a handful (18) of its supported languages/dialects, whereas Microsoft supports it in most (103) (though still saying "Always provide human-readable speech as a fallback"). The investigation seems to have overlooked this aspect.

But every single task in MediaWiki-extensions-Phonos is also tagged with Community-Tech except for this one, hence the question. @MusikAnimal's patch even indicates intention to work on it. @KSiebert If it is indeed your team's decision not to work on this, I'd like some explanation.

@dmaza So let me get this straight. You're saying that Phonos is going to stop supporting

@KSiebert Hi, what's going on? Are you removing all Phonos-related tasks from the CommTech board? If not, why just this one?

Looks like this is a deliberate change: T329300: "all read" notifications icons styled inconsistently in Vector 2022

But we're not officially supporting changing the playback rate, are we? I thought it was just one of myriad things you could exploit the hook for. So it makes little sense to me to single out playbackRate and prepare for its being modified, when there are countless other things the hook may be used for that make the default behavior unexpected.

Pretty sure this task is only about file="". Which indeed should be tracked, otherwise a file may be mistakenly deleted for being unused.

I think it should register as a file usage, not a mere link.

The rate change works for me on en-rtl too. Note the visual indication of progress with the animated background doesn't change even if you set playbackRate.

Good idea. There should be a list of supported phonemes/alphabets (or at least a link to TTS documentation with such a list) too.

Phonos does not support Chinese IPA because Google's text-to-speech, which Phonos relies on (on WMF sites), doesn't. It does accept Pinyin for Mandarin and Jyutping for Cantonese, however. The task for supporting them is T324109.

ext.pageTriage.util (which ext.pageTriage.util/models/ext.pageTriage.article.js is in) is required by ext.pageTriage.views.toolbar, which is defined in Hooks.php, not in extension.json. Perhaps ext.pageTriage.toolbarStartup should require it too?

That's my point: making them mutually exclusive entails assuming that all supported engines will assign unique names, and usually the less assumptions the better.

Do you think it would be a good idea to allow for both voice and lang? It seems that they should be mutually exclusive, but we can always prioritize voice selection when present.

In T322787#8450073, @dom_walden wrote:

TTS support for text only in phonos should fail with an error

A user can make IPA optional in a sense by using an IPA character not supported by Google, as it will ignore the unsupported IPA and just read the text.

For example:

<phonos ipa="#" text="blahblah" lang="en" />

It will ignore the # and just read blahblah.

The idea is to make it possible without a hack like this.

That's more or less intentional (the former video looks too similar to the latter but I assume that's due to the framerate). "Reduced motion" doesn't mean no motion. Just because the user has asked reduced motion doesn't mean they don't want the benefit of being able to see the progress (at least I certainly do, and I have prefers-reduced-motion on my phone), and the benefit is precisely greater for longer files. Of course the regular looks similar to the reduced when the file is long or the button is short, because there's not enough room for the animation to be smooth in the first place. It's the regular motion that's become similar to the reduced motion, not the other way around.

Is it worth making the label customizable? So that more specific details could be provided when required? e.g.

<phonos file="intro.mp3" aria-label="Listen to the opening bars of the piece" />

I doubt it given what @Graham87 said above. If it is not obvious what the audio is about without the label, then it's probably not obvious to sighted readers either. It couldn't hurt to make it customizable, but it might accidentally invite overexplanation that doesn't actually help screenreader users. Obviously deferring to Graham (or anyone else using screenreaders or with experience in accessibility development) though.

Doesn't look great on Firefox RTL.

Thanks for the feedback! Yes I used @wmui-color-accent90, the same as :hover.

T324102, which concerns a legal requirement, will likely entail converting PhonosButton to an extension of (or wrapping it in) ButtonGroupWidget and thus a CSS overhaul.

@JSengupta-WMF Can you comment on this? Even if you didn't think the feature as requested was a good idea, I think you'll agree that the UX leaves something to be desired, as the button barely changes when you click it unless you move the cursor away.

Note that when file= is used, the audio is not necessarily of a pronunciation.