Change Details

Currently the fundraising json structure supports a client-side parameter called `$platform;`, which gets replaced by the respective client with the corresponding platform name (Android / iOS). This is used in the action `url` string for filling in the platform name for analytics purposes. We propose adding the following additional parameters: * **`$formattedId;`** -- which would take the place of the entire value of the current `wmf_source` url parameter. The notion of "formatted ID" is already something that is firmly established within our code. Specifically, the formatted ID is a string that is made up of these components: `[language][country]_[campaignID]_[platform]`. So then, the formatted ID effectively becomes something of this form: `enUS_US_2025_Android`. But if you look closely at the `url` parameters specified in the current campaign configuration, this is //exactly// what the `wmf_source` parameter is trying to be. Except currently, the `wmf_source` parameter must be manually composed by the creators of the campaign structure, which can lead to errors and inconsistencies such as observed in T415692. If we introduce a `$formattedId;` parameter, and simply plug it into the url as `wmf_source=$formattedId;`, the authors of the campaign configuration will no longer need to worry about composing it properly, and will eliminate this class of bugs. * **`$country;`** -- replaced by the current GeoIP country of the client. * **`$language;`** -- replaced by the current language selected by the client. * **`$appVersion;`** -- replaced by the current app version string. * **`$appInstallId;`** -- replaced by the current app install ID.

Currently the fundraising json structure supports a client-side parameter called `$platform;`, which gets replaced by the respective client with the corresponding platform name (Android / iOS). This is used in the action `url` string for filling in the platform name for analytics purposes. We propose adding the following additional parameters: * **`$formattedId;`** -- which would take the place of the entire value of the current `wmf_source` url parameter. The notion of "formatted ID" is already something that is firmly established within our code. Specifically, the formatted ID is a string that is made up of these components: `[language][country]_[campaignID]_[platform]`. So then, the formatted ID effectively becomes something of this form: `enUS_US_2025_Android`. But if you look closely at the `url` parameters specified in the current campaign configuration, this is //exactly// what the `wmf_source` parameter is trying to be. Except currently, the `wmf_source` parameter must be manually composed by the creators of the campaign structure, which can lead to errors and inconsistencies such as observed in T415692. If we introduce a `$formattedId;` parameter, and simply plug it into the url as `wmf_source=$formattedId;`, the authors of the campaign configuration will no longer need to worry about composing it properly, and will eliminate this class of bugs. * **`$country;`** -- replaced by the current GeoIP country of the client. * **`$language;`** -- replaced by the current language selected by the client. * **`$appVersion;`** -- replaced by the current app version string. * **`$appInstallId;`** -- replaced by the current app install ID. We are also agreeing that this would necessitate bumping the structure version number to **3**.

Currently the fundraising json structure supports a client-side parameter called `$platform;`, which gets replaced by the respective client with the corresponding platform name (Android / iOS). This is used in the action `url` string for filling in the platform name for analytics purposes. We propose adding the following additional parameters: * **`$formattedId;`** -- which would take the place of the entire value of the current `wmf_source` url parameter. The notion of "formatted ID" is already something that is firmly established within our code. Specifically, the formatted ID is a string that is made up of these components: `[language][country]_[campaignID]_[platform]`. So then, the formatted ID effectively becomes something of this form: `enUS_US_2025_Android`. But if you look closely at the `url` parameters specified in the current campaign configuration, this is //exactly// what the `wmf_source` parameter is trying to be. Except currently, the `wmf_source` parameter must be manually composed by the creators of the campaign structure, which can lead to errors and inconsistencies such as observed in T415692. If we introduce a `$formattedId;` parameter, and simply plug it into the url as `wmf_source=$formattedId;`, the authors of the campaign configuration will no longer need to worry about composing it properly, and will eliminate this class of bugs. * **`$country;`** -- replaced by the current GeoIP country of the client. * **`$language;`** -- replaced by the current language selected by the client. * **`$appVersion;`** -- replaced by the current app version string. * **`$appInstallId;`** -- replaced by the current app install ID. We are also agreeing that this would necessitate bumping the structure version number to **3**.