feat: Translate docs 2.0 (#868)

* Translated BeagleRemoteView to EN Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * Navigation controller translated to PT Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * Navigation Controller translated to PT Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * Revises View client web and translates to PT Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * adjusts view client inf Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * revises ViewClient Android and translates to PT Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * adjustment in shortcode Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * log system revised and translated to EN Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * Overview from dependencies revised and translated to PT Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * view client for dependencies revised and translated to EN Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * Update content/en/android/customization/view-client.md Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/en/android/customization/view-client.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/en/android/customization/view-client.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/web/commons/view-client.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/web/commons/beagle-remote-view.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> * Update content/pt/ios/customization/dependencies/view-client.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/view-client.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/en/android/customization/view-client.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/en/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/en/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/en/web/commons/navigation/navigation-controllers.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/en/web/commons/view-client.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> * Update content/pt/ios/customization/dependencies/overview.md Signed-off-by: carlossteinzup <carlos.stein@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br> Co-authored-by: Hector Custódio <hector.custodio@zup.com.br>
ZupIT · Mar 10, 2022 · 4aa7430 · 4aa7430
1 parent 2998324
commit 4aa7430
Show file tree

Hide file tree

Showing 16 changed files with 688 additions and 270 deletions.
diff --git a/content/en/android/customization/view-client.md b/content/en/android/customization/view-client.md
@@ -7,23 +7,31 @@ description: >-
 
 ---
 
-# Introduction
-Similar to the HttpClient, but more specific. While the HttpClient is responsible for managing every request (views, json data, images, etc), the ViewClient is only responsible for fetching views, i.e. server driven pages.
-The ViewClient interface has to functions `fetch` and `prefetch`.
+## What is it?
 
-The default implementation of `fetch` does two things:
-1. search for a response data in a local cache, if exists, remove it from cache and return;
-2. if there is no response data in cache, it calls HttpClient and make the request for the ResponseData.
+The `View Client` is very similar to the HttpClient. While the HttpClient is responsible for handling requests (views, json data, images, etc), the ``ViewClient`` is only responsible for fetching views (Server Driven Views).
 
-The default implementation of `prefech` does two things:
-1. search for a response data in a local cache, and return it if exists;
-2. if there is no response data in cache, it calls HttpClient and make the request for the ResponseData and store it in cache (memory).
+The ViewClient interface has two functions **`fetch`** and **`prefetch`**.
 
-Note that `fetch` just search for responses that may have been prefetched earlier, and `prefetch` just store responses. It does nothing other than this, and this might be enough for most applications. But some applications may need extra behavior when fetching views, and this is the place where it should be implemented.
+The **`fetch`** default implementation has 2 functionalities:
 
-# Creating a new ViewClient
+1. It searches for a response data in a local cache, and if a cache exists, this function removes it from cache and return its contents;
+2. If there is no response data in cache, this function calls the `HttpClient` and makes a request which returns a ResponseData.
 
-A good example is caching. Let's say we want to locally store a response so when Beagle calls `viewClient.fetch` again, it returns the cached result instead of calling the HttpClient. To do this, we can create a new ViewClient class that implement ViewClient, has storage and is annotated with `@BeagleComponent` as follows:
+The **`prefetch`** default implementation has 2 functionalities:
+
+1. It searches for a response data in a local cache, and it returns this cache if it exists;
+2. If there is no response data in cache, this function calls the `HttpClient` and make the request for a ResponseData and store it in cache (memory).
+
+{{% alert color="success" %}}
+Please note that `fetch` just search for responses that may have been *prefetched* earlier, and `prefetch` just store responses. It just do this, and that is enough for most applications. But some other applications may need an extra behavior when fetching views, and this is when a customized ViewClient must be made.
+{{% /alert %}}
+
+## Creating a new ViewClient
+
+A good example is caching. Let's say we want to locally store a view in a way that when Beagle calls `viewClient.fetch` again, it returns the cached result, instead of calling the HttpClient.
+
+To do this, we can create a ``**MyViewClient**`` class that implements ``ViewClient``, has a storage and is annotated with `@BeagleComponent` as follows:
 
 ```kotlin
 @BeagleComponent
@@ -65,4 +73,4 @@ class MyViewClient(
 
 ```
 
-Above we implemented a very simple logic to `fetch` and `prefetch` that will store every fetch result in memory using a MutableMap `cachedResponses` using the request url as key, and search for a ResponseData in it every time `fetch` or `prefetch` is called. This is a very dumb implementation, because this cache would never expire, but the objective here is just to show how such feature could be implemented using the ViewClient.
+Above we have implemented a logic to `fetch` and `prefetch` that will store every fetch result in memory using a MutableMap called `cachedResponses`. It uses the *request url* as key, and searches for a ``ResponseData`` in it every time `fetch` or `prefetch` is called. This is a simple implementation, since this cache would never expire, and the objective here is to show how this feature could be implemented using the ViewClient.
diff --git a/content/en/ios/customization/dependencies/_index.md b/content/en/ios/customization/dependencies/_index.md
@@ -2,7 +2,5 @@
 title: Beagle dependencies
 weight: 159
 description: >-
-  In this section you will learn about Beagles' dependencies and their properties for iOS environment.
+  In this section you will learn about Beagles' dependencies and its properties for the iOS environment.
 ---
-
----
diff --git a/content/en/ios/customization/dependencies/log-system.md b/content/en/ios/customization/dependencies/log-system.md
@@ -5,57 +5,59 @@ weight: 151
 
 ---
 
-#### Introduction
+## What is it?
 
-Beagle uses the unified log system recommend by Apple, to provide different log messages in critical stages of a server driven flow. 
+Beagle uses the unified log system recommended by Apple, to provide different log messages in critical stages of a server driven flow.
 
 The log messages provided for Beagle iOS can be access through:
 
-* Xcode console
-* Application console
+* **Xcode console** and
+* **Application console**
 
-They are divided in 4 categories: 
+They are divided in 4 categories:
 
 1. **Network:** related to the network layer, information and error messages for each request, response and network URL construction.
 2. **Decoding:** displays messages every time a `parse` error occurs.  
-3. **Navigation:** informative messages that describes the navigations inside the server driven flow and possible errors may occur. 
-4. **Form:** related to forms. 
+3. **Navigation:** informative messages that describes the navigations inside the server driven flow and possible errors may occur.
+4. **Form:** related to forms.
 
-It is possible to disable triggered log messages. Beagle will not call the Log's API, even if it is default or customized. You will need to change the attribute `isLoggingEnabled` of`BeagleDependencies` to`false`.
+It is possible to disable the triggered log messages. Beagle will not call the Log's API, even if it is default or customized. You will need to change the attribute `isLoggingEnabled` of `BeagleDependencies` to `false`.
 
-The log messages can be filtered using these categories names and the main package identifier of the application as a subsystems. 
+The log messages can be filtered using these categories names and the application main package identifier as a subsystems.
 
-## Instructions to filter log messages:
+## Instructions to filter log messages
 
-Follow the steps below to filter the log messages: 
+Follow the steps below to filter the log messages:
 
 **Step 1:** open `Console App`;
 
 **Step 2:** select `device` on the `Devices` menu;
 
-**Step 3:** insert the filters in the search bar, search only for log messages with the Network category in the subsystem ~~`br.com.zup.BeagleDemoApp`~~ 
+**Step 3:** insert the filters in the search bar, search only for log messages with the Network category in the subsystem ~~`br.com.zup.BeagleDemoApp`~~
+{{< figure src="/shared/1.png">}}
 
-![](/shared/1.png)
+**Step 4:**  when you open the `BeagleDemo` application, you will see two log messages with the `network category`, one will show that Beagle made a request and the other indicating the response.
+{{< figure src="/shared/2.png">}}
 
-**Step 4:**  when you open the `BeagleDemo` application, you will see two log messages with the network category, one will show that Beagle made a request and the other indicating the response. 
-
-![](/shared/2.png)
-
-**Step 5:** error messages will be displayed with a yellow dot in the field `Type`, as showed below: 
-
-![](/shared/3.png)
+**Step 5:** error messages will be displayed with a yellow dot in the field `Type`, as showed below:
+{{< figure src="/shared/3.png">}}
 
 **Step 6:** to select the second log message received with a Network filter, you will see a `verbosa` version of this response.  
+{{< figure src="/shared/4.png">}}
 
-![](/shared/4.png)
-
-**Step 7:** the body of the response contains the server-driven screen and all its attributes and specifications can be accessed. 
+**Step 7:** the body of the response contains the server-driven screen and all its attributes and specifications can be accessed.
 
 ## Customization
 
-In order to let Beagle's environment open to modifications, the default API logs can be replaced to any other. Follow th next steps to make the API's logs replacement: 
+In order to let Beagle's environment open to modifications, the default API logs can be replaced by any other. THe next steps explains how to replace the API's logs:
 
-**Step 1:** implement BeagleLoggerType protocol on the class you want to use as log API, you will see that it is necessary to implement the methods `log(_ log: LogType)` and `logDecodingError(type: String)` that are internally called by Beagle when a message needs to be triggered:
+**Step 1:** implement BeagleLoggerType protocol on the class you want to use as the log API. You will see that it is necessary to implement the methods:
+
+* **`log(_ log: LogType)`** and
+* **`logDecodingError(type: String)`**
+
+These are internally called by Beagle when a message needs to be triggered
+We have listed an example below:
 
 ```swift
 class CustomLogger: BeagleLoggerType {
@@ -69,18 +71,21 @@ class CustomLogger: BeagleLoggerType {
 }
 ```
 
-**Step 2:** on Beagle's configuration of your project, assign to a class' instance to the `logger` dependency on `BeagleDependencies`:
+**Step 2:** Go to your project Beagle's configuration and assign a class' instance to `logger` dependency on the `BeagleDependencies`:
 
 ```swift
 let dependencies = BeagleDependencies()
 dependencies.logger = CustomLogger()
 Beagle.dependencies = dependencies
 ```
+
 ## BeagleLoggerProxy
 
-This class should not be used by the user in the majority of cases. This is the object that will be internally stored in `Beagle.dependencies.logger` instead of` BeagleLogger` customized by the user.
+{{% alert color="warning" %}}
+This class shouldn't be changed in most cases, since this is the object that will be internally stored in the `Beagle.dependencies.logger` instead of the customized `BeagleLogger`.
+{{% /alert %}}
 
-Its responsibility is to only forward calls to the user's class if `Beagle.dependencies.isLogginEnabled` is` true`, otherwise it won't pass along the message. Today it is public just to allow access to the user's custom class via:
+Its responsibility is only to forward calls to the user's class if `Beagle.dependencies.isLogginEnabled` is `true`, otherwise it won't pass the message. This property is public to allow access to the user's custom class via the code below:
 
 ```swift
 (Beagle.dependencies.logger as? BeagleLoggerProxy)?.logger

diff --git a/content/en/ios/customization/dependencies/overview.md b/content/en/ios/customization/dependencies/overview.md
@@ -3,16 +3,18 @@ title: Overview
 weight: 1
 type: overview
 description: >-
-  In this section you will learn about Beagles' dependencies and their properties for iOS environment.
+  This section describes the Beagles' dependencies and their properties for iOS environments.
 ---
 
 ---
 
-## Introduction
+## What is it?
 
-Your application can change Beagle's default behavior by customizing its dependencies.
+The `dependecies` file is where you can change the Beagle's default behavior in your application.
 
-From the `BeagleConfigurator` we can call the static method `setup(dependencies: BeagleDependencies)` which receives an object of type `BeagleDependencies`, where the customization of the Beagle dependencies can be done.
+## How does it work?
+
+The `BeagleConfigurator` calls the static method `setup(dependencies: BeagleDependencies)` that receives an `BeagleDependencies` object. This object will hold all dependencies's properties. Here follows an example:
 
 ```swift
 public struct BeagleDependencies {
@@ -36,10 +38,13 @@ public struct BeagleDependencies {
 }
 ```
 
-This structure has an empty constructor that assigns the default Beagle implementations, so just start it and make the customizations that are convenient.
+{{% alert color="success" %}}
+This structure has an empty constructor that assigns the default Beagle implementations:
 
-Therefore, it is appropriate to make this initial configuration of Beagle during the application startup process, that is, in the `didFinishLaunchingWithOptions` of the `AppDelegate`:
+* start it and make the necessary customizations.
+{{% /alert %}}
 
+Therefore, it is appropriate to make this *Beagle initial configuration* during the application startup process, that is, in the the `AppDelegate` function `didFinishLaunchingWithOptions` as shown below:
 
 ```swift
 @UIApplicationMain
@@ -64,15 +69,21 @@ class AppDelegate: UIResponder, UIApplicationDelegate {
 }
 ```
 
-To access these dependencies during application execution, Beagle provides a `@Injected` property wrapper that resolves an instance to the type of the variable (wrapped value). So suppose we want to clear the global context content at some point during application execution:
+{{% alert color="success" %}}
+To access these dependencies during the application execution, Beagle provides a `@Injected` property wrapper that resolves an instance to the type of the variable (wrapped value).
+{{% /alert %}}
+
+### Examples
+
+Below we have an example on how to clear the global context content at some point when executing the application:
 
 ```swift
 @Injected var globalContext: GlobalContextProtocol
 globalContext.clear()
 ```
 
 {{% alert color="warning" %}}
-This property wrapper raises a `fatalError` if it is used to resolve a dependency that is not Beagles' or that is optional and has not been configured e.g:(logger, analyticsProvider, deepLinkHandler, networkClient), to work around that, simply use `@OptionalInjected` which will return nil if the dependency is not resolved.
+This property wrapper raises a `fatalError` if it is used to resolve a dependency that is not Beagles' or that is optional and has not been configured e.g:(logger, analyticsProvider, deepLinkHandler, networkClient), to work around that, simply use `@OptionalInjected` which will return nil if the dependency is not resolved, as shown below.
 {{% /alert %}}
 
 ```swift
@@ -82,13 +93,13 @@ logger?.log(Log.network(.httpRequest(request: .init(url: urlRequest))))
 
 ## Customizable Dependencies
 
-Default dependencies implementation that can be customized.
+Here follow a few Default dependencies implementations that can be customized.
 
 ### CoderProtocol
 
-It is responsible for the encoding and decoding logic of the Beagle. Exposes the `register` method so that it is possible to register new components and actions.
+It is responsible for the encoding and decoding Beagle's logic. It exposes the `register` method so that it is possible to register new components and actions.
 
-Below there is an example of how to register a new component and a custom action:
+Below you can find an example on how to register a new component and a custom action:
 
 ```swift
 dependencies.coder.register(component: CustomWidget.self)
@@ -97,17 +108,17 @@ dependencies.coder.register(action: CustomAction.self)
 
 ### UrlBuilderProtocol
 
-It is responsible for creating a URL for a Beagle request from relative URLs that can be sent through BFF (in navigation flows for example) and a configured base URL.
+It is responsible for creating a Beagle request URL from relative URLs that are received from an BFF (in navigation flows for example) and a configured base URL.
 
-See next an example on how to use it:
+This is an example on how to use it:
 
 ```swift
 dependencies.urlBuilder = UrlBuilder(baseUrl: URL(string: "SUA URL BASE"))
 ```
 
 ### ThemeProtocol
 
-Stores all your **styles** and knows how to apply them to your components.
+It stores all your **styles** and knows how to apply them to your components.
 
 Some widgets have a variable that allows you to define the style. The name of each one must be passed to the **Theme** dependency, so that that style can be used in its respective component.
 
@@ -144,10 +155,10 @@ dependencies.theme = theme
 
 ### ViewClientProtocol
 
-It is responsible for fetching screens from the backend using the `fetch` and `prefetch` methods. It has an internal implementation that simply assembles urls from `urlBuilder` and makes requests from `networkClient`.
+It is responsible for fetching screens from the backend using the `fetch` and `prefetch` methods. It has an internal implementation that assembles urls from a `urlBuilder` and makes a request from `networkClient`.
 
 {{% alert color="info" %}}
-It is possible to implement a screen caching mechanism from the custom implementation of this dependency.
+It is possible to implement a screen caching mechanism from this dependency custom implementation.
 {{% /alert %}}
 
 ### ImageDownloaderProtocol
@@ -162,9 +173,9 @@ Dependencies which are not default and therefore should be implemented before us
 
 It is responsible for triggering the log messages produced when running Beagle streams from the `log` method. These logs follow the `LogType` protocol, which has the following parameters:
 
-- category: log subject;
-- message: log message;
-- level: classifies the criticity level.
+* category: log subject;
+* message: log message;
+* level: classifies the criticity level.
 
 ### NetworkClientProtocol
 
@@ -174,7 +185,7 @@ It is responsible for executing **network requests**. Beagle does not provide a
 
 This handler is used for a [**deep link navigation**]({{< ref path="/ios/customization/dependencies/deeplink-handler.md" lang="en" >}}) action. The variable has a default value, you can add new screens or replace them with others in the application.
 
-Below you can see a snippet on how to add a screen with a possible route for deep linking using a default value:
+Below you can see a code on how to add a screen with a possible route for a deep linking using a default value:
 
 ```swift
 let deepLinkHandler = DeeplinkScreenManager.shared
@@ -185,7 +196,7 @@ BeagleConfigurator.setup(dependencies: dependencies)
 
 ### AnalyticsProviderProtocol
 
-It is a protocol that can be implemented to track screen appearance or completion actions and click events.
+It is a protocol that can be implemented to track the screen appearance, actions and click events.
 
 See the example below:
 
@@ -203,29 +214,28 @@ class AnalyticsSample: Analytics {
 }
 ```
 
-## Dependencias publicas não customizáveis
-
+## Public dependencies that are not customizable
 
-Dependencies that are not customizable but have public APIs for configuring Beagle.
+Here we list a few dependencies that could not be customized but have public APIs for configuring Beagle.
 
 ### NavigationProtocol
 
-The `navigator` handles actions type of [**navigate**]({{< ref path="/api/actions/navigate/" lang="en" >}}) of your application.
+The `navigator` handles the [**navigate**]({{< ref path="/api/actions/navigate/" lang="en" >}}) actions in your application.
 
-Exposes custom navigation controller registration methods and [**navigation animation**]({{< ref path="/ios/customization/navigation-animation" lang="en" >}}).
+It exposes a custom navigation controller registration methods and a [**navigation animation**]({{< ref path="/ios/customization/navigation-animation" lang="en" >}}).
 
 ### GlobalContextProtocol
 
-It is responsible for managing the global context of Beagle, exposes `get`, `set` and `clear` functions, so that it is possible to access and change its attributes outside the scope of Beagle.
+It is responsible for managing the Beagle global context, it exposes the `get`, `set` and `clear` functions, so that it is possible to access and change the Global context attributes outside the Beagle scope.
 
 ### OperationsProviderProtocol
 
-It is responsible for providing context operations, exposes the `register` function so that it is possible to register custom operations in Beagle's default OperationsProvider.
+It is responsible for providing context operations, exposing the `register` function so that it is possible to register custom operations in Beagle's default OperationsProvider.
 
 ### BundleProtocol
 
 It is responsible for providing the application's `Bundle` so that Beagle has access to local images contained, it is initialized with `Bundle.main` but this can be easily changed:
 
 ```swift
 dependencies.appBundle.bundle = Bundle(identifier: "myBundleId")
-```
+```