diff --git a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
index c00d3d072557..76de01f8f327 100644
--- a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
+++ b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
@@ -442,7 +442,7 @@ regarding possible unintentional matches for pattern-based rollback rules.
 
 [NOTE]
 ====
-As of 6.2, you can globally change the default rollback behavior: e.g. through
+As of 6.2, you can globally change the default rollback behavior – for example, through
 `@EnableTransactionManagement(rollbackOn=ALL_EXCEPTIONS)`, leading to a rollback
 for all exceptions raised within a transaction, including any checked exception.
 For further customizations, `AnnotationTransactionAttributeSource` provides an
@@ -450,21 +450,22 @@ For further customizations, `AnnotationTransactionAttributeSource` provides an
 
 Note that transaction-specific rollback rules override the default behavior but
 retain the chosen default for unspecified exceptions. This is the case for
-Spring's `@Transactional` as well as JTA's `jakarta.transaction.Transactional`.
+Spring's `@Transactional` as well as JTA's `jakarta.transaction.Transactional`
+annotation.
 
 Unless you rely on EJB-style business exceptions with commit behavior, it is
-advisable to switch to `ALL_EXCEPTIONS` for a consistent rollback even in case
-of a (potentially accidental) checked exception. Also, it is advisable to make
-that switch for Kotlin-based applications where there is no enforcement of
-checked exceptions at all.
+advisable to switch to `ALL_EXCEPTIONS` for consistent rollback semantics even
+in case of a (potentially accidental) checked exception. Also, it is advisable
+to make that switch for Kotlin-based applications where there is no enforcement
+of checked exceptions at all.
 ====
 
 Currently, you cannot have explicit control over the name of a transaction, where 'name'
 means the transaction name that appears in a transaction monitor and in logging output.
 For declarative transactions, the transaction name is always the fully-qualified class
-name + `.` + the method name of the transactionally advised class. For example, if the
+name of the transactionally advised class + `.` + the method name. For example, if the
 `handlePayment(..)` method of the `BusinessService` class started a transaction, the
-name of the transaction would be: `com.example.BusinessService.handlePayment`.
+name of the transaction would be `com.example.BusinessService.handlePayment`.
 
 [[tx-multiple-tx-mgrs-with-attransactional]]
 == Multiple Transaction Managers with `@Transactional`
@@ -565,7 +566,7 @@ e.g. with a value of "order" it can be used for autowiring purposes (identifying
 the order repository) as well as transaction manager selection, as long as the
 target beans for autowiring as well as the associated transaction manager
 definitions declare the same qualifier value. Such a qualifier value only needs
-to be unique with a set of type-matching beans, not having to serve as an id.
+to be unique within a set of type-matching beans, not having to serve as an ID.
 ====
 
 [[tx-custom-attributes]]