doc: fixes some typo in documentation (#89) (#90)

Signed-off-by: Julien Déramond <[email protected]>
Signed-off-by: Pierre-Yves Lapersonne <[email protected]>
Co-authored-by: Julien Déramond <[email protected]>
Co-authored-by: Pierre-Yves Lapersonne <[email protected]>

.github/DEVELOP.md

@@ -20,12 +20,12 @@
 You should check wether or not you have the tools in use in the project like _Fastlane_, _SwiftLint_, _SwiftFormat_, etc.
 You can have a look for example in thr **THIRD\_PARTY.md** file which lists any dependencies and tools we use are different levels (SDK, showcase app, projects).
 
-If some tools are missing, pick the suitable command line bellow:
+If some tools are missing, pick the suitable command line below:
 ```bash
 # Use Bundler to install a major part of dependencies (thanks to Gemfile and Gemfile.lock files)
 bundle install
 
-# Use CocoaPods to install other dependencies not avaialble as rubygems (thanks to Podfile and Podfile.lock files)
+# Use CocoaPods to install other dependencies not available as rubygems (thanks to Podfile and Podfile.lock files)
 bundle exec pod install
 
 # Some dependencies must be downloaded by hand:
@@ -69,7 +69,7 @@ The Xcode project contains two targets:
 ## Certificates, profiles and identifiers
 
 We choose to use Xcode automatic signing for debug builds of the app so as to make easier onboarding of newcomers in development team, and also to prevent to update provisioning profiles with individual developers certificates each team someone wants to build the app and also to prevent to register each new build device). You may need to be part of our team if you want to build in debug mode.
-Note the bundle identifier here for lcoal builds is **com.orange.ouds.demoapp-debug**, with a **-debug** suffix so as to prevent any local build to be replaced by TestFlight builds which have **com.orange.ouds.demoapp** identifiers.  
+Note the bundle identifier here for local builds is **com.orange.ouds.demoapp-debug**, with a **-debug** suffix so as to prevent any local build to be replaced by TestFlight builds which have **com.orange.ouds.demoapp** identifiers.
 
 However for release builds we use a dedicated _provisioning profile_ built with of course a _distribution certificate_(.p12 format with private key, not .cer) and the _bundle identifier_ `com.orange.ouds.demoapp` for our _Apple Team_ `France Telecom (MG2LSJNJB6)`. Thus you won't be able to build and sign in release mode without this provisioning profile and this distribution certificate. These elements are stored in our local GitLab CI runners and must not be available outside.
 
@@ -166,7 +166,7 @@ exit 0
 We try also to apply [keep a changelog](https://keepachangelog.com/en/1.0.0/), and [semantic versioning](https://semver.org/spec/v2.0.0.html) both with [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/).
 
 You can generate a `RELEASE_NOTE.md` file using your Git history and [git cliff](https://git-cliff.org/) tool.
-Define first a `cliff.toml` configuration file containing the code bellow.
+Define first a `cliff.toml` configuration file containing the code below.
 
 ```toml
 # git-cliff ~ configuration file
@@ -176,7 +176,7 @@ Define first a `cliff.toml` configuration file containing the code bellow.
 # changelog header
 header = """
 # Release Note\n
-All notable changes for this version are here and blablbla.\n
+All notable changes for this version are here and blablabla.\n
 """
 # template for the changelog body
 # https://keats.github.io/tera/docs/#introduction
@@ -353,9 +353,9 @@ sort_commits = "oldest"
 A [GitHub Action](https://github.com/gitleaks/gitleaks-action) has been integrated to the repository with a configuration file defined in _/github/workflows_ named _gitleaks-action.yaml_.
 It will launch the _Gitleaks_ tool automatically.
 
-Howevere this tool does not detect plain API key mixed in URL, that is a reason why _Gitleaks_ can be called in a pre-commit hook, using the _giteaks.toml_ at the root of the prokect.
+However this tool does not detect plain API key mixed in URL, that is a reason why _Gitleaks_ can be called in a pre-commit hook, using the _giteaks.toml_ at the root of the project.
 To call _Gitleaks_ in pre-commit hooks, create a file named **pre-commit** inside _.git/hooks_ (then run `chmod u+x` in the file).
-Then place the bash code bellow in this file:
+Then place the bash code below in this file:
 
 ```bash
 # Run Gitleaks before commits

CHANGELOG.md

@@ -16,6 +16,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- [Library] Fix some typos in documentation ([#89](https://github.com/Orange-OpenSource/ouds-ios/issues/89))
+
 ## [0.1.0](https://github.com/Orange-OpenSource/ouds-ios/compare/0.0.0...0.1.0) - 2024-08-08
 
 ### Added

OUDS/Core/Components/Sources/Forms/TextInput/OUDSFormsTextInput.swift

@@ -54,7 +54,7 @@ public struct OUDSFormsTextInput: View {
                 icon: { /*@START_MENU_TOKEN@*/Image(systemName: "42.circle")/*@END_MENU_TOKEN@*/ }
             )
 
-            Text("Write bellow some awesome text!")
+            Text("Write below some awesome text!")
                 .fontWeight(theme.ftiSubtitleFontWeight.fontWeight)
                 .font(.system(size: theme.ftiSubtitleFontSize))
                 .foregroundColor(theme.ftiSubtitleColor.color)

OUDS/Core/Tokens/RawTokens/Sources/BorderRawTokens.swift

@@ -15,17 +15,17 @@ import Foundation
 
 // MARK: - Type aliases to keep grammar clear
 
-/// Typeliases precising `Double` value are used (because of multiplier factors) for a **border width raw token**.
+/// Type alias precising `Double` value are used (because of multiplier factors) for a **border width raw token**.
 public typealias BorderWidthRawToken = Double
 
-/// Typeliases precising `Double` value are used (because of multiplier factors) for a **border widthradiusraw token**.
+/// Type alias precising `Double` value are used (because of multiplier factors) for a **border radius raw token**.
 public typealias BorderRadiusRawToken = Double
 
-/// Typealise for `String` so as to help users (developers) to see that raw tokens are needed and linked to `String` for **border style raw tokeb**.
+/// Type alias for `String` so as to help users (developers) to see that raw tokens are needed and linked to `String` for **border style raw token**.
 /// `String` are used here to prevent to rely on _SwiftUI_ types which are not compatible with `@objc` and are heavier than primitive types.
 /// In addition, if new styles are defined in design team side (such as kind of composite styles) and need to be processed differently 
 /// (because not available with _SwiftUI_ because are composed of several styles),
-/// such  `String` values could be procesed later without any API breaks.
+/// such  `String` values could be processed later without any API breaks.
 public typealias BorderStyleRawToken = String
 
 // MARK: - Raw tokens
@@ -39,7 +39,7 @@ public typealias BorderStyleRawToken = String
 /// In the future, generating tools like _Style Dictionary_ should either follow this file template and structure or just replace values or lines.
 public enum BorderRawTokens {
 
-    private static let borderBase: Double = 4 // Double type because used bellow for computations with Double values
+    private static let borderBase: Double = 4 // Double type because used below for computations with Double values
 
     // MARK: Primitive token - Border - Width
 

OUDS/Core/Tokens/RawTokens/Sources/ElevationRawTokens.swift

@@ -15,7 +15,7 @@ import Foundation
 
 // MARK: - Type aliases to keep grammar clear
 
-/// Typeliases precising `Int` value are used (because used in _SwiftUI_ API) for each **elevation raw token**.
+/// Type alias precising `Int` value are used (because used in _SwiftUI_ API) for each **elevation raw token**.
 public typealias ElevationRawToken = Int
 
 // MARK: - Composite raw token

OUDS/Core/Tokens/SemanticTokens/Sources/BorderSemanticTokens.swift

@@ -16,13 +16,13 @@ import OUDSTokensRaw
 
 // MARK: - Type aliases to keep grammar clear
 
-/// Typeliases precising `BorderWidthRawToken`  is used as a value of this **border width semantic token**.
+/// Type alias precising `BorderWidthRawToken` is used as a value of this **border width semantic token**.
 public typealias BorderWidthSemanticToken = BorderWidthRawToken
 
-/// Typeliases precising `BorderRadiusSemanticToken`  is used as a value of t**his border raw semantic token**.
+/// Type alias precising `BorderRadiusRawToken` is used as a value of this **border raw semantic token**.
 public typealias BorderRadiusSemanticToken = BorderRadiusRawToken
 
-/// Typeliases precising `BorderStyleSemanticToken`  is used as a value of this **border style semantic token**.
+/// Type alias precising `BorderStyleRawToken` is used as a value of this **border style semantic token**.
 public typealias BorderStyleSemanticToken = BorderStyleRawToken
 
 // MARK: - Semantic tokens

OUDS/README.md

@@ -131,7 +131,7 @@ They can be seen as an high level of usage with functional meanings.
 Thus if we need for example to change a warning color, supposing this color is defined as a _semantic token_, we onlyhave to change its assigned value and all components using the _semantic token_ won't be impacted in their definition.
 In addition, there are hundreds of _semantics tokens_ and we needed to add them to the abstract root theme using extensions for clarity reasons to prevent to have a _Swift class_ with thousands of lines. Each _raw token_ "family" is then declared in its dedicated _Swift protocol_ any root theme must implement. Because we choose to split responsabilities and objects into their own modules, we faced troubles to make possible for children themes to override properties declared in _protocols_ and defined in _extensions_.
 That is the reason why tokens are exposed as `@objc open` to be available and oveeridable anywhere. 
-To keep the same semantics as the ones used in our specifications, _typealias_ are used to as to make the links to _primitive types_ and our logic of _tokens_. These type aliases are avaialble for those who want too make their own theme.
+To keep the same semantics as the ones used in our specifications, _typealias_ are used to as to make the links to _primitive types_ and our logic of _tokens_. These type aliases are available for those who want too make their own theme.
 
 Example with `ColorSemanticTokens`:
 
@@ -152,7 +152,7 @@ _Raw tokens_ are smallest _tokens_ possible. They are associated to raw values a
 
 In fact, we choose to use as most as possible primitive types for raw values, like `Int`, `Double`, `CGFloat` or `String` so as to handle the smallest types with few impacts on the memory for ecodesign principles. Indeed with hundreds of raw tokens, it will be more efficient to store primitive small types than structs or classes.
 So we expose also in higher level some properties so as to convert when needed some of these types to `SwiftUI` types (like `Font.Weight` and `Color`).
-To keep the same semantics as the ones used in our specifications, _typealias_ are used to as to make the links to _primitive types_ and our logic of _tokens_. These type aliases are avaialble for those who want too make their own theme.
+To keep the same semantics as the ones used in our specifications, _typealias_ are used to as to make the links to _primitive types_ and our logic of _tokens_. These type aliases are available for those who want too make their own theme.
 
 Using more simple and primitive types will help also to test the library. With also type aliases we force users to use our types and not higher level types like _SwiftUI_ types.