Gareth Bowen

I think that's a big improvement! I have no problem deprecating the old widget definition and maintaining it till the next major (or beyond if necessary). I imagine the code...

Sounds like `#3` is the way forward and definitely worth the investigation. Thanks @jkuester

If our implementation for db-doc didn't exist then I think `bind` would be more correct, and I'm not too concerned about compatibility with db-doc if we feel bind is right....

Okay. That's really painful! I think the answer is some form of (3). I have no strong preference now about whether we use the `cht_` convention or just drop it...

@dianabarsan Please add any details I've missed!

Removed the "affects" labels as this was never possible in CHT.

The [lib we use for formatting and validation](https://github.com/google/libphonenumber) has a function to `getNumberType` which returns one of these types: https://javadoc.io/doc/com.googlecode.libphonenumber/libphonenumber/latest/com/google/i18n/phonenumbers/PhoneNumberUtil.PhoneNumberType.html Should be reasonably easy to implement. I think I'd prefer...

We provide our own phone widget which validates against libphonenumber: https://github.com/medic/cht-core/blob/master/webapp/src/js/enketo/widgets/phone-widget.js I don't know how to indicate different validation modes, but maybe we can use `appearance`?

There's a solution being investigated for https://github.com/medic/cht-core/issues/8681 which includes the ability to pass parameters to widgets which I think would be helpful here too.

Removed the "affects" labels as the bug isn't a regression.