Managing translations after changing key structure

General Questions
,
1

I am the administrator of a project where the source file was created by concatenating language files from different locations.

For example, we have:

  • folder1/Language.properties
  • folder2/Language.properties
  • folder3/Language.properties

These files are combined into a single file, which is then imported as the source file into Crowdin.

Because the source file is built from different Language.properties files, the keys are prefixed with a plugin name to ensure uniqueness. For instance:

  • lang.file.1.plugin.name__key=key-value
  • lang.file.2.plugin.name__key=key-value
  • lang.file.3.plugin.name__key=key-value

In practice, this looks like:

  • com.test.portal.language.lang__remote-site-id=Remote Site ID
  • portal-web__c2p9-label=C2P9 Slider
  • com.test.portal.language.lang__orders=Orders

We have an internal application that downloads the translations zip file, filters the keys by their plugin name, and then distributes them to their respective Language_${locale}.properties files. It’s important to note that the plugin name is removed during this process; it is only used to determine which file the key belongs to.

My question is: I plan to change the process to use only one source file, which would eliminate the need for keys to have a plugin name. If I make this change, will the pre-existing translations be lost, since their keys still contain the plugin name?

2

Hello @davi.santos!

Could you please provide additional details about the application that you are working with? Does it make use of the Crowdin API or CLI by any chance? Additionally, what is the original format of your source files, and in what format are you uploading your translations?

Have you considered utilizing pre-translation through Translation Memory?

4

Hi @DianaO,

I basically want to deprecate an old sync process that uses the Crowdin API and CLI (the internal application I mentioned). The intention is to replace it with a workflow based on GitHub Actions.

As I mentioned in my first message, the old sync process concatenates some Language.properties files and uses them as the source file in Crowdin.

Here’s a example of this source file:

com.liferay.portal.language.lang__zoom-in=Zoom In
com.liferay.portal.language.lang__zoom-out=Zoom Out
com.liferay.portal.language.lang__zoom-to-fit=Zoom to Fit
com.liferay.portlet.tck.bridge__portlet-tck-bridge-configuration-name=Portlet TCK Bridge
portal-web__c2p9-description=Select a number using a slider.
portal-web__c2p9-label=C2P9 Slider
portal-web__oauth2.application.description.liferay-oauth2-scope-sample-qa-app=Sample QA app
portal-web__oauth2.scope.example-scope-1=Example scope 1
portal-web__oauth2.scope.example-scope-2=Example scope 2
portal__do-you-like-to-eat-pizza-with-anchovies=Do you like to eat pizza with anchovies?

The prefix before the double underscore (__) represents the plugin name, which indicates which file the keys belong to. However, when I migrate this old sync process to the GitHub Action, I’ll use only one source file, so the plugin names won’t be needed anymore. I’ll only keep the com.liferay.portal.language.lang keys. For example:

zoom-in=Zoom In
zoom-out=Zoom Out
zoom-to-fit=Zoom to Fit

My concern is what will happen when I upload the new source file without the plugin names, since all the pre-existing translations were added with keys that include those prefixes. For example, in pt_BR the translations were added like:

com.liferay.portal.language.lang__zoom-in=Ampliar
com.liferay.portal.language.lang__zoom-out=Afastar
com.liferay.portal.language.lang__zoom-to-fit=Ajustar

So, when I switch to the new source file with the prefixes removed, will these pre-existing translations be preserved?

The original format of the source file is .properties, and the new source file I’ll add has the same format. The only difference is that I’ll remove the plugin name prefix from the keys.

Also, I don’t want to use pre-translation. I want to make sure that after I upload the new source file, the current translations won’t be lost.

5

Ok, I tried uploading the new source file without the plugin names, and this was the result:

  • Some translations were correctly preserved, but a significant number of translations were lost (a bit less than 40%).
  • For the translations that were correctly preserved, they went from being “translated and approved” to just “translated.”

So, even the ones that were preserved are no longer approved. Does this mean I’ll need to approve each one individually again? Is there an easier way to do this without losing so much data?

6

Hello @davi.santos!

Thanks for sharing the details,

In the situation, when you had already “translated and approved” strings (which means they are stored in the respective Translation Memory), and no modification was made to the source text, you can run “pre-translation via TM” and make sure that the option “Approve added translations” is enabled. This way, you would add and approve the translations at the same time.

Since .properties is a key-valued file format, you can alternatively use the “Upload existing translations” option from the “Translations” tab of your project (in case you have previously downloaded them). There, you could also choose whether to automatically approve those translations or not. However, using this option requires key matching between the source file and translations.

Hope this helps!

7

Hi @Viacheslav,

I’ll try the pre-translation via translation memory and get back with an update as soon as possible.

Thanks for the quick response.

8

@davi.santos Sure, take your time!

Just one thing to mention here: you need to be sure that the appropriate translations were saved within the respective TM and that they have at least 100% match, meaning that the translation text was not modified (if we are speaking about Crowdin.com). In the Crowdin Enterprise version, the TM match needs to be a minimum 40%.

9

@Viacheslav Thanks for the heads-up!

For the project I’m working on, we’re using Crowdin.com.