Improve English content in technical documentation

Made technical docs more casual and approachable:
- Simplified complex sentences
- Added contractions where natural
- Improved flow and readability
- Fixed typos (e.g., "elemenating" → "eliminating")

Files updated:
- docs/technical/concept.md
- docs/technical/dx.md

Author: claude

docs/technical/concept.md

@@ -2,13 +2,13 @@
 
 _The Architecture of abap2UI5_
 
-This article introduces the core pattern behind abap2UI5: HTML Over-the-Wire — reimagined for the ABAP world. It explains how this approach eliminates traditional frontend complexity by shifting both UI rendering and application logic to the backend. The result: faster development, simplified deployment, and a UI5 frontend shell that acts purely as a rendering engine.
+This article introduces the core pattern behind abap2UI5: HTML Over-the-Wire — reimagined for the ABAP world. It shows how this approach cuts through traditional frontend complexity by moving both UI rendering and application logic to the backend. The result: faster development, simpler deployment, and a UI5 frontend shell that's purely a rendering engine.
 
 #### What is HTML Over-the-Wire?
 
 _HTML Over-the-Wire_ describes a server-centric web architecture in which the user interface is generated on the server and sent to the browser as ready-to-render HTML.
 
-Instead of building and maintaining complex JavaScript frontends, managing APIs, and exchanging JSON, the server handles everything — from business logic to UI generation. The browser simply receives HTML fragments and renders them. This approach eliminates the need for client-side MVC frameworks, data transformation layers, and frontend deployment processes [(1)](https://signalvnoise.com/svn3/html-over-the-wire/):
+Instead of building and maintaining complex JavaScript frontends, managing APIs, and exchanging JSON, the server handles everything — from business logic to UI generation. The browser just receives HTML fragments and renders them. This approach cuts out the need for client-side MVC frameworks, data transformation layers, and frontend deployment processes [(1)](https://signalvnoise.com/svn3/html-over-the-wire/):
 
 > You can write fast, modern, responsive web applications by generating your HTML on the server, and delivering that directly to the browser. You don’t need JSON as an in-between format. You don’t need client-side MVC frameworks. You don’t need complicated bundling and transpiling pipelines.
 
@@ -102,9 +102,7 @@ When a user triggers an event (e.g., pressing a button), the event information i
   <em>abap2UI5 – Simple shell app, backend handles all logic</em>
 </p>
 
-The frontend becomes a static app shared across all applications. Views and logic are fully defined and maintained in the backend and each application is represented by backend ABAP classes only. As a result, every UI5 app becomes a complete ABAP backend project — eliminating the need for separate frontend deployments entirely:
-
-The frontend becomes a static shell shared across all applications. Views and logic are fully defined and maintained in the backend, and each application is represented solely by backend ABAP classes. As a result, every UI5 development project becomes a complete backend project — eliminating the need for separate frontend deployments entirely:
+The frontend becomes a static shell shared across all applications. Views and logic are fully defined and maintained in the backend, with each application represented solely by backend ABAP classes. The result: every UI5 development project becomes a complete backend project — no separate frontend deployments needed:
 
 <p align="center">
 <img width="400" alt="image" src="https://github.com/user-attachments/assets/2d8b6441-84f3-464c-980f-2773d619af29" />
@@ -146,7 +144,7 @@ This leads to the second subtle shift in abap2UI5: Instead of binding OData to V
 
 This means CDS Views and OData services are no longer consumed directly on the frontend. Instead, the complete UI state — both view and model — is sent from the backend in a single response. Any user changes in the UI are then returned to the backend via a lightweight AJAX call containing the updated view model — no OData routing involved.
 
-Developers do not need to manually configure models or bindings. abap2UI5 handles this internally. All that’s required is to expose class attributes using a simple bind method — abap2UI5 handles the rest. 
+You don't need to manually configure models or bindings. abap2UI5 handles this internally. All you need to do is expose class attributes using a simple bind method — abap2UI5 takes care of the rest. 
 
 A typical backend response includes both the XML View:
 
@@ -229,9 +227,9 @@ The illustration below shows the difference between a full re-render and a targe
   <em>Partly HTML Rerendering via View Model Updates - Only relevant DOM parts are re-rendered, preserving UI state</em>
 </p>
 
-Thanks to UI5’s powerful data binding mechanism, only the modified DOM elements are updated. This preserves the current UI state — such as input focus — and ensures a smooth, uninterrupted user experience. 
+Thanks to UI5's powerful data binding mechanism, only the modified DOM elements are updated. This keeps the current UI state intact — like input focus — and ensures a smooth, uninterrupted user experience.
 
-The XML View and View Model concept make UI5 a perfect team player for the UI5 Over-the-Wire approach elemenating the need of full client-side re-renders.
+The XML View and View Model concept make UI5 a perfect match for the UI5 Over-the-Wire approach, eliminating the need for full client-side re-renders.
 
 #### Conclusion
 
@@ -250,7 +248,7 @@ Limitations:
 - Offline functionality or complex client-side interactions are not covered
 - Less effective if frontend and backend teams work independently
 
-By relocating UI control to the ABAP backend and using UI5 solely forthe  HTML creation, abap2UI5 enables fast and efficient development of business applications — without the complexity of SPA architectures.
+By moving UI control to the ABAP backend and using UI5 solely for HTML creation, abap2UI5 enables fast and efficient development of business applications — without the complexity of SPA architectures.
 
 Happy ABAPing! ❤️🦖🦕🦣
 

docs/technical/dx.md

@@ -2,7 +2,7 @@
 
 _A Developer-Centric Approach_
 
-abap2UI5 was created from the everyday experiences of ABAP developers. It addresses common challenges in the development process — including deployment, caching, debugging, and tooling — while preserving a coding style that stays close to familiar ABAP and SAP GUI patterns such as Selection Screens and ALV. The goal is to make working with abap2UI5 as familiar and intuitive as possible for ABAPers. This page takes a closer look at some of the key influences behind the framework.
+abap2UI5 was built from the everyday experiences of ABAP developers. It tackles common challenges in the development process — deployment, caching, debugging, and tooling — while keeping a coding style that's close to familiar ABAP and SAP GUI patterns like Selection Screens and ALV. The goal: make working with abap2UI5 as familiar and intuitive as possible for ABAPers. This page takes a closer look at the key influences behind the framework.
 
 ### Simple Output with IF_OO_ADT_CLASSRUN
 
@@ -38,11 +38,11 @@ CLASS zcl_app_ui5 IMPLEMENTATION.
   ENDMETHOD.
 ENDCLASS.
 ```
-What abap2UI5 adds is the ability to run in the browser without ADT, using a UI5 frontend that fully adheres to SAP Fiori design guidelines — and is ready to be shown to your colleagues right away.
+What abap2UI5 adds: the ability to run in the browser without ADT, using a UI5 frontend that fully follows SAP Fiori design guidelines — ready to show your colleagues right away.
 
 ###  Classic Input Handling with Selection Screens
 
-Input handling was never a challenge in classic ABAP — just define a Report with `PARAMETERS` and `SELECT-OPTIONS`, and the UI is generated automatically. Although the term didn’t exist back then, this gave you a "fullstack" app in just a few lines:
+Input handling was never a challenge in classic ABAP — just define a Report with `PARAMETERS` and `SELECT-OPTIONS`, and the UI gets generated automatically. The term didn't exist back then, but this gave you a "fullstack" app in just a few lines:
 
 ```abap
 REPORT zre_app_input.
@@ -80,7 +80,7 @@ CLASS zcl_app_input IMPLEMENTATION.
   ENDMETHOD.
 ENDCLASS.
 ```
-Additionally, you can test code changes instantly — just reload the page, enter input, and press the button — all within a single class and without any external UI tooling.
+Plus, you can test code changes instantly — just reload the page, enter input, and press the button — all within a single class, no external UI tooling needed.
 
 ### ALV-Style Table Output in the Browser
 
@@ -143,7 +143,7 @@ CLASS zcl_app_alv IMPLEMENTATION.
 ENDCLASS.
 ```
 
-From here, it's just a small step to generate everything dynamically using RTTI — similar to the SALV functionality, but running directly in the browser.
+From here, it's just a small step to generate everything dynamically with RTTI — similar to SALV functionality, but running directly in the browser.
 
 ### Classic Popups, Modern Events
 
@@ -203,34 +203,34 @@ CLASS zcl_app_alv_event IMPLEMENTATION.
 ENDCLASS.
 ```
 
-While browser-based roundtrips require slightly different flow control, the overall approach remains intuitive for ABAP developers.
+Browser-based roundtrips need slightly different flow control, but the overall approach stays intuitive for ABAP developers.
 
 ### More Developer-Friendly Advantages
 
-Beyond the code snippets shown above, the Over-the-Wire approach of abap2UI5 — based entirely on backend development — offers several additional advantages.
+Beyond the code snippets above, the Over-the-Wire approach of abap2UI5 — based entirely on backend development — brings several additional advantages.
 
 ##### Zero-Setup Deployment
 
-In abap2UI5, apps are just ABAP classes — deployment is as simple as activating the class. Transport to production happens via the standard transport system familiar from traditional ABAP development:
+In abap2UI5, apps are just ABAP classes — deployment is as simple as activating the class. Transport to production happens via the standard transport system you know from traditional ABAP development:
 - No separate frontend build or deployment pipelines  
 - Code changes can be instantly tested by other developers or consultants
 - Every app is abapGit-compatible — no separate frontend artifacts required  
 
 ##### No Caching Issues
 
-A common frustration in frontend development is caching — especially with BSP or Fiori Elements apps. You make a change, but nothing happens due to cached files, unless you manually trigger several cache invalidation transactions in the SAP backend. abap2UI5 avoids this issue entirely, as the UI is dynamically generated on every request:
+A common frustration in frontend development: caching — especially with BSP or Fiori Elements apps. You make a change, but nothing happens due to cached files, unless you manually trigger several cache invalidation transactions in the SAP backend. abap2UI5 sidesteps this entirely, as the UI gets dynamically generated on every request:
 - No need to clear browser or server caches  
 - Fast development iteration — edit the code, refresh the browser, see results  
 
 ##### Develop in Any IDE
 
-There's often debate about which IDE to use — but why not let everyone choose the tool they prefer? abap2UI5 apps are developed entirely in ABAP. You can work in ADT, SE80, or even explore integration with VS Code:
+There's often debate about which IDE to use — but why not let everyone pick their favorite? abap2UI5 apps are developed entirely in ABAP. Work in ADT, SE80, or even explore VS Code integration:
 - No additional setup required — works in any IDE
 - Ideal for teams with different tooling preferences
 
 ##### Pure ABAP Debugging
 
-Frontend-heavy applications often require switching between browser dev tools, JavaScript logs, and network inspectors. With abap2UI5, the UI is pure ABAP — no JavaScript, no additional layers. Just set a breakpoint in your ABAP method:
+Frontend-heavy apps often need switching between browser dev tools, JavaScript logs, and network inspectors. With abap2UI5, the UI is pure ABAP — no JavaScript, no additional layers. Just set a breakpoint in your ABAP method:
 - Backend-only debugging with the classic SE80 debugger or ADT
 - No need for browser debugging tools
 
@@ -243,7 +243,7 @@ Sharing your apps or code is simple. Since abap2UI5 apps are standard ABAP class
 
 ### Conclusion
 
-abap2UI5 brings back familiar ABAP development patterns. It reuses proven concepts like Selection Screens, ALV tables, and popup dialogs — but renders them as UI5 apps, defined and executed entirely in ABAP.
-The result: backend-driven UI development with minimal tooling and fast iterations. Whether it's prototyping or building full business apps, abap2UI5 keeps the development process close to what ABAP developers know best.
+abap2UI5 brings back familiar ABAP development patterns. It reuses proven concepts like Selection Screens, ALV tables, and popup dialogs — but renders them as UI5 apps, all defined and executed in ABAP.
+The result: backend-driven UI development with minimal tooling and fast iterations. Whether you're prototyping or building full business apps, abap2UI5 keeps development close to what ABAP developers know best.
 
 Happy ABAPing! ❤️🦖🦕🦣