Update jquery.intl-tel-input to v23.0.10 and add option for i18n

On webform.element.telephone.js#L51 is used: "localization"

var localization = $telephone.attr('data-webform-telephone-international-i18n');

On /src/Plugin/WebformElement/Telephone.php#L194 is used: "localisation"

'#title' => $this->t('Code language for localisation of country names'),

Please correct me if I'm mistaken but seems that both are correct depending the region, like British English and American English, right?

If yes, it's ok but I'd suggest to choose one to be consistent and avoid mixing both. As the same approach of Drupal Coding Standards that allows more than one option but recommends to choose one and avoid mixing:

Variables should be named using lowercase, and words should be separated either with uppercase characters (example: $lowerCamelCase) or with an underscore (example: $snake_case). Be consistent; do not mix camelCase and snake_case variable naming inside a file.

If possible I'd suggest "localization" that is already in use at webform.install.update.inc#L2355

I've noticed that the build path for the index.js file is not correct, there is a '/' missing in the Telephone.php file (line 129).
I also noticed the Javascript actually breaks as /libraries/jquery.intl-tel-input/build/js/intlTelInputWithUtils.min.js is never imported in the libraries file, this ended up breaking the entire patch pretty much.

It would also be beneficial, as we are trying to translate countries for accessability reasons, to always translate them to the current language of the page (especially when a language switch is available).
This could also be a checkbox 'use site default language' and hide the field for the langcode when checked.

I hope this is helpful feedback.

~ Josh

I've created a (temporary) patch that fixes the issues mentioned in my previous comment and adds default behavior to use the current site language as the render language when the langcode field is not explicitly set.

I applied the patch to my site, but the country flags stopped showing before the phone number, so something is wrong.

@Sneezycheesy Sorry for the confusion, I checked everything again today and the patch works great. Also, I upgraded the version in your patch to the latest version equal to 24.1.1.

I found the source of the problems from comment #8. The Webform module tries to load a translation file for the `intl-tel-input` library based on the selected language. However, if the selected language is not supported by the library, the module cannot load the necessary file, leading to missing translations and potential errors. I have therefore added the loading of the English version in such a situation.

Please make the changes on the merge request. This allows tests to be run.

Hi folks, I've attached a patch for the webform.element.telephone.js file, adding additional options to the telephone element component.

Seems to work! Thanks

Resolved merge conflicts, but tests are failing. :(

Here's a Composer-friendly patch for 6.2.x.

Doesn't work for 6.3.0-beta2. Here's a patch for that.

I’ve merged the 6.3.x branch into this one and fixed some PHPCS issues.

Since there were other implementations already merged into 6.3.x that affect webform.element.telephone.js, I had to apply the following patches locally to get everything working properly:
#3458484: Provide option to disable default Js validation on Telephone element
#3519674: Telephone validation issues when using states and pages

In intl-tel-input version v24.0.0 some parameters are functions - Ref: https://github.com/jackocnr/intl-tel-input/blob/v24.0.0/demo.html
For leveraging the #3493832: Allow custom data-options to be added to elements JavaScript options, I'm adding a way to convert the data attribute from string to function before passing the options to the intlTelInput instance.

Hey, sorry if this is somewhat brash, I'm a bit new to this.

I know that creating a string to function converter would allow to better use #3493832: Allow custom data-options to be added to elements JavaScript options, but it seems like it might be a bit difficult to manage the security of it and seems like a bit of a scope creep for this issue.

Instead, could we roll back the changes with the eval() function and work on getting tests to pass, then create another feature request to support this through something like a standardized event that can hooked into like mentioned in #3493832-7: Allow custom data-options to be added to elements JavaScript options. Alternatively, when #3464861: Webform asset javascript (webform/javascript/webform_id/custom.js) is showing not found is resolved users should be able to just add a custom JS script in to the webform config that can add functions to `Drupal.webform.intlTelInput.options`

I've included a patch file that doesn't have the parsing functions.

Hello, one more update. Found that the "withUtils" script was being attached as part of the webform library, however, it's recommended (and is already setup) to lazy load the utils script after page load, so I've updated the patch to also remove that. Also, I've put up an interdiff with the current HEAD of the branch.

Thank you.

Please add your changes to the merge request.