doc: review locator.md

docs/md/locator.md

@@ -14,9 +14,9 @@
 
 # Introduction
 
-Usually service locators are tightly bound to the services they expose and it's
+Usually, service locators are tightly bound to the services they expose and it's
 hard to define a general purpose solution.<br/>
-This tiny class tries to fill the gap and to get rid of the burden of defining a
+This tiny class tries to fill the gap and gets rid of the burden of defining a
 different specific locator for each application.
 
 # Service locator
@@ -33,7 +33,7 @@ entt::locator<interface>::allocate_emplace<service>(allocator, argument);
 
 The difference is that the latter expects an allocator as the first argument and
 uses it to allocate the service itself.<br/>
-Once a service has been set up, it's retrieved using the value function:
+Once a service is set up, it's retrieved using the `value` function:
 
 ```cpp
 interface &service = entt::locator<interface>::value();
@@ -58,13 +58,13 @@ Finally, to reset a service, use the `reset` function.
 
 ## Opaque handles
 
-Sometimes it's useful to be able to obtain a _copy_ of a service to be assigned
-to a different locator. For example, when working across boundaries it's common
-to _share_ a service with a dynamically loaded module.<br/>
+Sometimes it's useful to _transfer_ a copy of a service to another locator. For
+example, when working across boundaries it's common to _share_ a service with a
+dynamically loaded module.<br/>
 Options aren't much in this case. Among these is the possibility of _exporting_
 services and assigning them to a different locator.
 
-This is what the `handle` and `reset` functions allow to do.<br/>
+This is what the `handle` and `reset` functions are meant for.<br/>
 The former returns an opaque object useful for _exporting_ (or rather, obtaining
 a reference to) a service. The latter also accepts an optional argument to a
 handle which then allows users to reset a service by initializing it with an
@@ -82,7 +82,7 @@ uninitialized service elsewhere as well.
 Note that exporting a service allows users to _share_ the object currently set
 in a locator. Replacing it won't replace the element even where a service has
 been configured with a handle to the previous item.<br/>
-In other words, if for example an audio service is replaced with a null object
-to silence an application and the original service was shared, this operation
-won't propagate to the other locators. Therefore, a module that share the
-ownership of the original audio service is still able to emit sounds.
+In other words, if an audio service is replaced with a null object to silence an
+application and the original service was shared, this operation won't propagate
+to the other locators. Therefore, a module that share the ownership of the
+original audio service is still able to emit sounds.