Docs update (#2792)

* Fixing anchors

Co-authored-by: penmetsaa <penmetsaa@google.com>

FAQ.md

@@ -1,8 +1,8 @@
 # Frequently Asked Questions (FAQ)
 
-## <a href="#parsing"/>Parsing
+## <a href="#parsing">Parsing</a>
 
-### <a href="#country_code_not_removed"/>Why wasn't the country code removed when parsing?
+### <a href="#country_code_not_removed">Why wasn't the country code removed when parsing?</a>
 
 In some cases, the library cannot tell if the leading digits of a phone number
 are intended to be the country calling code, or the start of the national
@@ -18,7 +18,7 @@ If you know that your numbers are always in the form &lt;country calling
 code&gt;&lt;national significant number&gt;, it is safe to put a "+" in front to
 indicate this to the library.
 
-### <a href="#non_digits"/>Why does the library treat some non-digit characters as digits?
+### <a href="#non_digits">Why does the library treat some non-digit characters as digits?</a>
 
 When parsing, the library does its best to extract a phone number out of the
 given input string. It looks for the phone number in the provided text; it
@@ -52,7 +52,7 @@ Other examples, in reports:
 *   [#1199](http://github.com/google/libphonenumber/issues/1199)
 *   [#1813](http://github.com/google/libphonenumber/issues/1813)
 
-### <a href="#prefix_not_removed"/>Why wasn't the national prefix removed when parsing?
+### <a href="#prefix_not_removed">Why wasn't the national prefix removed when parsing?</a>
 
 Usually, when parsing, we remove a country's national or trunk prefix, so we can
 store a normalized form of the number. This is usually, but not always, a
@@ -72,7 +72,7 @@ part of the national number:
     when formatting since other short-codes do not, and we would be irreparably
     changing the phone number.
 
-### <a href="#parsing_idds"/>Why wasn't `00` parsed the same as `+`?
+### <a href="#parsing_idds">Why wasn't `00` parsed the same as `+`?</a>
 
 `00` is not an international prefix (IDD) in every region, so it's not
 equivalent to `+`.
@@ -91,22 +91,22 @@ You can try [the demo](http://libphonenumber.appspot.com/) for more regions.
 Also see `internationalPrefix` in
 [`resources/PhoneNumberMetadata.xml`](http://github.com/google/libphonenumber/blob/master/resources/PhoneNumberMetadata.xml).
 
-## <a href="#validation"/>Validation and types of numbers
+## <a href="#validation">Validation and types of numbers</a>
 
-### <a href="#possible_vs_valid"/>What is the difference between isPossibleNumber and isValidNumber?
+### <a href="#possible_vs_valid">What is the difference between isPossibleNumber and isValidNumber?</a>
 
 To understand the behavior of functions, please refer to the documentation in
 the Javadoc/C++ header files. For example, see `isPossibleNumberWithReason` in
 [`PhoneNumberUtil`](https://github.com/google/libphonenumber/blob/master/java/libphonenumber/src/com/google/i18n/phonenumbers/PhoneNumberUtil.java).
 
-### <a href="#short_numbers"/>Why does PhoneNumberUtil return false for valid short numbers?
+### <a href="#short_numbers">Why does PhoneNumberUtil return false for valid short numbers?</a>
 
 Short numbers are out of scope of
 [`PhoneNumberUtil`](https://github.com/google/libphonenumber/blob/master/java/libphonenumber/src/com/google/i18n/phonenumbers/PhoneNumberUtil.java).
 For short numbers, use
 [`ShortNumberInfo`](https://github.com/google/libphonenumber/blob/master/java/libphonenumber/src/com/google/i18n/phonenumbers/ShortNumberInfo.java).
 
-### <a href="#what_is_valid"/>What does it mean for a phone number to be valid?
+### <a href="#what_is_valid">What does it mean for a phone number to be valid?</a>
 
 Our phone number library can tell that a number range is valid when there is
 sufficient official documentation, with some latency after this fact is brought
@@ -122,7 +122,7 @@ phone call with a verification code). This is not technically feasible without
 such a verification step given the complicated international world we live in,
 with varying standardization practices in different regions.
 
-#### <a href="#why_not_valid"/>But my dialled number connected, so isn't it valid?
+#### <a href="#why_not_valid">But my dialled number connected, so isn't it valid?</a>
 
 Not necessarily.
 
@@ -135,7 +135,7 @@ Not necessarily.
     US are not valid, because without the rest of the number it is impossible
     for the library to canonicalize this.
 
-### <a href="#isvalidnumberforregion"/>When should I use isValidNumberForRegion?
+### <a href="#isvalidnumberforregion">When should I use isValidNumberForRegion?</a>
 
 Rarely! Many people have phone numbers that do not belong to the country they
 live in. This applies particularly to mobile numbers, but may also be true
@@ -149,7 +149,7 @@ One use-case where this method may be useful is if you want to see if a
 `FIXED_LINE` number for a business matches the country it is in, to try and spot
 data errors.
 
-### <a href="#incorrect_formatting"/>Some "valid" numbers are not formatting correctly.
+### <a href="#incorrect_formatting">Some "valid" numbers are not formatting correctly.</a>
 
 This could be due to number simplification. In order to keep the size of the XML
 files to a reasonable level, it's necessary in some regions (e.g. "DE" or "AT")
@@ -167,27 +167,27 @@ information to cover these numbers as well, it's a rather non-trivial task
 valid ranges with different formats). Note that this also applies to attributes
 like "national only" or geocoding information.
 
-### <a href="#sms_sending"/>What types of phone numbers can SMSs be sent to?
+### <a href="#sms_sending">What types of phone numbers can SMSs be sent to?</a>
 
 SMSs can be sent to `MOBILE` or `FIXED_LINE_OR_MOBILE` numbers. However,
 in some countries it is possible to configure other types, such as normal
 land-lines, to receive SMSs.
 
-### <a name="#fixed_line_or_mobile"/>Why did I get `FIXED_LINE_OR_MOBILE` as the type of my phone number?
+### <a name="#fixed_line_or_mobile">Why did I get `FIXED_LINE_OR_MOBILE` as the type of my phone number?</a>
 
 Some number ranges are explicitly defined as being for fixed-line or mobile
 phones. We even represent ranges defined as being "Mostly land-line" in this
 way.
 
-### <a name="#portability"/>What is mobile number portability?
+### <a name="#portability">What is mobile number portability?</a>
 
 The ability to keep your mobile phone number when changing carriers. To see whether a region supports mobile number portability use [isMobileNumberPortableRegion](https://github.com/google/libphonenumber/blob/58247207903f917839001bc62525a5b48a475b7e/java/libphonenumber/src/com/google/i18n/phonenumbers/PhoneNumberUtil.java#L3524).
 
-### <a name="#carrier_changes"/>Since it's possible to change the carrier for a phone number, how is the data kept up-to-date?
+### <a name="#carrier_changes">Since it's possible to change the carrier for a phone number, how is the data kept up-to-date?</a>
 
 Not all regions support mobile number portability. For those that don't, we return the carrier when available. For those that do, we return the original carrier for the supplied number.
 
-### <a name="#m2m"/>What about M2M (machine to machine) numbers?
+### <a name="#m2m">What about M2M (machine to machine) numbers?</a>
 
 libphonenumber does not support M2M numbers in general, but only in one exception case where in Netherlands 097X M2M numbers are used as regular mobile phone numbers.
 
@@ -201,14 +201,14 @@ Many people use this library for formatting the numbers of their contacts, for a
 
 At the moment Libphonenumber can only support phone numbers that can be dialled by us, not by machines. If you found any humanly diallable M2M numbers that library is not supporting, please raise an [issue here](http://issuetracker.google.com/issues/new?component=192347) with all authoritative and specific documentation such as government sources, which have varied definitions.
 
-### <a href="#why_only_nl_m2m"/>Why supporting only NL M2M numbers?; Are we sure all 097X numbers are MOBILE?
+### <a href="#why_only_nl_m2m">Why supporting only NL M2M numbers?; Are we sure all 097X numbers are MOBILE?</a>
 
 Official authority has [explicitly stated](https://www.acm.nl/en/publications/information-about-dutch-097-numbers-non-dutch-providers) that this range “should be made accessible, just like other, regular number series from the Netherlands” and that “you can set up a voice and SMS connection towards prefix +31-97 in the same way as you have done already with the +31-6 series.[...] you should enable your systems for voice telephony for the numbers
 in the +31-97 series”. This means, however, that there might be cases where the library would categorise a number as a valid mobile number, but in reality, the particular number is used as pure M2M, is not SMS or voice-enabled. There is not much we can do from our side about this, since we always follow official guidelines.
 
 Therefore, clients should be aware that there is possibility of false positives in NL MOBILE category. The library will continue to not support M2M numbers in general.
 
-### <a href="#operator_specific_numbers"/>What about numbers that are only valid for a set of subscribers?
+### <a href="#operator_specific_numbers">What about numbers that are only valid for a set of subscribers?</a>
 
 There are some numbers that only work for the subcribers of certain operators
 for special operator-specific services. These differ from carrierSpecific since
@@ -223,19 +223,19 @@ similar to our prerequisites for supporting M2M.
 Please see [this issue](https://issuetracker.google.com/issues/65238929) for more
 context, and file a new issue if you're able to provide more information than this.
 
-## <a name="#representation"/>Representation
+## <a name="#representation">Representation</a>
 
-### <a name="#max_length"/>What is the maximum and minimum length of a phone number?
+### <a name="#max_length">What is the maximum and minimum length of a phone number?</a>
 
 We support parsing and storing numbers from a minimum length of two digits to a
 maximum length of 17 digits currently (excluding country calling code). The ITU
 standard says the national significant number should not be longer than
 fifteen digits, but empirically this has been proven not to be followed by all
 countries.
 
-## <a name="#formatting"/>Formatting
+## <a name="#formatting">Formatting</a>
 
-### <a name="#language_specific_format"/>Can / should we format phone numbers in a language-specific way?
+### <a name="#language_specific_format">Can / should we format phone numbers in a language-specific way?</a>
 
 No, phone number formatting is country-specific and language-independent. E.g.
 formatting a US number in a French way (e.g. the way a France number is
@@ -245,7 +245,7 @@ It is true that in some countries phone numbers are typically written using
 native, not ASCII, digits; our phone number library supports parsing these but
 doesn't support it at formatting time at the moment.
 
-### <a href="#changes_in_formatting"/>When does formatting in a country change?
+### <a href="#changes_in_formatting">When does formatting in a country change?</a>
 
 The formatting within a country changes sparingly, but may be announced explicitly
 or noted implicitly in a national numbering plan update that introduces a new number
@@ -268,7 +268,7 @@ parentheses persists and both methods are acceptable.
 See [issue #1996](https://github.com/google/libphonenumber/issues/1996)
 for some additional discussion.
 
-### <a name="#empty_format_result"/>Why does formatNumberForMobileDialing return an empty string for my number?
+### <a name="#empty_format_result">Why does formatNumberForMobileDialing return an empty string for my number?</a>
 
 If we don't think we can guarantee that the number is diallable from the user's
 mobile phone, we won't return anything. This means that for numbers that we
@@ -279,17 +279,17 @@ time then we will return an empty string. If you get an empty string and are
 okay providing a number that may not be diallable, you can call another of our
 formatting numbers instead.
 
-## <a name="#metadata"/>Metadata
+## <a name="#metadata">Metadata</a>
 
-### <a name="#metadata_definition"/>What do we mean by "metadata"?
+### <a name="#metadata_definition">What do we mean by "metadata"?</a>
 
 We use the word "metadata" to refer to all information about phone numbering in
 a particular country - what the country code, international and national
 dialling prefixes are, what carrier codes are operational, which phone numbers
 are possible or valid for a particular country, how to optimally format them,
 which prefixes represent a particular geographical area, etc.
 
-### <a name="#metadata_sources"/>Where do we get information from to determine if a number range is valid?
+### <a name="#metadata_sources">Where do we get information from to determine if a number range is valid?</a>
 
 In theory, phone numbering plans are all supposed to be administered through the
 ITU. Many countries' phone numbering plans may be found on the [ITU website](
@@ -316,7 +316,7 @@ We'd love to consume machine-readable numbering plan data (assigned ranges,
 carrier & geo mappings). If you can connect us with partners in the industry
 to achieve this, please do so. Thanks!
 
-### <a name="#mx_and_ar"/>Why is this number from Argentina (AR) or Mexico (MX) not identified as the right number type?
+### <a name="#mx_and_ar">Why is this number from Argentina (AR) or Mexico (MX) not identified as the right number type?</a>
 
 Certain countries' mobile and/or fixed line ranges may overlap or too granular,
 which may make accurate identification impossible. Eg: Argentina and Mexico.
@@ -371,7 +371,7 @@ mobile numbers internatioanlly, fixed-line to mobile nationally.. As these
 dialling patterns were deprecated, we have continued to maintain mobile and
 fixed-line ranges at higher level, returning type as [`FIXED_LINE_OR_MOBILE`](#fixed_line_or_mobile)
 
-### <a href="#mx_legacy_formats"/>Why Mexico (MX) numbers in older dialling formats are accepted as valid ones?
+### <a href="#mx_legacy_formats">Why Mexico (MX) numbers in older dialling formats are accepted as valid ones?</a>
 Though library has stopped supporting below older dialling codes in the canonical
 form and formatting results, we are lenient in parsing the number, i.e removing
 all older codes.
@@ -382,7 +382,7 @@ This is because we found the older dialling codes supported even after deprecati
 period, so we decided to support them for longer time. However, we will stop this as
 part of [this issue](https://issuetracker.google.com/issues/205606725). More details there.
 
-### <a name="#unsupported_regions"/>Why are Bouvet Island (BV), Pitcairn Island (PN), Antarctica (AQ) etc. not supported?
+### <a name="#unsupported_regions">Why are Bouvet Island (BV), Pitcairn Island (PN), Antarctica (AQ) etc. not supported?</a>
 
 We only support a country if:
 
@@ -417,7 +417,7 @@ calling codes that are only "reserved", or that no data is available for (namely
 a proposed new international telecommunication public correspondence service,
 shared code".)
 
-### <a name="#indonesia_tollfree"/>Why are Indonesian toll-free numbers beginning with "00x 803" not supported?
+### <a name="#indonesia_tollfree">Why are Indonesian toll-free numbers beginning with "00x 803" not supported?</a>
 
 Although some numbers beginning with "001 803" or "007 803" do work in Indonesia
 to reach toll-free endpoints, these numbers are hard to support because they
@@ -435,9 +435,9 @@ section, and it is likely some changes in the parsing code would have to be
 made to interpret the "00x" as something other than an IDD: this could have
 undesirable side-effects when parsing other numbers.
 
-## <a name="#misc"/>Misc
+## <a name="#misc">Misc</a>
 
-### <a name="#reduced_metadata"/>What is the metadatalite.js/METADATA_LITE option?
+### <a name="#reduced_metadata">What is the metadatalite.js/METADATA_LITE option?</a>
 
 For JavaScript, Java and C++ there is the option to use a stripped-down version
 of the metadata. Currently this only removes the example number metadata, so the
@@ -462,7 +462,7 @@ The metadata binary files can be generated using the ant build rules
 file](https://github.com/google/libphonenumber/blob/master/java/build.xml)
 itself.
 
-### <a name="#maven"/>Which versions of the Maven jars should I use?
+### <a name="#maven">Which versions of the Maven jars should I use?</a>
 
 When possible, use the [latest
 version](https://github.com/google/libphonenumber/releases) of
@@ -482,7 +482,7 @@ version of libphonenumber, follow these steps:
 *   If you depend on the carrier or geocoder jar, you also need to depend on
         the prefixmapper jar.
 
-### <a name="#android"/>How do I load libphonenumber resources in my Android app?
+### <a name="#android">How do I load libphonenumber resources in my Android app?</a>
 
 #### System considerations
 
@@ -525,7 +525,7 @@ You also need to copy the binary metadata files into your app's asset directory,
 automate updating them from upstream. To avoid net increase of app size, remove them
 from libphonenumber.
 
-### <a name="#windows"/>What about Windows?
+### <a name="#windows">What about Windows?</a>
 
 The libphonenumber team's support of the C++ library on Windows is primarily to
 support Chromium's build environment, and we depend on the community to support
@@ -545,7 +545,7 @@ group](https://groups.google.com/group/libphonenumber-discuss):
 *   [#1555](https://github.com/google/libphonenumber/issues/1555) to allow
     Windows to build cpp library with pthreads for multi-threading
 
-### <a name="#remove_example_number"/>How to remove a specific example number
+### <a name="#remove_example_number">How to remove a specific example number</a>
 
 We supply example numbers as part of the library API. While we aim to have numbers
 that are either explicitly allocated by the country as a test number, or look
@@ -556,7 +556,7 @@ If we by chance have actually listed your real number and would like it removed,
 please report this through Google's new [Issue Tracker](http://issuetracker.google.com/issues/new?component=192347).
 Only our internal team will have access to your identity (whereas GitHub usernames are public).
 
-### Why can the smallest digits of parsed numbers that are very long be incorrect when parsing in Javascript?
+### <a name="#long_numbers_in_js">Why can the smallest digits of parsed numbers that are very long be incorrect when parsing in Javascript?</a>
 
 Eg: National number of 900184080594493**87**, ```region: JP``` is parsed as
 900184080594493**90**. Reason: When the provided number is more than the max