* 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).
* 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.
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.
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
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
* Updates the type annotations in phonenumberutil.js
Updates the type annotations to indicate the inputs are required to be non-null.
* Update pending_code_changes.txt
* Update pending_code_changes.txt
* Updates the type annotations in phonenumberutil.js
Updates the type annotations to indicate the inputs are required to be non-null.
* Update pending_code_changes.txt
* Update pending_code_changes.txt
* Adding checking of leading digits before using an alternate format rule
when finding phone numbers in text (previously we thought this was done, hence why the data was there, but it wasn't).
Also some minor comment/formatting changes, and splitting a private helper method
into two.
* Adding checking of leading digits before using an alternate format rule
when finding phone numbers in text (previously we thought this was done, hence why the data was there, but it wasn't).
Also some minor comment/formatting changes, and splitting a private helper method
into two.
The format of the data has changed such that formatting patterns now only refer to \d, not specific numbers, so we don't need the special handling in the AYTF code which converts them to \d.
The format of the data has changed such that formatting patterns now only refer to \d, not specific numbers, so we don't need the special handling in the AYTF code which converts them to \d.
rohininidhi
Silvio Brändle
mandlil
openvcdiff
kkeshava
Fabrice Berchtold
katbohm
penmetsaa
rohininidhi
tmarek-google
Doug Roeper
lararennie
AlipmanG