Since the integration of section translations into parallel corpora, the section translations that create a new article (by translating the lead section) are also stored inside cx_translations table. This means that the recent translation entrypoint will work for section translations without any further effort from our side. Moving this ticket to "Needs QA".

@santhosh does this ticket needs QA or the issue is not yet fixed?

As demonstrated by the following screencast this issue seems to be currently fixed. The test case is exact the same that Emeka used in the previous screencast. Another issue appears, as the link redirects to an invalid URL but we can create a separate task for this one. Moving this one to "Needs QA" so that it can be verified.

This ticket is expected to be fixed by the work submitted in T314392.

Following the latest patches and after the tests, the status of the instrumentation of the entrypoints is displayed in the following table:

The instrumentation of the entrypoint when creating a new article on mobile is currently missing and this issue will fixed in a following patch.

The missing frequent languages entrypoint is NOT properly instrumented as displayed in the following screencast. The campaign URL parameter is wrongfully set to "mfmissinglanguages" instead of mffrequentlanguages and as a result the dashboard_open and dashboard_translation_start events are logged with the generic direct_preselect event source instead of the frequent_languages event source. This will be fixed in a upcoming patch.

The mobile language selector entrypoint is instrumented properly. As we can check in the screencast below, the campaign URL parameter is correctly set to mflanguagesearcher and the dashboard_open and dashboard_translation_start events are properly logged with the event source set to content_language_selector.

Recent translation entrypoint is instrumented properly, as shown in the screencast below. As we can observe, the campaign URL parameter is properly set to mfrecenttranslation
and the event source of dashboard_open and dashboard_translation_start events, is properly set to recent_translation.

This issue has been created as a regression from a patch that we merged last week. Will submit a patch about it today.

After some investigation I noticed that this issue happens only when exactly one appendice section exists inside the target article. The reason behind it is that for some reason the section contents of the appendice section appears in the PHP backend to also contain the categories. More specifically, during my investigation I tested the "Brunei" article for the (en/gu) language pair. I dumped the contents of the first section of the Brunei article in gu and the results were:

To add to the second question, this is something that happens in some (relatively rare) cases, where the source templates miss a template definition. In this specific case for example, although the source template has an "about" attribute and thus is recognized as a block template by our code, it doesn't hold any template definition (no "mw" data attribute) and the source template name is not available. This is the reason why it's not displayed in the screenshot. For sure this is not desirable, but there is a lot of room for such kind of improvements in block templates, so that we can safely support all unique cases.

@MNeisler your draft steps are indeed very close to the actually needed ones. @EChukwukere-WMF in order to have the events shown up in the console you'll need:

1. Activate event logging in target wiki (e.g. bn wiki) by running the following command in the console (inside the target wiki):

The above issue mentioned by @Pginer-WMF is resolved in the upcoming patch.

Wikipedia preview component could be used to support this feature but it would bring an increase of 46.1kb (when minified + gzipped) in size - according to bundlephobia.com -, which is probably not acceptable for this case.

Yes, it is quite a simple fix. I have it ready and will publish it today.