Another data point: Nobody seems to have been using it on Quarry so far.

The only entry I found is wikimedia-research/2018-10-Design-Research-mobile-research-samples github repo.

In T218349#5025671, @Framawiki wrote:

The only entry I found is wikimedia-research/2018-10-Design-Research-mobile-research-samples github repo.

Yes, some of the analytics work is in the separate wikimedia-research repo (search) and thus not covered by the GitHub search in the task description.

Here the tag is being used to calculate the monthly movement metrics - but I assume this would be easy to update (CC @Neil_P._Quinn_WMF ).

In T218349#5026073, @Tbayer wrote:

[...]

Here the tag is being used to calculate the monthly movement metrics - but I assume this would be easy to update (CC @Neil_P._Quinn_WMF ).

PS: just asked Neil in person and he confirmed it wouldn't be a concern.

Another thing to consider may be edit filters. I'm not even sure whether it is possible to include tags in edit filter rules, but in any case, at least on enwiki and dewiki, no filters seem to rely on the mobile web edit tag (admin access to view results).

In T218349#5026133, @Tbayer wrote:

PS: just asked Neil in person and he confirmed it wouldn't be a concern.

Just to clarify, it won't be a concern if your new tag covers everything currently tagged with mobile web edit (whether by backfilling the new tag or renaming the old tag). If instead you start setting a new tag and leave the old tag as is (which seems like it might be your plan), I would dislike that since all my analysis from now on will have to look for either tag instead of just one.

And, since we're revisiting the name of this tag, maybe we should change it to MobileFrontend or MobileFrontend action? This is perhaps a bit more confusing, but more accurate since (as I understand it) anyone who uses MobileFrontend, no matter what their device is, will have this tag applied.

In T218349#5026330, @Neil_P._Quinn_WMF wrote:

And, since we're revisiting the name of this tag, maybe we should change it to MobileFrontend or MobileFrontend action? This is perhaps a bit more confusing, but more accurate since (as I understand it) anyone who uses MobileFrontend, no matter what their device is, will have this tag applied.

Tags can be linked in the interface to an explanatory page, so that would help alleviate the confusion.

As for on-wiki uses by the general public:

After filtering out my own searches for the strings, web requests using with either mobile%20edit or mobile%20web%20edit are very rare [0].

+-------------+--------------------+----------------+
|      n      | n_mobile_web_edit  | n_mobile_edit  |
+-------------+--------------------+----------------+
| 8708164381  | 6                  | 12             |
+-------------+--------------------+----------------+

select
    sum(1) as n,
    sum(if(instr(uri_query, 'mobile%20web%20edit') > 0, 1, 0)) as n_mobile_web_edit,
    sum(if(instr(uri_query, 'mobile%20edit') > 0, 1, 0)) as n_mobile_edit
from
    wmf.webrequest
where
    year = 2019
    and month = 3
    and day = 14
    
    # Exclude MediaWiki Action API queries powering search autocomplete and associated EventLogging
    # instrumentation, and the same for Phabricator (?!). It's highly likely that this was me
    # searching mediawiki.org.
    and uri_query not like '%action=opensearch%'
    and uri_path != '/beacon/event'
    and uri_path != '/typeahead/class/PhabricatorSearchDatasource/'
;

@Neil_P._Quinn_WMF - Previously only article edits/file uploads were tagged with mobile web edit, mobile edit tags. We removed the extra IF statement that was causing the system to skip tagging different actions. Now all actions will be tagged with mobile web edit or mobile edit, the only requirement is that user has to be on the mobile site (we don't check the action type before we tag the action).

When I edit the message "tag-mobile_edit" i18n/en.json in MobileFrontend to say "Mobile web action" Special:RecentChanges updates to show the new label.

What is the problem statement here? Distinguishing old data from new data or updating how it appears in the interface? (the latter is easy but the former is a big undertaking and I want to check it's worth all that effort - from what I remember, when apps started using the tag, web didn't change their tag before for this reason).

In T218349#5028681, @Jdlrobson wrote:

[...]

What is the problem statement here? Distinguishing old data from new data or updating how it appears in the interface? (the latter is easy but the former is a big undertaking and I want to check it's worth all that effort - from what I remember, when apps started using the tag, web didn't change their tag before for this reason).

I understand it's the latter, although from the data analysis perspective it seems preferable to also rename it in the tables (it would be a permanent source of confusion if the tag's name there differs from its English name in the interface).

Or maybe I'm misunderstanding the question - distinguishing old data from new data is trivial after all, considering that the only difference is that the new version of the tag will encompass non-edits too, as @pmiazga explained above (T218349#5026951). Perhaps you meant something else?

• We announce that the tag will be renamed to wikitech-l, wikimedia-l, and on the technical village pump.

I don't think this is Wikimedia-l material. But a notice in Tech News would be a good idea.

In T218349#5028681, @Jdlrobson wrote:

When I edit the message "tag-mobile_edit" i18n/en.json in MobileFrontend to say "Mobile web action" Special:RecentChanges updates to show the new label.

What is the problem statement here? Distinguishing old data from new data or updating how it appears in the interface? (the latter is easy but the former is a big undertaking and I want to check it's worth all that effort - from what I remember when apps started using the tag, web didn't change their tag before for this reason).

I think that the main problem is that this tag is already translated and if we update the English translation, we need to convince translators to change all translations. Maybe we can remove all translations for tag-mobile_edit?

I think that the main problem is that this tag is already translated and if we update the English translation, we need to convince translators to change all translations. Maybe we can remove all translations for tag-mobile_edit?

I'm not sure I understand this. We can change en.json easily by a change to en.json in the repo. This will be syndicated to translators with the recommendation that this applies to things other than edits. Why is it a problem that tags are already translated?

From what I'm reading this is a trivial change (XS size, 0.5) which just needs a little communication. Am I missing something?

@Jdlrobson: Would changing the message require that any existing workflows are updated or would folk still have to refer to the tag by its name when querying the DB or specifying it as an argument for the tagfilter parameter in an MW API call, for example? That is, would the tag look like it was called "mobile web action" but still actually be called "mobile web edit"?

Create a run a maintenance script to update changes tagged with the ...edit tag

Do you think this should be a separate task? That might improve coordination with code changes. Is this something Readers Web should expect to build and execute or should the database team be involved?

It's not clear to me how to proceed with this task, this looks like a long task as we need to:

• create a new tag and start tagging everything with a new tag, then deploy to wikis
• during that time we will show both tags on Special:Tag page (the old one and the new one)
• create a maintenance script (I don't see anything like that), that will update the change_tag.ct_tag_id = NEW_ID where change_tag_ct.tag_id = OLD_ID. It also needs to update the change_tag_dev.ctd_count properly (don't miss edits that happened during maintenance script execution)
• run the maintenance script, and I'm afraid it can take ages for all wikis.

This whole maintenance process can take up like a week, plus most probably there are some edge cases are we ok with having two tags at the same time? Also, we need to do the same for both advanced mobile edit and mobile edit.

I don't think it's a good solution. the biggest table change_tag has ID's only, instead of updating all rows maybe it's just easier to update tag name in the DB, just run the query:
update change_tag_def SET ctd_name = 'mobile web action' where ctd_name = 'mobile web edit'
but then it has to be done during deployment window so code immediately starts using a new tag.
With that there will be no need to update all rows in change_tag table.

In case it wasn't clear I strongly recommend against rewriting this in the database - it's not worth the effort and potential loss of date. I think we should just update the translation.

I agree with @Jdlrobson that there's no point rewriting the database just to change the tag from "mobile web edit" to "mobile web action". For such a minor change, updating the display version of the tag (which can differ substantially from the database name: see w:en:Special:Tags for an example) is sufficient.

On the other hand, I still think that this tag should be renamed to "MobileFrontend" so it's more clear what this tag actually means and so that we have space to introduce a tag actually tied to device details if we want (translation might be a challenge, although we might be able to address that with the display name). In that case, I think it would be worth rewriting the database because having a tag whose meaning and display differed so much from its database name would be significant analytics debt.

However, that's probably an issue for another ticket 😁

My understanding is that tags can't be looked up by their translated name so existing references to "mobile web edit" would have to stay. Is that correct? For example, I only see messages being looked up for display purposes in https://github.com/wikimedia/mediawiki/blob/master/includes/changetags/ChangeTags.php (see ChangeTags::tagDescription and ::tagLongDescription).

Yeh i think urls would be the same but user interfaces would display the new label

In T218349#5066859, @Neil_P._Quinn_WMF wrote:

I agree with @Jdlrobson that there's no point rewriting the database just to change the tag from "mobile web edit" to "mobile web action". For such a minor change, updating the display version of the tag (which can differ substantially from the database name: see w:en:Special:Tags for an example) is sufficient.

In T218349#5081377, @phuedx wrote:

My understanding is that tags can't be looked up by their translated name so existing references to "mobile web edit" would have to stay. Is that correct?

Hmm, thanks for pointing this out. It looks like I'm actually wrong.

If I understand correctly, you're talking about a user filtering a list of revisions using a tag. The "new filters" used in the recent changes list and the watchlist allow you to browse and search a list of tags using the display names, so there, it's not an issue to have a difference between the display name and the database name.

However, in the old style changes list (used on Special:Contributions and by people who have opted out of the new filters), you have to type in the tag name used in the database, and there's not even a dropdown list to help you understand that. So if we just changed the tag's display name, users would have to know that, if you want to get a list of the edits with the tag "Mobile web action", you'd have to type in "mobile web edit".

In many ways, this is already an issue: to get edits tagged "Mobile web action", you have to type "mobile web action", case sensitive. Even worse, to get edits tagged "Visual edit", you have to type "visualeditor". Even worse than that is that situation on non-English wikis. For example, on the Arabic Wikipedia, to get edits tagged " تحرير مرئي", you have to type "visualeditor". You can see the mapping if you go to Special:Tags but it's still an awful user experience.

So we wouldn't be making the situation that much worse. But still, let's not do it.

Given this, I think there are only three viable options:

1. Leave the tag as is. "Mobile web edit" is not very wrong, applied to a log entry. I doubt many users would be (newly) confused.
2. Change the tag name in the database. Users would still have to relearn the secret tag incantation, but at least the secret incantation for "Mobile web action" would be "mobile web action", which is kind of easy to remember.
3. Fix the problem for good and let users search for tags by display names. Likely to be a significant amount of work and a distraction from your goals, although of course someone has to do it eventually.

My inclination is #1, given the relatively well-known complexity of #2 and the unknown-but-presumably-vast complexity of #3.

@ovasileva if we're not going to do this can we decline this bug? I'm assuming #3 is out at this point, so #1 and #2 are only viable options (and #2 less likely since I don't think we should be doing this post-deploy)

I think leaving it as is might make the most sense given the complexity. @MNeisler - any thoughts here from your side?

I agree that leaving the tag as is (Option #1) makes the most sense given the complexity and potential issues that might arise with the other options.