Set up shortcode(s) for sending SMS to USA and Canada

[philbooth]

The procedure for doing this is more convoluted than I realised it would be. We need to provide a business contact and implementation details for HELP and STOP messages.

It also requires a declaration that the campaign is TCPA compliant but the really tricky part is the requirement to specify the template text in advance, with no affordances for localization.

We could maybe try working round that by substituting the entire ${message} in to the template post-localization, but even then you have to provide a minimum of 10 characters for the rest of the message. Perhaps we could invert the interpolation and provide the link as the message body and and the localized message as the variable, i.e.:

${message}: https://mzl.la/1HOd4ec

Anyway, seems like we need to chat about this.

/cc @davismtl @shane-tomlinson

[philbooth]

To clarify, as I realise I didn't say it out loud, these are only requirements to send from a shortcode. We can still send to the USA and Canada without this stuff, if the sender id is a phone number.

[philbooth]

We could maybe try working round that by...

Or maybe we're fine with disabling localization for North American phone numbers? Makes it easier if that's an option.

[philbooth]

Oh, the other thing I didn't say out loud: I tried using the same shortcode as Fennec, 36698, but that gets rejected with the error Illegal Sender Address.

[philbooth]

Sorry about the link that used to be in the issue description btw. I just copied it from the admin form on Nexmo, without following it to see what it was. Turns out it was a sales pitch, I've deleted it now. 😊

[davismtl]

I'm thinking that the messages can be static (but one for every language) and then the URL is the one that will more likely be dynamic if we want to pass any parameters through it. (thinking of phase 3/4)

As a first step to this, I am not opposed to only releasing to EN-US/EN-CA.

[rfk]

I am not opposed to only releasing to EN-US/EN-CA.

I agree - we're trying to validate an idea here, let's scope it down to only en-us/en-ca users. If the results look promising, we can invest in more work on l10n, shortcodes, etc.

[philbooth]

I am not opposed to only releasing to EN-US/EN-CA.

I agree - we're trying to validate an idea here, let's scope it down to only en-us/en-ca users.

I can do this but just to be clear, it is literally more work than the alternative, which is to leave the branch in its current state.

If the results look promising, we can invest in more work on l10n, shortcodes, etc.

Evidently I failed to explain what this issue is all about. It exists mostly so I can say "this is why I didn't do the thing we agreed in Monday's front-end meeting". It's purely about shortcodes, any mentions of l10n are a red herring. The whole point of it was to speed things up, not slow them down. 😄

[rfk]

Do the thing that's the least work :-)

In my head all I see this boiling down to, is some config in the experiment code in the front-end that says "only enable this for en-US users for now".

[shane-tomlinson]

I agree - we're trying to validate an idea here, let's scope it down to only en-us/en-ca users.
I can do this but just to be clear, it is literally more work than the alternative, which is to leave the branch in its current state.

I was just going to say this @philbooth, thanks. Not adding the {{t}} tags now, and then adding them later is more work for us, in fact, we'd have to go back through both this repo and the content server and rip them all out. TBH, I'm fairly confident this feature is going to stick, I don't mind sending the few extra strings to l10n now to prepare.

[philbooth]

This was Nexmo-specific, closing.