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.
Solved! Go to Solution.
Views
Replies
Total Likes
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.
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.
Hi @SHIBANI06 ,
Just incase if you are using AEMaaCS, it has to pushed to higher environments via Source Code through CI/CD pipeline.
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