Fix some typos in markdown files

rfcs/0-jhipster-rfc-template.md

@@ -50,7 +50,7 @@ Why should we _not_ do this?
 [rationale-and-alternatives]: #rationale-and-alternatives
 
 - Why is this design the best in the space of possible designs?
-- What other designs have been considered and what is the rationale for not choosing them?
+- What other designs have been considered, and what is the rationale for not choosing them?
 - What is the impact of not doing this?
 
 ## Prior art

rfcs/1-jhipster-rfc-k8s-operator.md

@@ -8,7 +8,7 @@
 
 [summary]: #summary
 
-The JHipster Operators uses Kubernetes CRDs (Custom Resource Definitions) to encapsulate operational knowledge about JHipster Applications.
+The JHipster Operators use Kubernetes CRDs (Custom Resource Definitions) to encapsulate operational knowledge about JHipster Applications.
 
 # Motivation
 
@@ -25,7 +25,7 @@ The whole idea of having an operator makes sense only after having an applicatio
 Once your application is running there will be questions that start to pop up such as:
 
 - What happens if I want to deploy a second (or more) JHipster MicroServices Application? Is it going to work?
-  - If I have two (or more) applications , can I share the JHipster Registry between the two?
+  - If I have two (or more) applications, can I share the JHipster Registry between the two?
 - How can I make sure that all the MicroServices that are composing my application are up? How can I be notified if something goes down?
 - How can I upgrade/version an entire application (Set of microservices)?
 
@@ -67,7 +67,7 @@ Things that the Operator will **NOT** do:
 
 [guide-level-explanation]: #guide-level-explanation
 
-You can use the JHipster Kubernetes Operator to monitor and manage your JHipster MicroServices Applications running inside Kubernetes.In order to deploy your applications to Kubernetes you can use the `jhipster kubernetes` and `jhipster kubernetes-helm` generators to generate the Kubernetes Manifest required to run your containers in K8s.
+You can use the JHipster Kubernetes Operator to monitor and manage your JHipster MicroServices Applications running inside Kubernetes. In order to deploy your applications to Kubernetes you can use the `jhipster kubernetes` and `jhipster kubernetes-helm` generators to generate the Kubernetes Manifest required to run your containers in K8s.
 
 ![JHipster Flow to K8s](https://github.com/salaboy/jhipster-operator/blob/master/imgs/jhipster-flow.png 'JHipster Flow to K8s')
 
@@ -101,7 +101,7 @@ The JHipster Kubernetes Operator will use these resource definitions to understa
 
 Once these resources are deployed as part of the normal Kubernetes deployment procedure, the Operator will be able to monitor the state of the entire application.
 
-The Operator will expose a set of APIs to fine tune the default behaviour and also to expose relevant information such as:
+The Operator will expose a set of APIs to fine tune the default behavior and also to expose relevant information such as:
 
 - List of available applications (same information that is provided by the Kubernetes API)
 - Details of an application, related services, healthy status, version, etc
@@ -123,7 +123,7 @@ The Operator will provide an excellent entry point for domain specific extension
 Because the Operator will run inside a Kubernetes Pod, we need to grant the Operator's deployment with a special Service Account, Role and Role Bindings for it to be able to
 interact with the Kubernetes APIs. [You can find these extra manifests here](https://github.com/salaboy/jhipster-operator/tree/master/kubernetes/deploy).
 
-A Kubernetes Operator only make sense if you are planning to run your application in Kubernetes, for people that is not there yet, this might cause confusion. The Operator Documentation and guides should clearly explain what and why the Operator is trying to solve these platform wide concerns and its advantages.
+A Kubernetes Operator only makes sense if you are planning to run your application in Kubernetes, for people that are not there yet, this might cause confusion. The Operator Documentation and guides should clearly explain what and why the Operator is trying to solve these platform wide concerns and its advantages.
 
 # Rationale and alternatives
 
@@ -147,9 +147,9 @@ The README.md file provides a glimpse of this first iteration, but after a lot o
 
 - **Q: This definitely is cool but is this really necessary for a JHipster application.**
 - **A**: If you are running in Kubernetes, the JHipster K8s Operator will provide you extra functionality and it will allow Kubernetes to understand JHipster specific concerns.
-- **Q: Are we rebuilding any features provided by tools like Istio(coz many of the proposed features looks very similar to what it does)**
+- **Q: Are we rebuilding any features provided by tools like Istio (because many of the proposed features look very similar to what it does)?**
 - **A**: Not at all, we are providing an integration point for tools like Istio, KNative and CI/CD tools based on CRDs such as Jenkins X and Spinnaker.
-- **Q: While a JHipster CRD is cool it also means more tie in into JHipster in terms of deployment architecture is that necessary?**
+- **Q: While a JHipster CRD is cool, it also means more tie in into JHipster in terms of deployment architecture is that necessary?**
 - **A**: CRDs are just yaml files as the one that we need to deploy into Kubernetes, and are generated by the `jhipster kubernetes` and `jhipster kubernetes-helm` generators, so we are not changing anything regarding our deployment architecture. We are just decorating our existing manifest with JHipster Specific Resources, and this decoration can be optional. The CRDs are encapsulated, managed and installed by the Operator itself.
 
 # Unresolved questions

rfcs/2-jhipster-rfc-jhipster-control-center.md

@@ -32,7 +32,7 @@ As of JHipster 6.5, the JHipster administrator's management and monitoring UI is
 
 [motivation]: #motivation
 
-In recent years the technology landscape has changed significantly for Java and non Java based microservices but JHipster has somehow failed to adapt because we invested too much in maintaining our Eureka based solution: the JHipster registry. Although this solution is great and very productive for developers, it is not a very popular choice nowadays and our support for microservices without Eureka is lacking. Moreover, if we want to support more languages and technologies (.NET, Node.JS, Micronaut, Quarkus) and integrate them in the JHipster platform, non portable technologies such as Spring Cloud and Eureka cannot be made mandatory.
+In recent years, the technology landscape has changed significantly for Java and non Java based microservices but JHipster has somehow failed to adapt because we invested too much in maintaining our Eureka based solution: the JHipster registry. Although this solution is great and very productive for developers, it is not a very popular choice nowadays and our support for microservices without Eureka is lacking. Moreover, if we want to support more languages and technologies (.NET, Node.JS, Micronaut, Quarkus) and integrate them in the JHipster platform, non portable technologies such as Spring Cloud and Eureka cannot be made mandatory.
 
 In the meantime, our experience with the JHipster Registry has showed that in a microservice architecture, it is very valuable to have an overview of your running applications instances either in development or production. Currently this overview is provided as part of the application itself (for JHipster monoliths) or the JHipster Registry (for JHipster microservices). The goal of this RFC is to describe a solution that provides this overview in a new external application which can be used to cover all current use cases and more.
 
@@ -63,7 +63,7 @@ The **JHipster Control Center** is a standard web application that connects to o
 
 ### Description of features
 
-Once logged into the **JHipster Control Center**, the user will be able to view his administrator UI which present operational data coming from his JHipster applications. Typical data available from there will include:
+Once logged into the **JHipster Control Center**, the user will be able to view their administrator UI which presents operational data coming from their JHipster applications. Typical data available will include:
 
 - Health and readiness statuses
 - List of application instances and their metadata
@@ -74,7 +74,7 @@ The goal of the **JHipster Control Center** is to be used in combination with an
 
 ### Usage in development
 
-In every JHipster app, docker-compose files are present in the `src/main/docker` folder to launch associated services such as databases, message brokers and registries using docker. Among them, a **jhipster-control-center.yml** will let the users starts the **JHipster control-center** which will then be available at [http://localhost:1337](http://localhost:1337). By default the docker-compose file will be generated in such a way that the Control Center will be able to connect to the locally running JHipster application out of the box. Another possible way to run the **JHipster Control Center** in development would be to develop a simple CLI that allows to start the **JHipster Control Center** server quickly. Such a CLI tool could be embedded into the JHipster package distributed on NPM.
+In every JHipster app, docker-compose files are present in the `src/main/docker` folder to launch associated services such as databases, message brokers, and registries using Docker. Among them, a **jhipster-control-center.yml** will let the users start the **JHipster control-center** which will then be available at [http://localhost:1337](http://localhost:1337). By default, the docker-compose file will be generated in such a way that the Control Center will be able to connect to the locally running JHipster application out of the box. Another possible way to run the **JHipster Control Center** in development would be to develop a simple CLI that allows to start the **JHipster Control Center** server quickly. Such a CLI tool could be embedded into the JHipster package distributed on NPM.
 
 ### Usage in production
 
@@ -89,7 +89,7 @@ Implementation details will be left to the discretion of the **JHipster Control
 - A separate **JHipster Control Center** GitHub repository will host the application and allow collaboration.
 - The **JHipster Control Center** application will be based on a Java reactive Spring Boot application using Spring Cloud Gateway as embedded proxy technology.
 - The application will include Spring Cloud dependencies to allow it to plug into Eureka, Consul and Kubernetes service discovery mechanism.
-- The Management UI will be developed using Vue and can reuse some the existing code that currently lives in the "Admin pages" of a JHipster application.
+- The Management UI will be developed using Vue and can reuse some of the existing code that currently lives in the "Admin pages" of a JHipster application.
 - The application will be packaged as a docker image and a jar file which will be published on Docker Hub and Maven Central.
 - After the initial **JHipster Control Center** 1.0 release, it will be expected to keep backward compatibility with JHipster applications generated with JHipster version 7.0 or higher.
 - The **JHipster Control Center** will be an optional part of JHipster so that users will not have to use it. However, we think that it will provide sufficient improvements to the development and operational experience to convince users to adopt it.

rfcs/3-jhipster-rfc-unambiguous-priorities.md

@@ -10,15 +10,15 @@
 
 [summary]: #summary
 
-This RFC proposes to change priorities declaration to a more unambiguous way. Making it easier to understand and allow the generator class to be implemented with a more traditional notation.
+This RFC proposes to change priority declaration in a more unambiguous way. Making it easier to understand and allow the generator class to be implemented with a more traditional notation.
 
 ## Motivation
 
 [motivation]: #motivation
 
 Priorities are currently implemented as a getter with a non `_` prefixed name, and any new function with a non `_` prefixed name will be queued as a task at `default` priority. Javascript standard is that `_` prefixed name is private method, and non `_` prefixed name are class members instead of tasks. We should try to follow Javascript standards.
 
-JHipster workflow is clear and each priorities has it's purpose. This makes tasks outside priorities useless and its drawbacks overcome its benefits. We don't need to queue any tasks outside our declared priorities.
+JHipster workflow is clear and each priority has it's purpose. This makes tasks outside priorities useless and its drawbacks overcome its benefits. We don't need to queue any tasks outside our declared priorities.
 
 ## Guide-level explanation
 
@@ -52,7 +52,7 @@ JHipster uses Yeoman's traditional priorities:
 
 The result is that developers may be confused with the notation. And the API doesn't follow standards.
 
-While this works, an unambiguous notation would improve understanding the workflow and improve the API.
+While this works, an unambiguous notation would improve understanding of the workflow and improve the API.
 
 ```js
   get [INITIALIZING_PRIORITY]() {

rfcs/4-jhipster-rfc-entity-as-core.md

@@ -24,7 +24,7 @@ Another reason is that JHipster has too many generators, this will allow a more
 
 [guide-level-explanation]: #guide-level-explanation
 
-JHipster have a few generators related to entities.
+JHipster has a few generators related to entities:
 
 - `entities` generator is used to delegate selected entities to `entity` generator and `database-changelog` generator.
 - `entities-client` generator is used to rebuild webpack when some entity changes.
@@ -39,7 +39,7 @@ We have priorities to be used on entity generators.
 
 Those generators and priorities will be replaced by entity focused priorities and internal methods to support the workflow. Some entity related generators may be kept for more specific purpose like prompts.
 
-Planed priorities includes.
+Planed priorities include:
 
 - `configuringEachEntity`: priority to manipulate entities config.
 - `preparingEachEntity`: priority to create derived properties for entities to be used by the templates.
@@ -120,7 +120,7 @@ New priorities will have as first argument relevant resources to the priority/ta
 
 The implementation will require changes to `yeoman-generator` in order to allow tasks arguments and extract tasks to execute them for more than once (each entity/language).
 
-As advantages we can list:
+As advantages, we can list:
 
 - Fewer generators.
 - Remove some duplicated codes from entity related generators.

rfcs/5-jhipster-rfc-modular-needles.md

@@ -39,14 +39,14 @@ JHipster 7 have lots of technology specific needles implemented at `generator-ba
 - `addMavenPluginRepository`
 - Many others
 
-Those needles should be implemented using modular approach at the technology specific generator.
+Those needles should be implemented using a modular approach at the technology-specific generator.
 
 ## Reference-level explanation
 
 [reference-level-explanation]: #reference-level-explanation
 
 Needles will be implemented as a stand-alone function having the generator as first parameter.
-For convenience it will be exposed at the technology specific generator as a class member method.
+For convenience, it will be exposed at the technology-specific generator as a class member method.
 
 ```mjs
 export function aNeedle(generator, needleData) {
@@ -73,7 +73,7 @@ export default class Generator {
 }
 ```
 
-Using at a child generator:
+Using needles api inside a child generator:
 
 ```mjs
 import Generator from './base-generator.mjs'
@@ -87,7 +87,7 @@ export default class ChildGenerator extends Generator {
 }
 ```
 
-Using at a non related generator:
+Using a non-related generator:
 
 ```mjs
 import { aNeedle } from './base-generator.mjs'
@@ -101,7 +101,7 @@ export default class UnrelatedGenerator {
 }
 ```
 
-Realistic example applying multiples needles at same file:
+Realistic example applying multiple needles in the same file:
 
 ```mjs
 import { addProperty, addDependency, addDependencyToDevProfile } from 'generator-jhipster/generators/maven'
@@ -124,13 +124,13 @@ export default class UnrelatedGenerator {
 [drawbacks]: #drawbacks
 
 Needles api will not be exposed to every generator by default.
-It need to be imported to be used.
+It needs to be imported to be used.
 
 ## Rationale and alternatives
 
 [rationale-and-alternatives]: #rationale-and-alternatives
 
-This will allow to create a modular implementation.
+This will allow creating a modular implementation.
 
 ## Unresolved questions