Change "lightning network" to lowercase

README.md

@@ -44,7 +44,7 @@ The process to create the guide started in the summer of 2020. The first draft o
 
 On June 2, 2021, the community [announced](https://bitcoindesign.medium.com/announcing-the-bitcoin-design-guide-c4955d859fda) the launch of the initial version of the Bitcoin Design Guide to the public.
 
-On February 9, 2022, the community [announced](https://bitcoindesign.medium.com/design-better-lightning-wallets-with-the-bitcoin-design-guide-v2-2669f610ebc7) the completion of a major revision of the guide to include content about the Lightning network.
+On February 9, 2022, the community [announced](https://bitcoindesign.medium.com/design-better-lightning-wallets-with-the-bitcoin-design-guide-v2-2669f610ebc7) the completion of a major revision of the guide to include content about the lightning network.
 
 See the [roadmap](https://github.com/orgs/BitcoinDesign/projects/2) for what we're currently working on.
 

calendar.md

@@ -46,7 +46,7 @@ Join community calls, design reviews, project discussions and other events. Our
 {% include emoji-box.html
     emoji = "⚡️"
     title = "Bitcoin design sprints"
-    description = "Our collaborative design sessions with Lightning wallet projects."
+    description = "Our collaborative design sessions with lightning wallet projects."
     url = "https://github.com/BitcoinDesign/Meta/issues/244"
 %}
 

guide.md

@@ -87,7 +87,7 @@ A closer look at the design process and frameworks, from [personal finance use c
 
 <h2 class="h3" markdown="1">[Daily spending wallet]({{ '/guide/daily-spending-wallet/' | relative_url }})</h2>
 
-An in-depth exploration of a mobile wallet for a Lightning-first, on-the-go use case. Covers primary user flows like [first use]({{ '/guide/onboarding/first-use/' | relative_url }}), [sending]({{ '/guide/payments/send/' | relative_url }}) and [requesting]({{ '/guide/payments/request/' | relative_url }}), features like [backup]({{ '/guide/onboarding/backing-up-a-wallet/' | relative_url }}) and [contacts]({{ '/guide/payments/contacts/' | relative_url }}), and more.
+An in-depth exploration of a mobile wallet for a lightning-first, on-the-go use case. Covers primary user flows like [first use]({{ '/guide/onboarding/first-use/' | relative_url }}), [sending]({{ '/guide/payments/send/' | relative_url }}) and [requesting]({{ '/guide/payments/request/' | relative_url }}), features like [backup]({{ '/guide/onboarding/backing-up-a-wallet/' | relative_url }}) and [contacts]({{ '/guide/payments/contacts/' | relative_url }}), and more.
 
 <div class="columns-desktop -two -ref">
 <div class="column" markdown="1">
@@ -150,7 +150,7 @@ An overview and considerations for bitcoin wallets that are managed by multiple
 
 <h2 class="h3" markdown="1">[How it works]({{ '/guide/how-it-works/' | relative_url }})</h2>
 
-Explanations of various technical aspects of bitcoin and Lightning.
+Explanations of various technical aspects of bitcoin and lightning.
 
 <div class="columns-desktop -two -how">
 <div class="column" markdown="1">

guide/daily-spending-wallet/activity.md

@@ -26,7 +26,7 @@ imagesBasics:
     - file: activity-ids
       modalImage: activity-ids-big
       alt: Smartphone screen showing a list of user transactions with minimal information and invoice IDs
-      caption: If your users are likely to rely on addresses or Lightning invoice IDs to identify payments, you may decide to show them. Always consider your users.
+      caption: If your users are likely to rely on addresses or lightning invoice IDs to identify payments, you may decide to show them. Always consider your users.
 imagesGrouping:
     - file: micropayments
       modalImage: micropayments-big
@@ -69,11 +69,11 @@ imagesReceive:
       caption: Tapping list items can quickly bring up further details and options.
 imagesSend:
     - file: send-transaction
-      alt: Smartphone screen showing a completed Lightning payment
-      caption: On-chain and Lightning payments look structurally similar, but differ in subtle ways.
+      alt: Smartphone screen showing a completed lightning payment
+      caption: On-chain and lightning payments look structurally similar, but differ in subtle ways.
     - file: send-transaction-expanded
-      alt: Smartphone screen showing a completed Lightning payment with extended technical details
-      caption: Expanded details of Lightning payment.
+      alt: Smartphone screen showing a completed lightning payment with extended technical details
+      caption: Expanded details of lightning payment.
 ---
 
 {% include picture.html
@@ -138,7 +138,7 @@ Since we already offer users a chronological list of events, it is a small step
 
 Events can include user activity related to unique wallet features. For example:
 
-- [Blixt](https://blixtwallet.github.io) allows for manual control over Lightning channels. The list can show when channels were opened and closed.
+- [Blixt](https://blixtwallet.github.io) allows for manual control over lightning channels. The list can show when channels were opened and closed.
 - [Breez](https://breez.technology) includes a podcast player. New subscriptions and episodes could be listed.
 - [Hexa](https://hexawallet.io) allows users to have multiple wallets. The list can show when new wallets were created.
 - Authentication to third-party services via [sign in with bitcoin]({{ '/guide/how-it-works/sign-in-with-bitcoin/' | relative_url }}).
@@ -151,7 +151,7 @@ Wallets can also independently keep an eye on user funds, data traffic, and othe
 
 ### Smart organization
 
-The Lightning network makes micropayments economically and technically viable. For example, as a user listens to a podcast, they may stream 10 sats per minute to the host as a thank you. This can easily result in a cluttered activity list, which can be remedied via automatic grouping.
+The lightning network makes micropayments economically and technically viable. For example, as a user listens to a podcast, they may stream 10 sats per minute to the host as a thank you. This can easily result in a cluttered activity list, which can be remedied via automatic grouping.
 
 {% include image-gallery.html pages = page.imagesGrouping %}
 
@@ -182,23 +182,23 @@ Alternative approaches to the basic list view can give users different perspecti
 
 The example shown here uses traditional categories borrowed from [personal household finance]({{ '/guide/designing-products/personal-finance/' | relative_url }}). As users tag transactions, the categories update.
 
-It's recommended to approach this type of view based on the unique use case and feature set of the application. For example, a wallet that is focused on interaction with Lightning applications may instead group payments by the services they were made with.
+It's recommended to approach this type of view based on the unique use case and feature set of the application. For example, a wallet that is focused on interaction with lightning applications may instead group payments by the services they were made with.
 
 </div>
 
 ### Transaction details
 
 The activity list focuses on summarizing the top-level information, so users can quickly scan the screen to get an overview. If they identify a transaction they want to take a closer look at or interact with, the following screens become relevant.
 
-##### A payment made on Lightning
+##### A payment made on lightning
 
 As with the activity list, transaction details screens should also only highlight relevant information and options, and make secondary details easily accessible.
 
 {% include image-gallery.html pages = page.imagesSend %}
 
 ##### A payment received on-chain
 
-While the details for Lightning and on-chain payments look very similar, there are subtle differences. Most noticeable for the user is the difference in fees and processing time.
+While the details for lightning and on-chain payments look very similar, there are subtle differences. Most noticeable for the user is the difference in fees and processing time.
 
 {% include image-gallery.html pages = page.imagesReceive %}
 
@@ -240,7 +240,7 @@ This can be in the form of text labels, or even uniquely generated icons like [J
 
 ### Wrapping up
 
-As mentioned at the top of the page, there is a lot of nuance in the display of user activity. While this allows for many different small design decisions, users overall benefit if wallets take similar approaches. Particularly when it comes to the addition of metadata that is not stored on-chain or by Lightning nodes, it would be helpful if wallets can converge on standardized data formats to allow for [interoperability]({{ '/guide/getting-started/principles/#interoperability' | relative_url }}) and data portability.
+As mentioned at the top of the page, there is a lot of nuance in the display of user activity. While this allows for many different small design decisions, users overall benefit if wallets take similar approaches. Particularly when it comes to the addition of metadata that is not stored on-chain or by lightning nodes, it would be helpful if wallets can converge on standardized data formats to allow for [interoperability]({{ '/guide/getting-started/principles/#interoperability' | relative_url }}) and data portability.
 
 ---
 

guide/daily-spending-wallet/contacts.md

@@ -27,11 +27,11 @@ imagesAddContact:
       alt: Address entry screen with expanded information about supported addresses
       caption: Information about supported address formats should be readily available.
     - file: manual-add-contact-add-address-valid
-      alt: Address entry screen with inline validation for a Lightning address
+      alt: Address entry screen with inline validation for a lightning address
       caption: Inline validation lets users know about if addresses are accepted.
     - file: manual-add-contact-with-address
-      alt: A contact with a Lightning address assigned
-      caption: A contact with a Lightning address associated.
+      alt: A contact with a lightning address assigned
+      caption: A contact with a lightning address associated.
 imagesSupportedFormats:
     - file: manual-add-contact-add-address-valid-on-chain
       alt: Address entry screen with inline validation for an on-chain address
@@ -63,13 +63,13 @@ imagesMultiAddressContact:
       caption: Address details and options can be available on tap.
 imagesImportAddress:
     - file: lightning-address-input
-      alt: Modal showing that a Lightning address was detected on the clipboard
+      alt: Modal showing that a lightning address was detected on the clipboard
       caption: A modal is shown when an address has been imported via the clipboard or other methods.
     - file: lightning-address-input-add-contact
       alt: Screen for selecting a contact
       caption: The user has tapped "Add contact" and then taps "+" to add a new contact.
     - file: lightning-address-input-new-contact
-      alt: Contact screen with the Lightning address assigned
+      alt: Contact screen with the lightning address assigned
       caption: The new contact is created with the address associated.
 imagesPayInvoice:
     - file: pay-invoice-with-details
@@ -165,7 +165,7 @@ https://www.figma.com/file/VB3GQdAnhl8yta44DY3PSV/Bitcoin-UI-Kit?node-id=3120%3A
 
 Whether we’re sending emails, physical mail, or following someone on social media, we primarily think in terms of names and faces, and not the respective address or user ID.
 
-Invoices, node IDs and other transaction endpoints in bitcoin and Lightning are highly unintuitive. Abstracting them via a contact list can create a much smoother user experience. There are many [payment request formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}), each with unique properties and varying levels of maturity and adoption, requiring unique design solutions. This page uses the more approachable term "address", along with various UI techniques, to abstract these complexities for users.
+Invoices, node IDs and other transaction endpoints in bitcoin and lightning are highly unintuitive. Abstracting them via a contact list can create a much smoother user experience. There are many [payment request formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}), each with unique properties and varying levels of maturity and adoption, requiring unique design solutions. This page uses the more approachable term "address", along with various UI techniques, to abstract these complexities for users.
 
 Let's go over common user interactions around managing contacts. This will illustrate how such a feature could work, and helps explain the underlying design problems and decisions.
 
@@ -194,7 +194,7 @@ The contacts screen should offer various features for editing and organization.
 
 ### Importing an address
 
-This scenario can be initiated by copying a Lightning address to the clipboard, scanning a QR code, or tapping a payment link (see [payment entry points]({{ '/guide/daily-spending-wallet/sending/#payment-entry-points' | relative_url }})). An address is passed into the application and, where it's recognized and appropriate options are shown to the user. In the example below, the user adds the address as a new contact.
+This scenario can be initiated by copying a lightning address to the clipboard, scanning a QR code, or tapping a payment link (see [payment entry points]({{ '/guide/daily-spending-wallet/sending/#payment-entry-points' | relative_url }})). An address is passed into the application and, where it's recognized and appropriate options are shown to the user. In the example below, the user adds the address as a new contact.
 
 {% include image-gallery.html pages = page.imagesImportAddress %}
 

guide/daily-spending-wallet/security.md

@@ -75,7 +75,7 @@ Editor's notes
 
 This page narrowly focuses on user actions to set up and maintain good security
 and privacy for their wallets. It does not cover key setup and management, or
-technical things like watch towers for Lightning wallets.
+technical things like watch towers for lightning wallets.
 
 Illustration sources