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. Also, as opposed to how we do it for ImageRecommendations, for ReviseTone we will not need caching here since we only make a single request to the endpoint. We will add monitoring for the performance of this in T407031 and might add caching later, if we learn that we need it. 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. Also, as opposed to how we do it for ImageRecommendations, for ReviseTone we will not need caching here since we only make a single request to the endpoint. We will add monitoring for the performance of this in T407031 and might add caching later, if we learn that we need it. The request format will be `/public/ml_cache/paragraph_tone_scores/{wiki_id}/{page_id}/{revision_id}`. The responses will look like: ```lang=json { "rows" : [ { "content" : "rain in spain", "idx" : 0, "model_version" : "v1", "page_id" : 1, "score" : 0.2, "revision_id" : 10, "wiki_id" : "enwiki" }, { "content" : "falls mostly on the plains", "idx" : 1, "model_version" : "v1", "page_id" : 1, "score" : 0.3, "revision_id" : 10, "wiki_id" : "enwiki" }, { "content" : "rain in spain", "idx" : 0, "model_version" : "v2", "page_id" : 1, "score" : 0.5, "revision_id" : 10, "wiki_id" : "enwiki" }, { "content" : "falls mostly on the plains", "idx" : 1, "model_version" : "v2", "page_id" : 1, "score" : 0.6, "revision_id" : 10, "wiki_id" : "enwiki" } ] } ``` 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. Also, as opposed to how we do it for ImageRecommendations, for ReviseTone we will not need caching here since we only make a single request to the endpoint. We will add monitoring for the performance of this in T407031 and might add caching later, if we learn that we need it. The specificrequest format we will get from the service will be what is currently being discussed in T401021:be `/public/ml_cache/paragraph_tone_scores/{wiki_id}/{page_id}/{revision_id}`. ```The responses will look like: ```lang=json wiki_id text,{ page_id bigint,"rows" : [ model_version text, { revision_id bigint, "content" : "rain in spain", "idx" : 0, "model_version" : "v1", "page_id" : 1, "score" : 0.2, "revision_id" : 10, "wiki_id" : "enwiki" }, { "content" : "falls mostly on the plains", "idx" : 1, "model_version" : "v1", "page_id" : 1, "score" : 0.3, "revision_id" : 10, "wiki_id" : "enwiki" }, { "content" : "rain in spain", "idx" : 0, "model_version" : "v2", "page_id" : 1, "score" : 0.5, "revision_id" : 10, "wiki_id" : "enwiki" }, { "content" : "falls mostly on the plains", "idx" : 1, "model_version" : "v2", "page_id" : 1, "score" : 0.6, "revision_id" : 10, "wiki_id" : "enwiki" } ] } 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.