User Details
- User Since
- May 4 2020, 9:06 AM (119 w, 2 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- NGkountas (WMF) [ Global Accounts ]
Yesterday
Fri, Aug 12
Thu, Aug 11
Wed, Aug 10
Wed, Aug 3
Tue, Aug 2
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.
Mon, Aug 1
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.
Thu, Jul 28
Wed, Jul 27
This issue has been created as a regression from a patch that we merged last week. Will submit a patch about it today.
Jul 7 2022
Jul 1 2022
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:
Jun 30 2022
Jun 28 2022
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.
Jun 27 2022
Jun 15 2022
@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:
- 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.
Jun 14 2022
Jun 8 2022
Jun 6 2022
Jun 2 2022
May 30 2022
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.
May 27 2022
May 26 2022
May 20 2022
May 13 2022
Yes, it is quite a simple fix. I have it ready and will publish it today.