Skip to main content
J
jensc17-Peridot
17-Peridot
January 20, 2023
Solved

Using Localization tables

  • January 20, 2023
  • 1 reply
  • 1481 views

Hello All,

 

I was wondering if anyone has any experience with using the localization tables in platforms that are shared by other projects.

 

Most of our platforms will be shared amongst plenty of other projects and teams. And by doing this, any changes to the localization table we do in our team, will also get imported into different environments (SIT/QA/Pilot/Prod) when other teams need to deploy their changes.

 

So if we have done some tests or improper translations in some of our localization tables, other teams might not notice and bring these issues into the different environments.

 

Has anyone else dealt with this?

 

Also, how can we in a good way deploy the localization tokens? Can we in some way export them as "source control" entities?

Is it even possible to put them together with other source control entities folders?

Something like this:

jensc_1-1674202046248.png

I think it's not really possible though.

 

I did find this with a bunch of information about the localization tables, but it didn't really answer my questions.

 

Thanks,

Jens

 

 

Best answer by VladimirRosu_116627

Hi @jensc ,

 

The localization tokens should be specific for the Application/Project at hand. Usually we do this by adding a prefix to an application tokens to make them specific for that application.

The prefix would help when exporting them. Localization Tokens can be exported as Source Control Entities. While it is correct you can not export a subset of localization Tokens matching the prefix above directly from the platform, you can build a custom service that does that.

My colleague Tanguy Parmentier was kind enough to create in Oct 2020 a service called "ExportLocalizationToken" and added it in the Git.Utility.ThingShape from the GitBackupExtension. Look in this service as inspiration.

The import part is a bit tougher, because I did not touch it recently. From memory: when you would import the resulted Localization File, they would overwrite the existing tokens, not all the table (as far as I remember, please don't take it for granted and verify first). So ideally you should make sure the token names at least are correct.

1 reply

V
VladimirRosu_11662719-TanzaniteAnswer
19-Tanzanite
January 20, 2023

Hi @jensc ,

 

The localization tokens should be specific for the Application/Project at hand. Usually we do this by adding a prefix to an application tokens to make them specific for that application.

The prefix would help when exporting them. Localization Tokens can be exported as Source Control Entities. While it is correct you can not export a subset of localization Tokens matching the prefix above directly from the platform, you can build a custom service that does that.

My colleague Tanguy Parmentier was kind enough to create in Oct 2020 a service called "ExportLocalizationToken" and added it in the Git.Utility.ThingShape from the GitBackupExtension. Look in this service as inspiration.

The import part is a bit tougher, because I did not touch it recently. From memory: when you would import the resulted Localization File, they would overwrite the existing tokens, not all the table (as far as I remember, please don't take it for granted and verify first). So ideally you should make sure the token names at least are correct.

    J
    jensc17-PeridotAuthor
    17-Peridot
    January 20, 2023

    Hello @VladimirRosu_116627,

    Thank you for your response.

     

    I will have a look at this utility tool and check back here once I understand the code.

    From what you say it sounds like it fetches any localization tokens from the localization tables that contain a specific prefix and pushes this into its own kind of localization table xml file.

     

    So this might be a good way to deal with this at least for exporting the "correct" tokens.

    And for now perhaps we'll need to import them manually.

     

    Thanks,

    Jens

    Terms & ConditionsCookie settingsAccessibility statement