Non-existing keys in export

Crowdin Issues
1

Hi,

I am working on the Mastodon project and I am currently improving our Crowdin integration with our Github Repository.

We are using the Github action to download the translations and create a Pull Request with them: https://github.com/mastodon/mastodon/blob/main/.github/workflows/crowdin-download.yml

There is a PR generated by the action:

In the export generated by the action, the file config/locales/af.yml contains those keys:

af:
  errors:
    '400': The request you submitted was invalid or malformed.
    '403': Jy het nie toestemming om hierdie bladsy te sien nie.
    '404': The page you are looking for isn't here.
    '406': This page is not available in the requested format.
    '410': The page you were looking for doesn't exist here anymore.
    '422':
    '429': Too many requests
    '500':
    '503': The page could not be served due to a temporary server failure.

But af.errors.500 does not exists, it should be af.errors.500.content and af.errors.500.title.

I download an export from Crowdin’s interface, and confirmed that those are the same in the manual export.

Those keys appears correctly in the base config/locales/en.yml file from the repo as well as in Crowdin’s UI:

image
image946Ă—376 19.9 KB

I am not sure what is happening here, could you explain why incorrect keys are appearing in the export?

We are running various checks on the locale files, and it causes them to fail (see build log here)

Thanks!

2

Hello,

Thank you for details! Passing issue to our tech team.

1 Like
3

Thanks @NataliaS. Did you hear anything from them?

4

Due to the “skip untranslated strings” option enabled in your Crowdin project, the export results in empty keys for the untranslated strings.

5

Thanks @Natalia, but I am not sure to understand.

Why would this option be an issue with only some languages, and cause some keys to be empty instead of containing the sub-keys that the original file contains?

Or maybe the issue is that those sub-keys do not have a translation in those languages, and as we skip untranslated strings, this skips every sub-key, but there is still the parent key, but empty (no sub-keys)?

It would probably be best to have your export code remove any key that does not contain sub-keys, as it causes issues in our case (because those keys were plain strings before, and then changes to sub-keys)

6

Hi,

If the string has translation in some language, it’ll be exported with the Skip untranslated strings option, however, if there is no translation to the same string in some language, the string won’t be exported in that specific language

Hope it helps,