- π³πΏNew Zealand quietone
In a slack discussion about β¨ Allow storing telephone number in E164 format Active catch suggested this be re-opened. He said that originally having field types in core meant people didn't have to find and download them. However, now with Project Browser and recipes those reasons are not so important.
- πΊπΈUnited States smustgrave
Following
I originally asked about deprecating this module because I feel most that use it have to use a contributed module like telephone_formatter to get it to work for them. Could be wrong buts been my experience
- π¬π§United Kingdom catch
We don't have many issues open against telephone, but β¨ Allow storing telephone number in E164 format Active would require either providing two telephone field types in one module to choose from (very confusing for UX) or hiding the current one and showing the new one with a possible migration path (potentially complex to implement), or moving the current field type to contrib and adding a the new one to core (also pretty complex). It's probably as much code to add or more than the current module has in total.
Given all of that, the previous assessment that telephone is low maintenance doesn't really hold any longer so I think this is worth looking at again. The fact that telephone formatter as 13,000 users also suggests that keeping telephone in core is not stopping people from having to add contrib modules to use it - potentially a contrib version could consolidate some of these things (the new storage format, validation, formatter etc.). I don't think this is used by Drupal CMS so trying to handle all of this in core doesn't seem right either.