Using Localization tables

[jensc]

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:

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

[VladimirRosu · Accepted solution]

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.

[jensc]

Hello @VladimirRosu,

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

[jensc]

Hello,

I did some modifications to not have to use the GIT template and instead use input parameters for the local FileRepo and FileRepoPath.

This then as you say export just the tokens with whatever prefix has been input.

However you still get all of the other language tables in the repository as well;

I suppose if you really wanted to you could change the code so as to not export any tables that do not contain your prefix.

Then I tried using the import from source control entities;

Which seems to have worked fine as my token was imported successfully.

So I guess it would probably work with having the "LocalizationTables" folder in your GIT if you wanted to import everything at once.

Thank you for your help.

Regards,

Jens

[VladimirRosu]

Many thanks for letting the community know about this Jens,

Happy to see it worked and good luck going forward!