Expand my Community achievements bar.

SOLVED

Best practices - i18n keys migration

Avatar

Level 4

I have a set of new i18n keys which will have translations in a couple of languages and I want to move all the new keys to a higher environment(Production).
I want to know the best possible way to do this migration.

As this has to be done on Production and there are a lot of keys, we want to do it on a lower environment and then migrate the keys to Production.
It would be helpful if I get some suggestions on best practices to move the i18n keys.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

The best way in my opinion is (assuming that you are not planning to store the i18n in the code, and you are not on AEMaaCS, and you don't have the i18n in the code)

1. Schedule a content freeze with the content authors.

2. Pull all dictionary down from production.

3. Push dictionary keys into a lower environment, example DEV enironment.

4. Apply all changes. 

5.review all changes via pair programming, making sure everything looks alright from /libs/cq/i18n/translator.html

8. Release package to QA. Making sure that everything looks okay, they can use /libs/cq/i18n/translator.html.

9. With the same content package, attach it to the release document. 

 

10. On release day, release it. (clear the cache)

11, send notifications to authors, they are okay to resume on i18n changes. 

=====

However for newer projects, keeping the i18n keys in the code, from experience, is more easier to manage these things.

View solution in original post

3 Replies

Avatar

Correct answer by
Community Advisor

The best way in my opinion is (assuming that you are not planning to store the i18n in the code, and you are not on AEMaaCS, and you don't have the i18n in the code)

1. Schedule a content freeze with the content authors.

2. Pull all dictionary down from production.

3. Push dictionary keys into a lower environment, example DEV enironment.

4. Apply all changes. 

5.review all changes via pair programming, making sure everything looks alright from /libs/cq/i18n/translator.html

8. Release package to QA. Making sure that everything looks okay, they can use /libs/cq/i18n/translator.html.

9. With the same content package, attach it to the release document. 

 

10. On release day, release it. (clear the cache)

11, send notifications to authors, they are okay to resume on i18n changes. 

=====

However for newer projects, keeping the i18n keys in the code, from experience, is more easier to manage these things.

Avatar

Community Advisor

Hi @SHIBANI06 ,

 

Just incase if you are using AEMaaCS, it has to pushed to higher environments via Source Code through CI/CD pipeline.

Avatar

Community Advisor

@SHIBANI06 

1.Best way to migrate the i18 folder via Package manager console.
2.Create/Install the i18 packages from Author to Author and Publisher to Publisher instance
e.g create i18 package in Dev Author and install the Package in UAT Author only (To avoid configuration conflicts between Author and Publisher)
3.Once the package is created and modify the filter mode of package to "merge" instead of "overwrite" (To avoid configuration overwrite in Production)


Refer this document to perform the filter change:
https://www.albinsblog.com/2019/05/how-to-enable-merge-mode-for-packages-in-aem.html

https://www.albinsblog.com/2016/04/how-to-manage-i18-translation-in-adobe-CQ5-AEM.html

 

Regards,

Raja