As at the posting of this comment, the conversation on GitHub with the OSM team has stalled. From the screenshot below demonstrates using an message box notice to inform and potentially direct these queries to OpenStreetMaps GitHub issues page when a user is in the process of creating an issue on Translating talk:OpenStreetMap.

Use 10 month blocks to chart the trend of notifications. https://jsoneditoronline.org/

What is the criteria for the IME icon being shown?

The number of notifications sent prior to the implementation of T323192, i.e July 2023 on:

• Meta: 385
• Mediawiki: 54
• Commons: 21

I believe this ticket should not be tagged with`ContentTranslation` project.

We should show information to the user about the status of the page i.e discouraged, and prevent submission of the form in such a case. We can use this approach to prevent scope creep with the filtering logic within the Entity Selector.

I think having an INFO file outside the tarball would provide a shorter path to reading the file without having to download a whole 2GB of data just to find out that it may not be useful. Both these files can sit inside a directory with the name twn-translation-dump. A simpler alternative would be to add the date to the name of the tarball. Something like twn-translation-dump-29-04-24.tar.gz.

Result of the suggestions above:
Vector 2022

This issue still exists as of the posting of this comment.

Mobile (Chrome - Android)	Desktop browser (Chrome - MacOS)

In T311521#9716746, @abi_ wrote:

Its only visible when the user hovers over the source text or tabs to select it.

As a prototype, I have a WIP patch that accomplishes this functionality. The buttons, in my opinion, seem a bit much but may be necessary in their layout. (Ignore the color of the icon, I think a monochrome version of it would be ideal). Additionally, I'd like @Nikerabbit , @Pginer-WMF to weigh in on this layout.

In T348516#9679625, @Nikerabbit wrote:

What's the destiny of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/976192?

@Pginer-WMF: I think we are arriving at a consensus on what we want to track.

We'll be following up this task with T361138. Story points have been reduced to 4 as we didn't have to use so much of Codex components.

The project is now available for translation here https://translatewiki.net/wiki/Special:Translate/mwgithub-themetoggle

Project has been added and translation exports will happen tomorrow.

This issue was fixed in this patch. Additional side effects such as fixing this border issue resulted in a border disappearing in the pick a sentence step 'Done' button is also no longer an issue.

Does https://gitlab.wikimedia.org/l10n-bot have commit access to this project? If not, it would be important to add the bot so that the project receives localization updates.

We now have an open Github issue for this task on OpenStreetMap.

Are you referring to switching to json/yaml? If so, please go ahead as this would enable us to support you better.

translatewiki.net does not support the PHP format for translations currently used by your project. See list of supported file formats.

SearchSuggest exists in MW Core so It would make sense to update it to a Vue component there instead of on the Translate extension. The diff is generated from the compare API as well; meaning that there's no additional work related to Vue on Special:PagePreparation

Translatewiki requires all languages be in their own individual files. See example here: https://github.com/wikimedia/jquery.uls/tree/master/i18n.

The hook Translate:GettextFFS:headerFields was soft deprecated and later in hard deprecated in favor of adding an interface, GettextFormatHeaderFieldsHook.php, that will triggered using the HookRunner. Hook interfaces were added in Mediawiki 1.35 --> T338451

These tags are now available on Wikidata tags. However, no activity is being registered. After some investigation by @ngkountas, it turns out that this might be user rights issue.

Tested: When a user clicks on 'Unsubscribe', the preferred contact methods remain intact while the contact frequency is changed to 'none' which is in line with the design requirements of this ticket. The FAQ section on MediaWiki:Translatorsignup-summary was also updated to remove the section describing how to unsubscribe from translation notifications.

The second patch to incorporate the none' contact frequency option is now available on https://www.mediawiki.org/wiki/Special:TranslatorSignup

The existing message from translationnotifications-email-body and translationnotifications-digestemail-body were taken up. Changing the translationnotifications-talkpage-body message would prompt changing the others for consistency reasons.

This is the view of the new message.

The first patch to incorporate the 'Unsubscribe' button on this ticket was deployed on Meta: https://meta.wikimedia.org/wiki/Special:TranslatorSignup

After TranslateWiki deployment, the icons appear as below. This link showcases the changes implemented from this ticket

In T335256#9205834, @Zache wrote:

Is CX is using wblinktitles API for adding languagelinks?

• https://www.wikidata.org/w/api.php?action=help&modules=wblinktitles

If so one clean method could be adding tags parameter to wblinktitles API similar to other wikibase edit API calls (see wbeditentity , wbsetsitelink)

• https://www.wikidata.org/w/api.php?action=help&modules=wbsetsitelink
• https://www.wikidata.org/w/api.php?action=help&modules=wbeditentity

Then ask wikidata admins to register the changetag use it when adding the langlink.

Users could edit it which is little bit annoying, but not really something what nobody cares.

From my understanding the patches above were abandoned because regardless of the fact that we can use`wbsetsitelink` API, these change_tags will still have to be registered on Wikidata to show up. I think the easiest route will be to contact a Wikidata admin to register these tags. Thus, we don't need to use this API as a hack to achieve this.