• State Not Answered
  • Replies 1 reply
  • Subscribers 136 subscribers
  • Views 889 views
  • Users 0 members are here
Options
Related

Any experience changing language codes globally, including legacy content?

F. Gress

I'm looking for anyone who has tried changing language codes when there was existing/legacy content in the target language(s).

We want to revise our TD language list (LOV) to use standard ISO language+country codes (and align with our WorldServer codes, etc).

For example, instead of 'fr' for French we want 'fr-FR' and 'fr-CA', etc. 

Our conundrum is how to handle all the legacy translated-and-released content we have that is coded 'fr'.

We do not want to leave the legacy content as-is; we want to be able to publish future pubs coded 'fr-FR' (instead of 'fr') and also re-use all the legacy 'fr' content (which, yes, was really French-for-France and should have been coded that way originally).

We are considering making the change by exporting batches, running scripts, and re-importing, but this is of course risky and a huge chore.

Any feedback based on experience would be welcome.
Rate translation
×
Suggest better translation
×
  • 0

    It is always difficult changing language codes once you have been using the system for so many years. You probably have a lot of content in your database today and since you don't want to have legacy content, it means every single XML item in the database needs to get updated.

    In theory this should be possible. Depending on the amount of content it might take a long time but we are able to download a XML object, modify the language attributes and upload it back into the repository. 

    So a simplified workflow could be:

    1. getting an overview of all XML items in the database, so you know what needs to get updated

    2. Change the language code in the system to the ISO standards.

    3. Change the Translation XML settings and Translation Organizer config

    4. Design a process to get all XML content from the database, update the language code and upload it back into the repository.

    Now this process is not without any risk. We usually recommend to never change content once it is released in the database. It is a process that will require a lot of testing, backups and downtime. You will have to test publishing as well to make sure everything still works. 

    Another item to take into consideration is reporting. If you have custom reporting, or you use the search, you can ask the system to display all items that have been modified during a certain date range. After running step 3 (update all XML content), this will no longer work, as it will display all XML items.

    In terms of best practices, the only was I see to update all content, is by using the APIs. Direct database edits are not supported and should be avoided at any costs. We have PowerShell libraries that can help you connect to the API and execute your process. However my experience is better by using a .net Console program. .Net gives you the opportunity to use a parallel for each workflow which can significantly speed up the process.