adding fr-fr & en-gb versions

Author: benchbzh

pages/storage_and_backup/object_storage/s3_bucket_lifecycle/guide.en-gb.md

@@ -1,7 +1,7 @@
 ---
 title: Object Storage - Smart Storage Management with Lifecycle Rules
 excerpt: Learn how to optimise your storage costs with OVHcloud lifecycle rules
-updated: 2025-04-03
+updated: 2025-04-29
 ---
 
 <style>
@@ -155,13 +155,57 @@ In a versioning-enabled bucket, each object has one current version and zero or
 | Expiration.Days                                     | yes*     | Indicates the duration in days after which the objects are to be deleted. The value must be an integer equal to or greater than 1. </br></br> ⚠️ This attribute is mandatory if Date is not present. </br> ⚠️ this attribute is mutually exclusive with Date i.e you either have Date or Days but you cannot specify both. |
 | Expiration.ExpiredObjectDeleteMarker                | no       | Tells if OVHcloud Object Storage should immediately remove delete markers with no noncurrent versions aka expired delete markers. </br></br> ⚠️ You cannot specify Days or Date with ExpiredObjectDeleteMarker in the same rule. When you specify the Days/Date, expired delete markers are automatically deleted like normal objects when they satisfy the age criteria. ExpiredObjectDeleteMarker is used to clean up delete markers as soon as they become the only version, you have to create a separate rule with only ExpiredObjectDeleteMarker attribute in Expiration. </br> ⚠️ When you use the ExpiredObjectDeleteMarker lifecycle action, the rule cannot specify a tag-based filter. |
 | NoncurrentVersionExpiration                         | no       | A lifecycle action that indicates when noncurrent object versions should be deleted. This action does not affect the current versions. It only deletes the versions that are not current. |
-| NoncurrentVersionExpiration.NoncurrentDays          | no       | Indicates the number of days before a noncurrent version is eligible to deletion after they became noncurrent i.e the minimum age of a noncurrent version. </br> Example: </br></br> Suppose you have an object A with 10 versions: </br> - A v10 (current version, creation date: 2024-10-23) </br> - A v9 (noncurrent version, creation date: 2024-10-22) </br> - A v8 (noncurrent version, creation date: 2024-10-21) </br> - A v7 (noncurrent version, creation date: 2024-10-20) </br> - A v6 (noncurrent version, creation date: 2024-10-19) </br> - A v5 (noncurrent version, creation date: 2024-10-18) </br> - A v4 (noncurrent version, creation date: 2024-10-17) </br> - A v3 (noncurrent version, creation date: 2024-10-16) </br> - A v2 (noncurrent version, creation date: 2024-10-15) </br> - A v1 (noncurrent version, creation date: 2024-10-14) </br></br> If current date is 2024-10-23 and **NoncurrentDays**=5, the lifecycle rule will delete the noncurrent versions older than 5 days i.e v1, v2, v3, v4 and v5. |
+| NoncurrentVersionExpiration.NoncurrentDays          | no       | Indicates the number of days before a noncurrent version is eligible to deletion after they became noncurrent i.e the minimum age of a noncurrent version. |
 | NoncurrentVersionExpiration.NewerNoncurrentVersions | no       | Indicates the number of most recent noncurrent versions to retain. Maximum is 100. </br></br> Example: </br> Suppose you have an object B with 10 versions: </br> - B v10 (current version, creation date: 2024-10-23) </br> - B v9 (noncurrent version, creation date: 2024-10-22) </br> - B v8 (noncurrent version, creation date: 2024-10-21) </br> - B v7 (noncurrent version, creation date: 2024-10-20) </br> - B v6 (noncurrent version, creation date: 2024-10-19) </br> - B v5 (noncurrent version, creation date: 2024-10-18) </br> - B v4 (noncurrent version, creation date: 2024-10-17) </br> - B v3 (noncurrent version, creation date: 2024-10-16) </br> - B v2 (noncurrent version, creation date: 2024-10-15) </br> - B v1 (noncurrent version, creation date: 2024-10-14) </br></br> If **NewerNoncurrentVersions**=3, the lifecycle rule will delete all the noncurrent versions except the 3 most recent i.e v9, v8 and v7. |
 | AbortIncompleteMultipartUpload                      | no       | A lifecycle action that applies a delete operation on parts of an incomplete multipart upload. |
 | AbortIncompleteMultipartUpload.DaysAfterInitiation  | no       | Indicates the number of days after which all the parts of all incomplete multipart uploads are deleted and aborts the underlying multipart uploads. |
 
 ///
 
+### Understanding the NoncurrentDays parameter
+
+The NoncurrentDays parameter defines the minimum number of days since a version is no longer current. This paramater must not be confused with the age of the object but rather indicates the minimum age of a non-current version.
+
+**Example 1:**
+
+Suppose you have an object A with 10 versions:
+
+- A v10 (current version, creation date: 2024-10-23).
+- A v9 (noncurrent version, creation date: 2024-10-22).
+- A v8 (noncurrent version, creation date: 2024-10-21).
+- A v7 (noncurrent version, creation date: 2024-10-20).
+- A v6 (noncurrent version, creation date: 2024-10-19).
+- A v5 (noncurrent version, creation date: 2024-10-18).
+- A v4 (noncurrent version, creation date: 2024-10-17).
+- A v3 (noncurrent version, creation date: 2024-10-16).
+- A v2 (noncurrent version, creation date: 2024-10-15).
+- A v1 (noncurrent version, creation date: 2024-10-14).
+
+If current date is 2024-10-23 and **NoncurrentDays**=5, the lifecycle rule will delete the noncurrent versions older than 5 days i.e v1, v2, v3 and v4 because:
+
+- A v1 is non-current since 2024-10-15 (when A v2 was created) i.e its age as a non-current version is 8 days.
+- A v2 is non-current since 2024-10-16 (when A v3 was created) i.e its age as a non-current version is 7 days.
+- A v3 is non-current since 2024-10-17 (when A v4 was created) i.e its age as a non-current version is 6 days.
+- A v4 is non-current since 2024-10-18 (when A v5 was created) i.e its age as a non-current version is 5 days.
+
+
+**Example 2:**
+
+Suppose you have an object B with 5 versions:
+
+- B v5 (current version, creation date: 2024-10-28).
+- B v4 (noncurrent version, creation date: 2024-10-27).
+- B v3 (noncurrent version, creation date: 2024-10-20).
+- B v2 (noncurrent version, creation date: 2024-10-15).
+- B v1 (noncurrent version, creation date: 2024-10-14).
+
+If current date is 2024-10-29 and **NoncurrentDays**=5, the lifecycle rule will delete the noncurrent versions older than 5 days i.e only v1 and v2 because:
+
+- B v1 is non-current since 2024-10-15 (when B v2 was created) i.e its age as a non-current version is 14 days.
+- B v2 is non-current since 2024-10-20 (when B v3 was created) i.e its age as a non-current version is 9 days.
+
+
+
 ### Get the scheduled expiration date
 
 If an object is scheduled to be deleted, a HEAD-OBJECT call will return a special http response header x-amz-expiration that contains a timestamp indicating its expiry date and an id of the lifecycle rule that has been applied.
@@ -693,4 +737,4 @@ Delete operations resulting from application of lifecycle rules are not replicat
 
 If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project.
 
-Join our [community of users](/links/community).
+Join our [community of users](/links/community).

pages/storage_and_backup/object_storage/s3_bucket_lifecycle/guide.en-ie.md

@@ -163,6 +163,7 @@ In a versioning-enabled bucket, each object has one current version and zero or
 ///
 
 ### Understanding the NoncurrentDays parameter
+
 The NoncurrentDays parameter defines the minimum number of days since a version is no longer current. This paramater must not be confused with the age of the object but rather indicates the minimum age of a non-current version.
 
 **Example 1:**
@@ -732,4 +733,4 @@ Delete operations resulting from application of lifecycle rules are not replicat
 
 If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project.
 
-Join our [community of users](/links/community).
+Join our [community of users](/links/community).

pages/storage_and_backup/object_storage/s3_bucket_lifecycle/guide.fr-ca.md

@@ -731,4 +731,4 @@ Les opérations de suppression résultant de l'application des règles de cycle
 
 Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.
 
-Échangez avec notre [communauté d'utilisateurs](/links/community).
+Échangez avec notre [communauté d'utilisateurs](/links/community).

pages/storage_and_backup/object_storage/s3_bucket_lifecycle/guide.fr-fr.md

@@ -1,7 +1,7 @@
 ---
 title: Object Storage - Gestion intelligente du stockage avec des règles lifecycle
 excerpt: "Découvrez comment optimiser vos coûts de stockage avec les règles lifecycle d'OVHcloud"
-updated: 2025-04-03
+updated: 2025-04-29
 ---
 
 <style>
@@ -71,8 +71,8 @@ En règle générale, la fonction lifecycle est conçue pour vous aider à optim
 
 En règle générale, lorsque plusieurs règles s'appliquent au même ensemble d'objets dans une configuration de bucket lifecycle :
 
-- La suppression permanente a la priorité sur la transition
-- La transition a la priorité sur la création de marqueurs de suppression
+- La suppression permanente a la priorité sur la transition.
+- La transition a la priorité sur la création de marqueurs de suppression.
 - La date d'expiration/de transition la plus courte a la priorité sur la plus longue.
 
 ### Versions courantes et versions non courantes
@@ -155,13 +155,56 @@ Dans un bucket versionné, chaque objet a une version courante et zéro ou plusi
 | Expiration.Days                                     | oui*     | Indique la durée en jours après laquelle les objets doivent être supprimés. La valeur doit être un nombre entier égal ou supérieur à 1. </br></br> ⚠️ Cet attribut est obligatoire si Date n'est pas présent. </br> ⚠️ Cet attribut s'exclut mutuellement avec Date, c'est-à-dire que vous avez soit Date, soit Days, mais vous ne pouvez pas spécifier les deux. |
 | Expiration.ExpiredObjectDeleteMarker                | non       | Indique si OVHcloud Object Storage doit immédiatement supprimer les marqueurs de suppression qui n'ont pas de versions non courantes (marqueurs de suppression expirés). </br></br> ⚠️ Vous ne pouvez pas spécifier Days ou Date avec ExpiredObjectDeleteMarker dans la même règle. Lorsque vous spécifiez Days/Date, les marqueurs de suppression expirés sont automatiquement supprimés comme des objets normaux lorsqu'ils satisfont aux critères d'âge. ExpiredObjectDeleteMarker est utilisé pour nettoyer les marqueurs de suppression dès qu'ils deviennent la seule version. Vous devez créer une règle séparée avec uniquement l'attribut ExpiredObjectDeleteMarker dans Expiration. </br> ⚠️ Lorsque vous utilisez l'action de lifecycle ExpiredObjectDeleteMarker, la règle ne peut pas spécifier un filtre basé sur un tag. |
 | NoncurrentVersionExpiration                         | non       | Une Action de lifecycle qui indique quand les versions d'objets non courantes doivent être supprimées. Cette action n'affecte pas les versions courantes. Elle supprime uniquement les versions qui ne sont pas à jour. |
-| NoncurrentVersionExpiration.NoncurrentDays          | non       | Indique le nombre de jours avant qu'une version non courante soit éligible à la suppression après qu'elle soit devenue non courante, c'est-à-dire l'âge minimum d'une version non courante. </br> Exemple : </br></br>  Supposons que vous ayez un objet A avec 10 versions : </br> - A v10 (current version, creation date: 2024-10-23) </br> - A v9 (non-current version, creation date: 2024-10-22) </br> - A v8 (non-current version, creation date: 2024-10-21) </br> - A v7 (non-current version, creation date: 2024-10-20) </br> - A v6 (non-current version, creation date: 2024-10-19) </br> - A v5 (non-current version, creation date: 2024-10-18) </br> - A v4 (non-current version, creation date: 2024-10-17) </br> - A v3 (non-current version, creation date: 2024-10-16) </br> - A v2 (non-current version, creation date: 2024-10-15) </br> - A v1 (non-current version, creation date: 2024-10-14) </br></br> Si la date actuelle est 2024-10-23 et **NoncurrentDays**=5, la règle de lifecycle supprimera les versions non courantes datant de plus de 5 jours, c'est-à-dire v1, v2, v3, v4 et v5. |
+| NoncurrentVersionExpiration.NoncurrentDays          | non       | Indique le nombre de jours avant qu'une version non courante soit éligible à la suppression après qu'elle soit devenue non courante, c'est-à-dire l'âge minimum d'une version non courante. |
 | NoncurrentVersionExpiration.NewerNoncurrentVersions | non       | Indique le nombre de versions non courantes les plus récentes à conserver. Le maximum est de 100. </br></br> Exemple: </br> Supposons que vous ayez un objet B avec 10 versions : </br> - B v10 (current version, creation date: 2024-10-23) </br> - B v9 (non-current version, creation date: 2024-10-22) </br> - B v8 (non-current version, creation date: 2024-10-21) </br> - B v7 (non-current version, creation date: 2024-10-20) </br> - B v6 (non-current version, creation date: 2024-10-19) </br> - B v5 (non-current version, creation date: 2024-10-18) </br> - B v4 (non-current version, creation date: 2024-10-17) </br> - B v3 (non-current version, creation date: 2024-10-16) </br> - B v2 (non-current version, creation date: 2024-10-15) </br> - B v1 (non-current version, creation date: 2024-10-14) </br></br> Si **NewerNoncurrentVersions**=3, la règle de lifecycle supprimera toutes les versions non courantes à l'exception des trois plus récentes, à savoir v9, v8 et v7. |
 | AbortIncompleteMultipartUpload                      | non       | Une action de lifecycle qui applique une opération de suppression sur les parties d'un téléchargement multi-parties incomplet. |
 | AbortIncompleteMultipartUpload.DaysAfterInitiation  | non       | Indique le nombre de jours après lequel toutes les parties de tous les téléchargements multi-parties incomplets sont supprimées et interrompt les téléchargements multi-parties sous-jacents. |
 
 ///
 
+### Comprendre le paramètre NoncurrentDays
+
+Le paramètre NoncurrentDays définit le nombre minimum de jours écoulés depuis qu'une version n'est plus la version courante. Ce paramètre ne doit pas être confondu avec l'âge de l'objet mais indique plutôt l'âge minimum d'une version non-courante.
+
+**Exemple 1:**
+
+Supposons que vous avez un objet A avec 10 versions :
+
+- A v10 (version courante, date de création: 2024-10-23).
+- A v9 (version non-courante, date de création: 2024-10-22).
+- A v8 (version non-courante, date de création: 2024-10-21).
+- A v7 (version non-courante, date de création: 2024-10-20).
+- A v6 (version non-courante, date de création: 2024-10-19).
+- A v5 (version non-courante, date de création: 2024-10-18).
+- A v4 (version non-courante, date de création: 2024-10-17).
+- A v3 (version non-courante, date de création: 2024-10-16).
+- A v2 (version non-courante, date de création: 2024-10-15).
+- A v1 (version non-courante, date de création: 2024-10-14).
+
+Si la date actuelle est 2024-10-23 et **NoncurrentDays**=5, la règle de lifecycle supprimera les versions non-courantes de plus de 5 jours : v1, v2, v3 et v4, car :
+
+- A v1 est non-courante depuis 2024-10-15 (quand A v2 a été créée) : son âge en tant que version non-courante est 8 jours.
+- A v2 est non-courante depuis 2024-10-16 (quand A v3 a été créée) : son âge en tant que version non-courante est 7 jours.
+- A v3 est non-courante depuis 2024-10-17 (quand A v4 a été créée) : son âge en tant que version non-courante est 6 jours.
+- A v4 est non-courante depuis 2024-10-18 (quand A v5 a été créée) : son âge en tant que version non-courante est 5 jours.
+
+
+**Exemple 2:**
+
+Supposons que vous avez un objet B avec 5 versions :
+
+- B v5 (version courante, date de création: 2024-10-28).
+- B v4 (version non-courante, date de création: 2024-10-27).
+- B v3 (version non-courante, date de création: 2024-10-20).
+- B v2 (version non-courante, date de création: 2024-10-15).
+- B v1 (version non-courante, date de création: 2024-10-14).
+
+Si la date actuelle est 2024-10-29 et **NoncurrentDays**=5, la règle de lifecycle supprimera les versions non-courantes de plus de 5 days : uniquement v1 et v2, car :
+
+- B v1 est non-courante depuis 2024-10-15 (quand B v2 a été créée) : son âge en tant que version non-courante est 14 jours.
+- B v2 est non-courante depuis 2024-10-20 (quand B v3 a été créée) : son âge en tant que version non-courante est 9 jours.
+
+
 ### Obtenir la date d'expiration programmée
 
 Si un objet est programmé pour être supprimé, un appel HEAD-OBJECT renvoie un en-tête de réponse http spécial x-amz-expiration qui contient un timestamp indiquant sa date d'expiration et un identifiant de la règle du lifecycle qui a été appliquée.
@@ -693,4 +736,4 @@ Les opérations de suppression résultant de l'application des règles de cycle
 
 Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.
 
-Échangez avec notre [communauté d'utilisateurs](/links/community).
+Échangez avec notre [communauté d'utilisateurs](/links/community).