Replace 'e.g.' with 'for example' in documentation and comments

Closes gh-33515

framework-docs/modules/ROOT/pages/data-access/jdbc/advanced.adoc

@@ -223,7 +223,7 @@ As of 6.1.2, Spring bypasses the default `getParameterType` resolution on Postgr
 MS SQL Server. This is a common optimization to avoid further roundtrips to the DBMS just
 for parameter type resolution which is known to make a very significant difference on
 PostgreSQL and MS SQL Server specifically, in particular for batch operations. If you
-happen to see a side effect e.g. when setting a byte array to null without specific type
+happen to see a side effect, for example, when setting a byte array to null without specific type
 indication, you may explicitly set the `spring.jdbc.getParameterType.ignore=false` flag
 as a system property (see above) to restore full `getParameterType` resolution.
 

framework-docs/modules/ROOT/pages/data-access/jdbc/connections.adoc

@@ -177,7 +177,7 @@ corresponding `DataSource` proxy class for the target connection pool: see
 This is particularly useful for potentially empty transactions without actual statement
 execution (never fetching an actual resource in such a scenario), and also in front of
 a routing `DataSource` which means to take the transaction-synchronized read-only flag
-and/or isolation level into account (e.g. `IsolationLevelDataSourceRouter`).
+and/or isolation level into account (for example, `IsolationLevelDataSourceRouter`).
 
 `LazyConnectionDataSourceProxy` also provides special support for a read-only connection
 pool to use during a read-only transaction, avoiding the overhead of switching the JDBC

framework-docs/modules/ROOT/pages/data-access/orm/jpa.adoc

@@ -175,7 +175,7 @@ a context-wide `LoadTimeWeaver` by using the `@EnableLoadTimeWeaving` annotation
 `context:load-time-weaver` XML element. Such a global weaver is automatically picked up
 by all JPA `LocalContainerEntityManagerFactoryBean` instances. The following example
 shows the preferred way of setting up a load-time weaver, delivering auto-detection
-of the platform (e.g. Tomcat's weaving-capable class loader or Spring's JVM agent)
+of the platform (for example, Tomcat's weaving-capable class loader or Spring's JVM agent)
 and automatic propagation of the weaver to all weaver-aware beans:
 
 [source,xml,indent=0,subs="verbatim,quotes"]
@@ -469,7 +469,7 @@ a non-invasiveness perspective and can feel more natural to JPA developers.
 What about providing JPA resources via constructors and other `@Autowired` injection points?
 
 `EntityManagerFactory` can easily be injected via constructors and `@Autowired` fields/methods
-as long as the target is defined as a bean, e.g. via `LocalContainerEntityManagerFactoryBean`.
+as long as the target is defined as a bean, for example, via `LocalContainerEntityManagerFactoryBean`.
 The injection point matches the original `EntityManagerFactory` definition by type as-is.
 
 However, an `@PersistenceContext`-style shared `EntityManager` reference is not available for

framework-docs/modules/ROOT/pages/data-access/r2dbc.adoc

@@ -469,10 +469,10 @@ Kotlin::
 
 NOTE: R2DBC itself does not support Collection-like values. Nevertheless,
 expanding a given `List` in the example above works for named parameters
-in Spring's R2DBC support, e.g. for use in `IN` clauses as shown above.
-However, inserting or updating array-typed columns (e.g. in Postgres)
+in Spring's R2DBC support, for example, for use in `IN` clauses as shown above.
+However, inserting or updating array-typed columns (for example, in Postgres)
 requires an array type that is supported by the underlying R2DBC driver:
-typically a Java array, e.g. `String[]` to update a `text[]` column.
+typically a Java array, for example, `String[]` to update a `text[]` column.
 Do not pass `Collection<String>` or the like as an array parameter.
 
 [[r2dbc-DatabaseClient-filter]]

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc

@@ -250,7 +250,7 @@ the proxy are intercepted. This means that self-invocation (in effect, a method
 the target object calling another method of the target object) does not lead to an actual
 transaction at runtime even if the invoked method is marked with `@Transactional`. Also,
 the proxy must be fully initialized to provide the expected behavior, so you should not
-rely on this feature in your initialization code -- e.g. in a `@PostConstruct` method.
+rely on this feature in your initialization code -- for example, in a `@PostConstruct` method.
 
 Consider using AspectJ mode (see the `mode` attribute in the following table) if you
 expect self-invocations to be wrapped with transactions as well. In this case, there is
@@ -564,7 +564,7 @@ transaction definitions from a base class as well. This effectively overrides
 the default transaction manager choice for any unqualified base class methods.
 
 Last but not least, such a type-level bean qualifier can serve multiple purposes,
-e.g. with a value of "order" it can be used for autowiring purposes (identifying
+for example, 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

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-decl-explained.adoc

@@ -41,7 +41,7 @@ operations need to execute within the same Reactor context in the same reactive
 
 When configured with a `ReactiveTransactionManager`, all transaction-demarcated methods
 are expected to return a reactive pipeline. Void methods or regular return types need
-to be associated with a regular `PlatformTransactionManager`, e.g. through the
+to be associated with a regular `PlatformTransactionManager`, for example, through the
 `transactionManager` attribute of the corresponding `@Transactional` declarations.
 ====