Should we bother? Tabs are short. I currently can't see the end of the title for any of the (only!) five tabs open in the window I'm writing this in. If you put something at the start, it'd mean I couldn't see the actual topic of the page...

You could change the favicon, I guess? That's guaranteed to be seen. (Apart from in Safari pre-macOS11.)

It is definitely necessary, for example, at the end of the title, to add the full word "reply" or "editing". Now browsers, when the user writes text in the address bar, show hints and, in particular, show suitable names of open tabs. This ability of browsers to find a tab is worth using.

I think if you are replying to something you probably remember the topic of the page, to answer DLynch’s point, and in any case you can mouseover if needed. Some contexts let you see more of the tab title than others so there’s a “progressive enhancement” argument to be made there too.
This is a good idea, and it might as well say “Replying:” rather than “Editing” since that is the text of the button you click and will let us distinguish the tabs from an actual edit window.

I found this task from [[mw:Talk:Talk pages project/Replying#Page title doesn't show talk page is being edited]]. I would also lean toward “Replying:” or “Replying - ” rather than “Editing”.

Like GKFX, I think this should be prefixed: I'm unlikely to be replying in more than a couple of tabs at once, and I'd probably remember their relative positions. And like Nick mentioned at the linked discussion, we may often have multiple copies of the same page open, so the Replying marker would be more distinguishing than the page title.

Perhaps “Re:” if you wanted something shorter, would this work in other languages?

I don't sense others here have perhaps appreciated the frustration in not being able to determine which Wikipedia project talk page is open for editing amongst a plethora of identical-looking Tabs. In source editor, the Tab began '"Editing Wikipedia...' It's easy to be working with 20 tabs or more open, and it used to be easy to distinguish even the truncated letters "Ed." amongst a sea of other tabs all beginning "Wikip" and return quickly to that tab to continue working. But Reply tool - as wonderfully useful as it is - no longer give us that luxury of seeing that the page is active and being edited.
It is, to be frank, a bloody nuisance not to be able to determine which Tab you were on and quickly return to it. You try opening multiple sets of pages of policies and guidance pages in order to reply to just one newbie who needs help at the Teahouse and be unable to find the live edited page amongst the sea of identical-looking Tabs. At that's just one task amongst two or three one might be dealing with at any one time. Surely this is a quick fix? Anything to distinguish the actively edited (replied to) page will be most welcome. Anything!

See also T310977: Document title is prefixed with "Editing" after using both editor modes and using the back button to go to the "Read" tab. I was under the impression that the problem exists in some (not all) browsers, and that the solution is reloading the page, which is not really what we want to do with the Reply tool.

Change 821717 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Prefix browser title while replying/starting a new topic

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

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/06c5554a27/wiki/Talk:DiscussionTools

OK, I've gone to Patch demo to look, registered myself as a user (after missing the small print of the "Captcha" instructions and having to start again, frustratingly), and yes, it looks as if the problem is solved there: in my Firefox browser, the tab appears with "Starting..." or "Editing ..." as the leading characters.

Thanks: Looks good. I hope this can soon be implemented in the live software.

The patch above uses the messages:

• Replying on <pagename>
• Starting new topic on <pagename>

One could more specific with the "Replying" message, e.g. mentioning the topic or the author of the parent comment, however that would make the prefix much longer, and given the intended use of the feature is just to quickly see which tab is "active", I don't think it's necessary.

In T262066#8140449, @PamD wrote:

registered myself as a user

For others here, you should be able to test without registering or logging in, and for future reference the logins for Patch Demo are always the same and are documented here.

By typing part of the title in the browser's address bar, you can quickly switch to the tab. In Firefox, you can enter "reply" and the tab is shown - it works. But in Chrome, no results are shown for the "reply"; it will be shown if you enter part of the old title (for example, "patch") - is there any way to update the tab information for it too?

In T262066#8141706, @Sunpriat2 wrote:

By typing part of the title in the browser's address bar, you can quickly switch to the tab. In Firefox, you can enter "reply" and the tab is shown - it works. But in Chrome, no results are shown for the "reply"; it will be shown if you enter part of the old title (for example, "patch") - is there any way to update the tab information for it too?

That sounds like a browser bug.

are there any adjustments you'd like to see made to the naming of the browser tab prefixes before we move forward with implementing this?

@ppelberg looks perfect to me!
My only concern would be with internationalization – it is sort of tricky to translate "replying to" in French for instance but I don't really see any alternative in English.

In T262066#8180016, @nayoub wrote:

are there any adjustments you'd like to see made to the naming of the browser tab prefixes before we move forward with implementing this?

@ppelberg looks perfect to me!
My only concern would be with internationalization – it is sort of tricky to translate "replying to" in French for instance but I don't really see any alternative in English.

Internationalization: great call out. @nayoub: what about something more simple like what I've suggested below?

I appreciate that the language below might be a little bit less clear than "Responding to." Tho, I assume that this language will be: A) easier to translate and B) sufficient for people to differentiate between tabs that do and do not have the Reply or New Topic tool open within them.

I wouldn't want to introduce a new verb "Respond", that seems confusing.

Not also the message is "Replying on <page>" not "Replying to" - I don't know if that makes it easier. I think our translators are resourceful enough that if there is no sensible translation of "Replying on <page>" that they will mutate the message accordingly, e.g. "Reply: <page>". This has happened with the "Editing <page>" message where a few languages have added a colon after the verb. (In French it is "Modification de <page>")

Great point @Esanders! I agree that adding another verb could cause some confusion and +1 on the translation community finding the appropriate copy.

Meta: I updated task description to match language @Esanders proposed in T262066#8140521.

Change 821717 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Prefix browser title while replying/starting a new topic

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

✅ Initial state: <title>Talk:<pagename></title>

✅ Reply Tool state: <title>Replying on Talk:<pagename></title>

✅ New Topic Tool state <title>Starting new topic on Talk:<pagename></title>

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/06c5554a27/w/

I dunno, I'd say this is a known limitation rather than broken. It's not really documented, but it seemed like common sense. If you want DiscussionTools to work properly, then there are some limitations on MediaWiki:Pagetitle. Similarly, there are some limitations on MediaWiki:Timezone-utc, and various other ways of customizing the wiki.

We could detect this scenario and disable the modification of the title, but we would need to somehow make it really clear that it is not working because of on-wiki customization, and not due to a software bug, or we will forever be getting bug reports about it. I don't have a good idea for how to do that (and I feel that the current undesirable behavior communicates it quite well).

(I think I remember the same problem coming up in 2016 or so in the development of VisualEditor, and it being resolved by simplifying the on-wiki customizations. However, I can't find any task or on-wiki discussion about this, so I might be making this up. But either way, I was aware of the potential problem while reviewing this code, but I thought that it was already resolved in practice on all wikis years ago.)

In T262066#8882038, @matmarex wrote:

I dunno, I'd say this is a known limitation rather than broken. It's not really documented, but it seemed like common sense.

Documenting it and communicating it directly to the projects affected would turn it into a known limitation, sure. But MediaWiki:Pagetitle is both documented to take wikitext and customising the page title using it has worked perfectly fine in the core platform for at least a decade. There is nothing common sense or obvious about the fact that Reply tool has used an API with severe limitations in its implementation.

Incidentally, these limitations of the Messages API are also pretty weird from an API design perspective. Implementation-wise, sure, I get that feature parity could be really difficult to implement safely and robustly; but not supporting most basic wikitext features in text loaded from wiki pages is rather non-intuitive (well-documented though, which pardons most sins). Especially since you can feed the output to action=parse or action=expandtemplates and get rendered output back.

Similarly, I think "If you want to use Reply tool at all you have to remove this functionality (that you've used for a decade and is quite important for your project) because one of its incidental features doesn't work with it" is a rather bad tradeoff to sell. Saying "If you want dynamic titles in Reply tool you'll have to limit your MediaWiki:Pagetitle to what's supported by the Messages API, but the core functionality of Reply tool will work just fine" is a completely different message (and one I can actually sell).

We could detect this scenario and disable the modification of the title, but we would need to somehow make it really clear that it is not working because of on-wiki customization, and not due to a software bug, or we will forever be getting bug reports about it.

I think you have this completely backwards: modifying the title is an optional value-add functionality (don't get me wrong, I agree that it is desirable and important in isolation), but the behaviour when MediaWiki:Pagetitle has been customised is actually broken. Not modifying the title is an obvious and common sense "known limitation", but…

I feel that the current undesirable behavior communicates it quite well).

…I don't think spewing what amounts to line noise at end users is an acceptable failure mode (much like raw exceptions, stack traces, or core dumps); and that line noise and JS console messages communicates nothing well except that "Reply tool is broken".

I'm a fairly technical user (and above-averagely invested in how the moving parts of MW hang together), and I never twigged that this issue could be related to any on-wiki customisations. That didn't become clear until I went to report a different problem that I suspect could be a run-on from this problem (when there is a fragment identifier in the URL, because you went straight to a section, Reply tool will remove focus from the text field after each character you type) and found T317600.

(I think I remember the same problem coming up in 2016 or so in the development of VisualEditor, and it being resolved by simplifying the on-wiki customizations. However, I can't find any task or on-wiki discussion about this, so I might be making this up. But either way, I was aware of the potential problem while reviewing this code, but I thought that it was already resolved in practice on all wikis years ago.)

From T317600#8880433 it doesn't appear grepping for these uses is prohibitively expensive (I haven't tried myself, but even if "someone was wrong on the Internet" I don't imagine that could have taken long to find). When a feature relies on secondary API (JS vs. PHP) with well-known limitations I don't think checking what's going to break on the projects is too onerous an expectation. Discovering that before deploying and talking to the affected communities (form and scope depending on specific circumstances) is kinda important IMO.

Eh, alright, I think you have me convinced. It should be fine to just disable this feature when the customized message is not compatible with the limited parser.

Final thoughts:

In T262066#8884519, @Xover wrote:

In T262066#8882038, @matmarex wrote:

Incidentally, these limitations of the Messages API are also pretty weird from an API design perspective. (…) Especially since you can feed the output to action=parse or action=expandtemplates and get rendered output back.

From a design perspective, I think doing that is rarely a good idea. It's not big deal to do it once or twice, but if it gets used in too many places, you end up with an application that has to contact the server constantly to respond to every user action. Additionally, it requires using async functions everywhere that depends on the message being available, which makes them impossible to use from code that has to be sync for some other reason. I think this is why we should avoid it.

(There are also some implementation caveats to resolve, e.g. those API actions don't support the {{GENDER:|…}} syntax referring to the current user, as that's only allowed in localisation messages.)

(It's a better idea if the message has no parameters and don't depend on context like {{PAGENAME}} or {{GENDER:|…}}, since it can be baked into the JS code, and we do that in a few places, e.g. https://gerrit.wikimedia.org/g/mediawiki/core/+/c4de31c2e6d4cf1f527273ecbd6bce83a975908c/resources/Resources.php#1273)

… I went to report a different problem that I suspect could be a run-on from this problem (when there is a fragment identifier in the URL, because you went straight to a section, Reply tool will remove focus from the text field after each character you type) …

I can't reproduce that, please file a task with more details (unless this is already resolved).

(I think I remember the same problem coming up in 2016 or so in the development of VisualEditor …)

From T317600#8880433 it doesn't appear grepping for these uses is prohibitively expensive …

It's easy now with https://global-search.toolforge.org/ (since mid-2019).