Refine FAQ (#6525)

docs/en/FAQ/Unexpected-endpoint-register.md

-# Local span and Exit span should not be register
+# Register mechanism is no longer required for local / exit span
 
-Since 6.6.0, SkyWalking cancelled the local span and exit span register. If old java agent(before 6.6.0) is still running,
-and do register to 6.6.0+ backend, you will face the following warning message.
+Since version 6.6.0, SkyWalking has removed the local and exit span registers. If an old java agent (before 6.6.0) is still running,
+which registers to the 6.6.0+ backend, you will face the following warning message.
 ```
 class=RegisterServiceHandler, message = Unexpected endpoint register, endpoint isn't detected from server side.
 ```
 
-This will not harm the backend or cause any issue. This is a reminder that, your agent or other client should follow the new protocol
+This will not harm the backend or cause any issues, but serves as a reminder that your agent or other clients should follow the new protocol
 requirements.
 
-You could simply use `log4j2.xml` to filter this warning message out.
\ No newline at end of file
+You could simply use `log4j2.xml` to filter this warning message out.

docs/en/FAQ/Why-have-traces-no-others.md

 ### Problem
-- There is no abnormal log in Agent log and Collector log, 
-- The traces show, but no other info in UI.
+- There is no abnormal log in Agent log and Collector log.
+- The traces can be seen, but no other information is available in UI.
 
 ### Reason
 The operating system where the monitored system is located is not set as the current time zone, causing statistics collection time points to deviate.
 
-### Resolve
-Make sure the time is sync in collector servers and monitored application servers.
+### Resolution
+Make sure the time is synchronized between collector servers and monitored application servers.

docs/en/FAQ/install_agent_on_websphere.md

-# IllegalStateException when install Java agent on WebSphere
-This FAQ came from [community discussion and feedback](https://github.com/apache/skywalking/issues/2652). 
-This user installed SkyWalking Java agent on WebSphere 7.0.0.11 and ibm jdk 1.8_20160719 and 1.7.0_20150407,
-and had following error logs
+# IllegalStateException when installing Java agent on WebSphere
+This issue was found in our [community discussion and feedback](https://github.com/apache/skywalking/issues/2652). 
+A user installed the SkyWalking Java agent on WebSphere 7.0.0.11 and ibm jdk 1.8_20160719 and 1.7.0_20150407,
+and experienced the following error logs:
 ```
 WARN 2019-05-09 17:01:35:905 SkywalkingAgent-1-GRPCChannelManager-0 ProtectiveShieldMatcher : Byte-buddy occurs exception when match type.
 java.lang.IllegalStateException: Cannot resolve type description for java.security.PrivilegedAction
@@ -22,8 +22,8 @@ at org.apache.skywalking.apm.dependencies.net.bytebuddy.matcher.ElementMatcher$J
 ...
 ```
 
-The exception has been addressed as access grant required in WebSphere. 
-You could follow these steps.
+The exception occured because access grant was required in WebSphere. 
+Simply follow these steps:
 
 1. Set the agent's owner to the owner of WebSphere.
 2. Add "grant codeBase "file:${agent_dir}/-" { permission java.security.AllPermission; };" in the file of "server.policy".

docs/en/FAQ/kafka-plugin.md

 ### Problem 
-The trace doesn't continue in kafka consumer side.
+Tracing doesn't work on the Kafka consumer end.
 
 ### Reason
-The kafka client is responsible for pulling messages from the brokers, and after that the data will be processed by the user-defined codes. However, only the poll action can be traced by the pluign and the subsequent data processing work is inevitably outside the scope of the trace context. Thus, in order to complete the client-side trace, manual instrument has to be done, i.e. the poll action and the processing action should be wrapped manually.
+The kafka client is responsible for pulling messages from the brokers, after which the data will be processed by user-defined codes. However, only the poll action can be traced by the plug-in and the subsequent data processing work inevitably goes beyond the scope of the trace context. Thus, in order to complete tracing on the client end, manual instrumentation is required, i.e. the poll action and the processing action should be wrapped manually.
 
 ### Resolve
-With native kafka client, please use Application Toolkit libraries to do the manual instrumentation, with the help of `@KafkaPollAndInvoke` annotation in `apm-toolkit-kafka` or with OpenTracing API. And if you're using `spring-kafka` 1.3.x, 2.2.x or above, you can track the Consumer side without effort.
+For a native Kafka client, please use the Application Toolkit libraries to do the manual instrumentation, with the help of the `@KafkaPollAndInvoke` annotation in `apm-toolkit-kafka` or with OpenTracing API. If you're using `spring-kafka` 1.3.x, 2.2.x or above, you can easily trace the consumer end without further configuration.