User Details
- User Since
- Jan 30 2019, 8:58 PM (226 w, 5 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Nardog [ Global Accounts ]
Today
They're even looking to expand this to all namespaces, see T313636#8174638 and T315893.
Sat, Jun 3
Fri, Jun 2
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.
Thu, Jun 1
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.
Fri, May 26
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.
Thu, May 25
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.
Wed, May 24
@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.
Sat, May 20
Seems to have caused T337081: "Add interlanguage link" shows a bubble: "An unknown error occurred"
The skin doesn't seem to matter.
Thu, May 18
The obvious solution to me is to save the preference only when the checkbox is clicked (i.e. not through the URL).
Fri, May 12
Thu, May 11
Tue, May 9
May 1 2023
Apr 29 2023
Apr 18 2023
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?
Apr 16 2023
Likely caused by this change:
Apr 15 2023
Apr 11 2023
Why is T334518 the parent task? Did you mean the other way around?
Apr 5 2023
@Umherirrender @matej_suchanek Can you please look into T148533 as well?
Apr 3 2023
Apr 2 2023
Mar 31 2023
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.
Mar 30 2023
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?).
Mar 28 2023
Mar 23 2023
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.)
Mar 22 2023
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.
Mar 14 2023
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.
Mar 10 2023
Mar 9 2023
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
Mar 8 2023
@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
Mar 7 2023
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.
Mar 4 2023
Pretty sure this task is only about file="". Which indeed should be tracked, otherwise a file may be mistakenly deleted for being unused.
Mar 2 2023
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.
Mar 1 2023
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.
Feb 28 2023
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.
Feb 27 2023
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.
Feb 26 2023
Doesn't look great on Firefox RTL.
Thanks for the feedback! Yes I used @wmui-color-accent90, the same as :hover.
Feb 24 2023
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.
Feb 22 2023
Note that when file= is used, the audio is not necessarily of a pronunciation.