* Add check for `phone-context`.
Add a check to PhoneNumberUtil that the value of the `phone-context` parameter of the tel URI follows the correct syntax as defined in [RFC3966](https://www.rfc-editor.org/rfc/rfc3966#section-3).
* Add check for `phone-context`.
Add a check to PhoneNumberUtil that the value of the `phone-context` parameter of the tel URI follows the correct syntax as defined in [RFC3966](https://www.rfc-editor.org/rfc/rfc3966#section-3).
* Add check for `phone-context`.
Add a check to PhoneNumberUtil that the value of the `phone-context` parameter of the tel URI follows the correct syntax as defined in [RFC3966](https://www.rfc-editor.org/rfc/rfc3966#section-3).
Remove unused leading_zero_possible field from phonemetadata.proto
Deleted all methods that refer to this.
Regenerated jars - because we no longer write a boolean for the removed proto field, all the java metadata files needed regenerating too.
Previously, building the demo (ant -f javascript/build.xml compile-demo) would fail because the latest build.xml is incompatible with the version of closure-compiler we recommend here. With this change, the build will work again.
Co-authored-by: Tijana Vislavski Gradina <tijanavg@google.com>
Earlier, AYTF is adding additional CC when returning unformatted result - for cases where the input digits are dropped for formatting. Eg: MX case: "+5213314010666" => "+52 +5213314010666". b/183053929
Now we. are proactively ensuring that no formatting is applied, where a format is chosen that would otherwise have led to some digits being dropped.
Why the input digits are dropped:
- In MX, the mobile token (1) is no more used, so when it is present in input, the formatted result should not contain it.
- However when AYTF, we should not be removing the input digits on the fly.
- More details in cl/373115460 and b/183053929