Change Details

In T401194 we created a sub-page based recommendation provider that uses mock data stored on the `/tone.json` to the articles in question. This will mostly also work as-is in beta. However, for the production release, we will need to get this data from the (Staging) Data Gateway. That means we will need something similar to the `ServiceImageRecommendationProvider`/`ProductionImageRecommendationApiHandler`, except simpler, maybe we don't even need this separation into two classes for ReviseTone. The specific format we will get from the service is still TBD, but we can take inspiration from what is currently being discussed in T401021 and make detail adjustments later. **Open Questions:** * what to do if no URL is configured? **Acceptance criteria:** * [ ] By default, we load the recommendations from an internal service via a URL (to be configured in PHP settings) * [ ] We continue to use the Subpage-based provider on CI, patch-demo, and beta.

In T401194 we created a sub-page based recommendation provider that uses mock data stored on the `/tone.json` to the articles in question. This will mostly also work as-is in beta. However, for the production release, we will need to get this data from the (Staging) Data Gateway. That means we will need something similar to the `ServiceImageRecommendationProvider`/`ProductionImageRecommendationApiHandler`, except simpler, maybe we don't even need this separation into two classes for ReviseTone. The specific format we will get from the service will be what is currently being discussed in T401021: ``` wiki_id text, page_id bigint, model_version text, revision_id bigint, paragraphs set<tuple<text, int, float>>, ``` Similar to T407353#11290512, for this task it is important that the scaffolding is in place, less so that every last detail matches the yet-to-be-built ML pipeline and storage infrastructure. **Acceptance criteria:** * [ ] By default, we load the recommendations from an internal service via a URL (to be configured in PHP settings) * [ ] We continue to use the Subpage-based provider on CI, patch-demo, and beta.

In T401194 we created a sub-page based recommendation provider that uses mock data stored on the `/tone.json` to the articles in question. This will mostly also work as-is in beta. However, for the production release, we will need to get this data from the (Staging) Data Gateway. That means we will need something similar to the `ServiceImageRecommendationProvider`/`ProductionImageRecommendationApiHandler`, except simpler, maybe we don't even need this separation into two classes for ReviseTone. The specific format we will get from the service is still TBD, but we can take inspiration fromwill be what is currently being discussed in T401021 and make detail adjustments later.: **Open Questions:**``` * what to do if no URL is configured? wiki_id text, page_id bigint, model_version text, revision_id bigint, paragraphs set<tuple<text, int, float>>, ``` Similar to T407353#11290512, for this task it is important that the scaffolding is in place, less so that every last detail matches the yet-to-be-built ML pipeline and storage infrastructure. **Acceptance criteria:** * [ ] By default, we load the recommendations from an internal service via a URL (to be configured in PHP settings) * [ ] We continue to use the Subpage-based provider on CI, patch-demo, and beta.