Merge pull request #687 from akeneo/updates-following-optionalsku-launch

Updates following optional sku launch

Author: Pauline-Kaltenbach

content/getting-started/from-identifiers-to-uuid-7x/welcome.md

@@ -20,31 +20,31 @@ We deployed **8** new API endpoints, endpoints that have the same role as alread
 - `POST a proposal /api/rest/v1/products-uuid/{uuid}/proposal` (EE only), same as [POST /api/rest/v1/products/{code}/proposal](https://api.akeneo.com/api-reference.html#post_proposal)
 - `GET a draft /api/rest/v1/products-uuid/{uuid}/draft` (EE only), same as [GET /api/rest/v1/products/{code}/draft](https://api.akeneo.com/api-reference.html#get_draft__code_)
 
-And later (during the last quarter of 2022), we plan to make optional the product identifier value (`pim_catalog_identifier` attribute).
+From November 2022, the product identifier value (pim_catalog_identifier attribute) has now become optional.
 
 ## Why do we do that?
 
-At the time these lines are written (July 2022), a PIM product contains one and only one way of unique identification: the so-called field `identifier` (the only `pim_catalog_identifier` attribute of the whole product).
+A PIM used to contain one and only identification: the so-called field `identifier` (the only `pim_catalog_identifier` attribute of the whole product).
 In Serenity, this field value is the SKU (Stock Keeping Unit) of the product, but what if you need to identify your product with several product identifiers (SKU, EAN, GTIN,...)?
 Adding classic fields won't do the job: you need a kind of identifier field for each product.
 And how will you identify your product if its SKU has changed?
 
 That's the purpose of the brand-new product UUID feature.
 
-But before making it happen, a product must have a **unique** and **immutable** way to identify it: that's why we introduce the product UUID (for Universally Unique Identifier).
+But before making it happen, a product must have a **unique** and **immutable** way to identify it: that's why we introduced the product UUID (for Universally Unique Identifier).
 
 ## What are the impacts?
 
-Of course, [Products endpoints](https://api.akeneo.com/api-reference.html#Product) will remain available (and they be enriched with a `UUID` property), even when new API endpoints will be ready for use.
-Nevertheless, when the current product identifier will become optional:
+Of course, [Products endpoints](https://api.akeneo.com/api-reference.html#Product) will remain available (and they be enriched with a `UUID` property), even whith the availability of the new API endpoints.
+Nevertheless, now that the current product identifier is optional:
 - [GET /api/rest/v1/products](https://api.akeneo.com/api-reference.html#get_products) won’t return products with empty product identifiers (in other words, you may miss products if you continue to use this endpoint);
 - `associations` property for [GET /api/rest/v1/products](https://api.akeneo.com/api-reference.html#get_products) or [GET /api/rest/v1/products/{code}](https://api.akeneo.com/api-reference.html#get_products__code_) may contain **NULL** values (product associated with a product without identifier);
 -  [GET /api/rest/v1/products/{code}](https://api.akeneo.com/api-reference.html#get_products__code_) could result in a 404 error (if the identifier is removed from the product).
   ...and you could encounter some issues with your code.
 
 ## What do we advise you?
 
-As soon as product UUID API endpoints are released, jump on the bandwagon right away:
+As UUID API endpoints have now been released, we recommend you to jump on the bandwagon right away:
 - Change [product-identifier-based products endpoints](https://api.akeneo.com/api-reference.html#Product) with UUID ones.
 - Every time you identify a product with its identifier in your application, be sure to replace it by corresponding product UUID. You will easily find the match between product identifier and UUID in both [products endpoints](https://api.akeneo.com/api-reference.html#Product) and new ones.