Merge branch 'docs/sync_cn_and_en_docs' into 'master'

docs: Sync CN and EN docs missing the translation label

Closes DOC-14472

See merge request espressif/esp-idf!48241

docs/en/api-guides/ble/ble-audio.rst

@@ -302,7 +302,7 @@ PBP depends entirely on BAP for the underlying broadcast transport; it does not
 
 
 Profile and Service Dependency Reference
------------------------------------------
+----------------------------------------
 
 The following tables summarize the dependencies between profiles and services in the ESP-IDF LE Audio implementation.
 

docs/en/api-guides/external-ram.rst

@@ -253,6 +253,7 @@ By default, failure to initialize external RAM will cause the ESP-IDF startup to
 
         On {IDF_TARGET_NAME}, PSRAM encryption can use an independent encryption key. If the PSRAM encryption key is not programmed, the flash encryption key will be used as the PSRAM encryption key.
 
+
 .. only:: esp32
 
     .. include:: inc/external-ram-esp32-notes.rst

docs/en/api-guides/tools/idf-tools.rst

@@ -60,7 +60,9 @@ To use Espressif's download server, set the environment variable ``IDF_GITHUB_AS
 
 Any mirror server can be used provided the URL matches the ``github.com`` download URL format. For any GitHub asset URL that the install process downloads, it will replace ``https://github.com`` with ``https://${IDF_GITHUB_ASSETS}``.
 
-.. note:: The Espressif download server currently does not mirror everything from GitHub, but only files attached as Assets to some releases, as well as source archives for some releases.
+.. note::
+
+    The Espressif download server currently does not mirror everything from GitHub, but only files attached as Assets to some releases, as well as source archives for some releases.
 
 .. _idf-tools-py:
 

docs/en/api-reference/bluetooth/index.rst

@@ -90,7 +90,7 @@ For additional details and API reference from the upstream documentation, refer
 ----
 
 Examples and Tutorials
----------------------------
+----------------------
 
 Explore examples and tutorials in the ESP-IDF examples directory:
 

docs/en/api-reference/system/console.rst

@@ -187,7 +187,7 @@ To establish a basic REPL environment, ``console`` component provides several us
 
 In a typical application, you only need to call :cpp:func:`esp_console_new_repl_stdio` to initialize the REPL environment, including driver install, basic console configuration, spawning a thread to do REPL task and register several useful commands (e.g., `help`).
 
-After that, you can register your own commands with :cpp:func:`esp_console_cmd_register`. The REPL environment keeps in init state until you call :cpp:func:`esp_console_start_repl`.
+After that, you can register your own commands with :cpp:func:`esp_console_cmd_register`. The REPL environment keeps in initialized state until you call :cpp:func:`esp_console_start_repl`.
 
 
 Application Examples

docs/en/api-reference/system/efuse.rst

@@ -573,9 +573,9 @@ To get a dump for all eFuse registers.
 Deferred WR_DIS Burning
 -----------------------
 
-``WR_DIS`` (Write Disable) is a special eFuse field that implements permanent write-protection. Each bit in ``WR_DIS`` disables further programming of one (or more) associated eFuse fields. Once burned, the affected fields can no longer be modified.
+``WR_DIS`` (Write Disable) is a special eFuse field that implements permanent write-protection. Each bit in ``WR_DIS`` disables further programming of one (or more) associated eFuse fields. Once a ``WR_DIS`` bit is burned, its associated fields can no longer be modified.
 
-When burning staged data in BLOCK0, ``WR_DIS`` bits are burned separately after all other BLOCK0 data to ensure the retry mechanism of the burn function can recover from coding errors. This approach guarantees that write-protection is applied only after other BLOCK0 data is successfully burned.
+When burning staged data in BLOCK0, the ``WR_DIS`` bits are burned separately after all other BLOCK0 data to ensure the burn function can recover from coding errors via its retry mechanism. This approach guarantees that write-protection is applied only after other BLOCK0 data is successfully burned.
 
 Application Examples
 --------------------

docs/en/api-reference/system/freertos_idf.rst

@@ -434,8 +434,8 @@ Misc
 
 .. only:: SOC_CPU_HAS_PIE
 
-    PIE / AI Coprocessor Usage
-    ^^^^^^^^^^^^^^^^^^^^^^^^^^
+    PIE/AI Coprocessor Usage
+    ^^^^^^^^^^^^^^^^^^^^^^^^
 
     Like the Floating Point Unit (FPU), IDF FreeRTOS implements **Lazy Context Switching** for the PIE coprocessor. On a context switch, PIE registers remain untouched until a task executes a PIE instruction. Once a task uses the PIE coprocessor, it is **pinned to the current core**.
 
@@ -444,6 +444,7 @@ Misc
         .. note::
 
             On ESP32-S31, the PIE coprocessor is available **only on Core 1**. If a task executes a PIE instruction while running on Core 0, IDF FreeRTOS migrates the task to Core 1 and pins it there. This migration **overrides** any existing core affinity.
+
             Because of this migration, tasks must **not** use the PIE coprocessor within a critical section or ISR, as doing so will cause a runtime abort.
 
 

docs/en/api-reference/system/mem_alloc.rst

@@ -41,7 +41,7 @@ All DRAM memory is single-byte accessible, thus all DRAM heaps possess the ``MAL
 
     .. note::
 
-        This option is available only on single-core ESP32 configuration (``CONFIG_FREERTOS_UNICORE=y``). The ``CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY`` option has a significant disadvantage compared to regular memory: every byte, half-word, and arbitrary unaligned access to ``MALLOC_CAP_IRAM_8BIT`` memory triggers a ``LoadStore`` or ``Alignment`` exception. Although these exceptions are handled in software to ensure correct values are read or written, each access incurs approximately 167 CPU cycles of overhead and can cause significant performance degradation if accessed frequently. Therefore, it should be avoided in performance-critical sections of code such as ISRs or tight loops. Consider to refactor the code to use 32-bit aligned (``uint32_t``) accesses.
+        This option is available only on single-core ESP32 configuration (``CONFIG_FREERTOS_UNICORE=y``). The ``CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY`` option has a significant disadvantage compared to regular memory: every byte, half-word, and arbitrary unaligned access to ``MALLOC_CAP_IRAM_8BIT`` memory triggers a ``LoadStore`` or ``Alignment`` exception. Although these exceptions are handled in software to ensure correct values are read or written, each access incurs approximately 167 CPU cycles of overhead and can cause significant performance degradation if accessed frequently. Therefore, it should be avoided in performance-critical sections of code such as ISRs or tight loops. Consider refactoring the code to use 32-bit aligned (``uint32_t``) accesses.
 
 When calling ``malloc()``, the ESP-IDF ``malloc()`` internally calls ``heap_caps_malloc_default(size)``. This will allocate memory with the capability ``MALLOC_CAP_DEFAULT``, which is byte-addressable.
 

docs/en/security/flash-encryption.rst

@@ -1276,6 +1276,7 @@ The command ``idf.py decrypt-flash-data`` can be used with the same options (and
 
     On {IDF_TARGET_NAME}, PSRAM encryption can use an independent encryption key. If the PSRAM encryption key is not programmed, the flash encryption key will be used as the PSRAM encryption key.
 
+
 Technical Details
 -----------------