translate dev docs to En (#637)

i18n/en/docusaurus-plugin-content-docs/current.json

@@ -1,6 +1,6 @@
 {
   "version.label": {
-    "message": "Next",
+    "message": "User Documentation",
     "description": "The label for version current"
   },
   "sidebar.docs.category.Overview": {

i18n/en/docusaurus-plugin-content-docs/current/dev/domain/overviewDomainModel.md

@@ -0,0 +1,3 @@
+# Overview of Domain Model
+
+Welcome to claim and supplement this document

i18n/en/docusaurus-plugin-content-docs/current/dev/domain/rm.md

@@ -0,0 +1,3 @@
+# Resourse Manager(RM)
+
+Welcome to claim and supplement this document

i18n/en/docusaurus-plugin-content-docs/current/dev/domain/tc.md

@@ -0,0 +1,3 @@
+# Transaction Coordinator(TC)
+
+Welcome to claim and supplement this document

i18n/en/docusaurus-plugin-content-docs/current/dev/domain/tm.md

@@ -0,0 +1,3 @@
+# Transaction Manager(TM)
+
+Welcome to claim and supplement this document

i18n/en/docusaurus-plugin-content-docs/current/dev/mode/xa-mode.md

@@ -0,0 +1,107 @@
+---
+title: Seata XA Mode
+keywords: [Seata]
+description: Seata XA Mode
+---
+
+# Seata XA Mode
+
+## Prerequisites
+
+- Databases that support XA transaction.
+- Java applications that access database via JDBC.
+
+## Overall Mechanism
+
+In the distributed transaction framework defined by Seata, XA mode is a transaction mode that manages branch transactions using the XA protocol mechanism, leveraging transaction resources such as databases and message services with XA protocol support.
+
+<img src="https://img.alicdn.com/tfs/TB1hSpccIVl614jSZKPXXaGjpXa-1330-924.png" style={{ zoom:'50%' }} />
+
+- Execution Phase:
+
+  - Rollbackable: Business SQL operations are placed in XA branches, and the XA protocol support ensures *rollbackability*.
+  - Persistent: After XA branches are completed, XA prepare is executed, and again, XA protocol support ensures *persistence* (i.e., no unexpected situations will prevent rollback).
+
+- Completion Phase:
+
+  - Branch Commit: Execute XA branch commit.
+  - Branch Rollback: Execute XA branch rollback.
+
+# Working Mechanism
+
+#### 1. Overall Operation Mechanism
+
+XA mode runs within the transaction framework defined by Seata:
+
+<img src="https://img.alicdn.com/tfs/TB1uM2OaSslXu8jSZFuXXXg7FXa-1330-958.png" alt="xa-fw" style={{ zoom:'50%' }} />
+
+- Execution Phase (E xecute):
+
+  - XA start/XA end/XA prepare + SQL + Register Branch
+
+- Completion Phase (F inish):
+
+  - XA commit/XA rollback
+
+#### 2. Data Source Proxy
+
+XA mode requires XAConnection.
+
+There are two ways to obtain XAConnection:
+
+- Option 1: Developers are required to configure XADataSource.
+- Option 2: Create it based on the developer's regular DataSource.
+
+The first method adds cognitive burden to developers, as they need to learn and use XADataSource specifically for XA mode, which contradicts the design goal of transparent XA programming.
+
+The second method is more developer-friendly. Like the AT mode, developers do not need to worry about any XA-related issues. They can maintain the local programming model.
+
+We prioritize designing and implementing the second method: DataSource proxy creates the corresponding XAConnection based on the regular JDBC connection obtained from the regular data source.
+
+Compared to the data source proxy mechanism in the AT mode, it looks like this:
+
+<img src="https://img.alicdn.com/tfs/TB11_LJcggP7K4jSZFqXXamhVXa-1564-894.png" alt="ds1" style={{ zoom:'50%' }} />
+
+However, the second method also has its limitations: it cannot guarantee compatibility correctness.
+
+In fact, this method is what database drivers should do. The implementation mechanisms of database drivers from different vendors and versions are vendor-specific. We can only ensure correctness on well-tested driver programs. Differences in the versions of driver programs used by developers may lead to the failure of the mechanism.
+
+This is particularly evident with Oracle. See the Druid issue: https://github.com/alibaba/druid/issues/3707
+
+Taking all factors into consideration, the data source proxy design for XA mode needs to support the first method: proxy based on XADataSource.
+
+Compared to the data source proxy mechanism in the AT mode, it looks like this:
+
+<img src="https://img.alicdn.com/tfs/TB1qJ57XZieb18jSZFvXXaI3FXa-1564-894.png" alt="ds2" style={{ zoom:'50%' }} />
+
+#### 3. Branch Registration
+
+XA start requires an Xid parameter.
+
+This parameter needs to be associated with the Seata global transaction's XID and BranchId so that the TC can drive the XA branch's commit or rollback.
+
+Currently, Seata's BranchId is generated uniformly during branch registration. Therefore, the timing of XA mode branch registration needs to be before XA start.
+
+A possible optimization in the future is:
+
+Delay branch registration as much as possible. Similar to the AT mode, we register the branch just before local transaction submission to avoid registering meaningless branches in case of branch execution failure.
+
+This optimization direction requires changes to the BranchId generation mechanism. BranchId should not be generated through branch registration but should be generated separately and then used to register the branch.
+
+## How to use XA Mode
+
+From a programming model perspective, XA mode is identical to AT mode.
+
+You can refer to Seata's official sample: [seata-xa](https://github.com/seata/seata-samples/tree/master/seata-xa)
+
+In the sample, the upper-level programming model is the same as the AT mode. You only need to modify the data source proxy to switch between XA mode and AT mode:
+
+```java
+@Bean("dataSource")
+public DataSource dataSource(DruidDataSource druidDataSource) {
+    // DataSourceProxy for AT mode
+    // return new DataSourceProxy(druidDataSource);
+
+    // DataSourceProxyXA for XA mode
+    return new DataSourceProxyXA(druidDataSource);
+}

i18n/en/docusaurus-plugin-content-docs/current/dev/seata-mertics.md

@@ -1,7 +1,164 @@
 ---
-title: Metrics design
+title: Metrics Design
 keywords: [Seata, Metrics]
-description: Seata Metrics.
+description: Seata Metrics
 ---
 
-TODO : Should be translated from docs/zh-cn/dev/architecture/seata_mertics.md
+### Metrics
+
+#### Design Philosophy
+
+1. Seata, as an integrated data consistency framework, will minimize the use of third-party dependencies to reduce the risk of conflicts in the Metrics module.
+2. The Metrics module will strive for higher measurement performance and lower resource overhead, minimizing side effects when enabled.
+3. When configuring, whether Metrics is activated and how data are published depend on the corresponding configuration; enabling configuration will automatically activate Metrics and publish measurement data to [Prometheus](https://github.com/prometheus).
+4. Using Service Provider Interface (SPI) for loading extensions instead of Spring.
+5. Initially, only core Transaction-related metrics will be published, and all other operational metrics will be gradually improved based on community needs.
+
+#### Module Description
+
+It consists of two core API modules, `seata-metrics-api` and `seata-metrics-core`, as well as N implementation modules such as `seata-metrics-registry-compact` and `seata-metrics-exporter-prometheus`:
+
+- seata-metrics-api Module
+
+This module is the core of Metrics and is part of the Seata infrastructure, referenced by TC, TM, and RM. It **does not contain any specific implementation code**, but it only includes interface definitions, including:
+
+1. Meter class interfaces: `Gauge`, `Counter`, `Timer`, etc.
+2. Registry container interface `Registry`
+3. Measurement publishing interface `Publisher`
+
+> Note: There are many existing implementations of Metrics in the open-source community, such as
+> 1. [Netflix-Spectator](https://github.com/Netflix/spectator)
+> 2. [Dropwizard-Metrics](https://github.com/dropwizard/metrics)
+> 3. [Dubbo-Metrics](https://github.com/dubbo/dubbo-metrics)
+> Some of them are lightweight and agile, while others are heavy and powerful. Since they are also "implementations", they will not be included in `seata-metrics-api` to avoid implementation binding.
+
+- seata-metrics-core Module
+
+This core module of Metrics organizes (loads) one Registry and N Exporters based on configuration.
+
+- seata-metrics-registry-compact Module
+
+This is the default (built-in) Registry implementation we provide.Instead of using other open-source Metrics libraries, it provides lightweight implementations of four types of Meters:
+
+- seata-metrics-exporter-prometheus Module
+
+This is the default Metrics implementation we provide. Without using other open-source Metrics implementations, it provides lightweight implementations of three types of Meters:
+
+| Meter Type | Description |
+| ---------- | ----------- |
+| Gauge      | Single latest value meter |
+| Counter    | Single accumulating meter, can increase or decrease |
+| Summary    | Multi-measurement output counter, outputs `total`, `count`, and `tps` (total per second) with no units |
+| Timer      | Multi-measurement output timer, outputs `total`, `count`, `max`, and `average`, supports accumulation in microseconds |
+
+> Note:
+> 1. More complex meters such as Histogram may be added in the future. Histogram is a type of meter that locally aggregates 75th, 90th, 95th, 98th, 99th, 99.9th, etc., and is suitable for certain scenarios but requires more memory.
+> 2. All meters inherit from Meter, and after executing the measure() method, all meters will generate 1 or N normalized Measurement results.
+
+It also implements an in-memory Registry and Prometheus Exporter to synchronize measurement data with Prometheus.
+
+> Note: Different monitoring systems have different ways of collecting measurement data. For example, Zabbix supports pushing with zabbix-agent, while Prometheus recommends using prometheus-server [pulling](https://prometheus.io/docs/practices/pushing/). Similarly, data exchange protocols are also different, so adaptation is often needed one by one.
+
+#### How to Use
+
+##### Add Configuration
+
+If you need to enable TC Metrics, you need to add configuration items in its configuration file:
+
+Take file.conf for example
+```text
+## metrics settings
+metrics {
+  enabled = true
+  registryType = "compact"
+  # multi exporters use comma divided
+  exporterList = "prometheus"
+  exporterPrometheusPort = 9898
+}
+```
+
+Or You can use application.yaml for versions above 1.5.0
+```yaml
+seata:
+  metrics:
+    enabled: true
+    registryType: compact
+    exporterList: prometheus
+    exporterPrometheusPort: 9898
+```
+
+Or You can also use a third-party configuration center such as nacos, apollo, etc.
+
+[Please refer to here](https://github.com/seata/seata/tree/develop/script/config-center) to upload the seata metrics configuration items to the corresponding configuration center, or open the corresponding configuration center console for manually adding.
+
+```properties
+metrics.enabled=true
+metrics.registryType=compact
+metrics.exporterList=prometheus
+metrics.exporterPrometheusPort=9898
+```
+
+After starting TC, you can get the text format data of Metrics on `http://tc-server-ip:9898/metrics`.
+
+>Tips: Port `9898` is used by default, and the list of ports registered by Prometheus [can be visited here](https://github.com/prometheus/prometheus/wiki/Default-port-allocations). If you want to change this port, you can use `metrics.exporter.prometheus.port` to modify the configuration.
+
+##### Download and start Prometheus
+
+After the download is complete, modify the Prometheus configuration file `prometheus.yml`, and add an item to grab Seata's measurement data in `scrape_configs`:
+```yaml
+scrape_configs:
+   # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
+   - job_name: 'prometheus'
+
+     # metrics_path defaults to '/metrics'
+     # scheme defaults to 'http'.
+
+     static_configs:
+     - targets: ['localhost:9090']
+
+   - job_name: 'seata'
+
+     # metrics_path defaults to '/metrics'
+     # scheme defaults to 'http'.
+
+     static_configs:
+     - targets: ['tc-server-ip:9898']
+```
+
+##### View data output
+It is recommended to combine the configuration [Grafana] (https://prometheus.io/docs/visualization/grafana/) to obtain better query results. The initial Metrics exported by Seata include:
+- TC :
+
+| Metrics | Description |
+| ------ | --------- |
+| seata.transaction(role=tc,meter=counter,status=active/committed/rollback) | Total number of currently active/committed/rollback transactions |
+| seata.transaction(role=tc, meter=summary, statistic=count, status=committed/rollback) | The number of transactions committed/rolled back in the current cycle |
+| seata.transaction(role=tc,meter=summary,statistic=tps,status=committed/rollback) | Transaction TPS(transaction per second) committed/rolled back in the current cycle |
+| seata.transaction(role=tc, meter=timer, statistic=total, status=committed/rollback) | The sum of time-consuming transactions committed/rolled back in the current cycle |
+| seata.transaction(role=tc, meter=timer, statistic=count, status=committed/rollback) | The number of transactions committed/rolled back in the current cycle |
+| seata.transaction(role=tc, meter=timer, statistic=average, status=committed/rollback) | The average transaction time spent on committing/rolling back in the current cycle |
+| seata.transaction(role=tc, meter=timer, statistic=max, status=committed/rollback) | The maximum time-consuming transaction committed/rolled back in the current cycle |
+
+Hint: the values of seata.transaction(role=tc, meter=summary, statistic=count, status=committed/rollback) and seata.transaction(role=tc, meter=timer, statistic=count, status=committed/rollback) may be the same, but they are derived from two different metrics.
+
+-TM:
+
+TM will be implemented later, including:
+seata.transaction(role=tm,name={GlobalTransactionalName},meter=counter,status=active/committed/rollback) : Use GlobalTransactionalName as the dimension to distinguish the status of different Transactional.
+
+-RM:
+
+RM will be implemented later, including:
+seata.transaction(role=rm, name={BranchTransactionalName}, mode=at/mt, meter=counter, status=active/committed/rollback): Use BranchTransactionalName as the dimension and AT/MT dimension to distinguish the transactional status of different branches.
+
+#### How to extend
+If there are any of the following situations:
+1. You do not use Prometheus as the operation and maintenance monitoring system, but you want to integrate Seata's Metrics data into Dashboard;
+2. You need more complex and powerful metric types, which already exist in other Metrics implementation libraries, and hope to integrate these third-party dependencies for direct use;
+3. You need to change the Measurement output of the default Metric, such as adding a `min` or `sd` (variance) to the Timer;
+4. ...
+
+Then you need to extend the implementation of Metrics by yourself, please create a new module project such as `seata-metrics-xxxx`, after that:
+- For 1: you need to implement a new Exporter;
+- For 2: You can change the default Registry implementation and return the third-party Meter implementation;
+- For 3: You can modify the implementation of the corresponding Meter, including the Measurement list returned by the `measure()` method.

i18n/en/docusaurus-plugin-content-docs/version-v1.0/dev/domain/overviewDomainModel.md

@@ -0,0 +1,3 @@
+# Overview of Domain Model
+
+Welcome to claim and supplement this document

i18n/en/docusaurus-plugin-content-docs/version-v1.0/dev/domain/rm.md

@@ -0,0 +1,3 @@
+# Resourse Manager(RM)
+
+Welcome to claim and supplement this document

i18n/en/docusaurus-plugin-content-docs/version-v1.0/dev/domain/tc.md

@@ -0,0 +1,3 @@
+# Transaction Coordinator(TC)
+
+Welcome to claim and supplement this document

i18n/en/docusaurus-plugin-content-docs/version-v1.0/dev/domain/tm.md

@@ -0,0 +1,3 @@
+# Transaction Manager(TM)
+
+Welcome to claim and supplement this document