Files path configuration for a Nextra site with GitHub integration

How to use Crowdin? Tips&Tricks
1

Hi there,

Calling for help as I’m stumbling on the configuration of files path for a Nextra.
As documented here, it requires that both source and translated files be named with a pattern like %file_name%.%two_letters_code%.%file_extension%. Thus, English source files are named %file_name%.en.%file_extension%.

My problem is that Crowdin includes the .en of the English source files names into the %file_name% placeholder, leading me to translated files named as %file_name%.en.%two_letters_code%.%file_extension%.

Is there a way to configure Crowdin to work with this site generator?

Thanks in advance for your help
TY
J

2

Well, here’s how Crowdin works with CLI (the same configaration can be applied to GitHub integration)

So it requires just a file name. Can be let’s say en.json

For now I see 2 options, either use CLI / API in Crowdin, then locally change file names and upload them to GitHub, or try to play around here based on Docs I’ve shared.

You can also simply change names in GitHub before pushing into Website.

Maybe try just %original_file_name% without any extension specified.

No other ideas than cunning name off after work is done or playing with configuration file.

1 Like
3

Hello @KateOlssenForum :slight_smile:

Thank you for your prompt answer. You sadly confirmed what I feared.
Massaging file names in or out of Crowdin could be a solution. Another one I’ve thought about would be to script the configuration file generation and update to create a source/translation entry for each file :confused:

"files": [
  {
    "source": "file1.en.md",
    "translation": "file1.%two_letter_code%.md"
  },
  {
    "source": "file2.en.md",
    "translation": "file2.%two_letter_code%.md"
  },
  ...
]

I wish some regex features were supported in addition to placeholders. This would surely help in many cases.

TY
J

4

So, in the file name it’s crucial to have some file name? Because if it’s for examle just en.json, than you can use this one

"source": "en.md",
"translation": "%two_letter_code%.%file_exteshion%". -> so it'll be de.md / fr.md / ja.md

But if it’s crucial, that yes, if you want different naming, you’ll need to change it after export. Should be a 5 minutes question to write a script to replace names.

1 Like
5

Hello friends,

Hope you’re having a beautiful weekend :slight_smile:

I have worked on a GitHub Action [1] to help reconcile this file naming pattern issue.
Put aside that it creates (too) many cancelled job runs [2], it does the job.

Nonetheless, I’m having a hard time understanding how the integration sync is triggered, and what files are synced and why !?
It seemed to work nicely, but then I changed the service branch name to use a testing branch and changed settings as shown in the joined capture. Now, no initial sync of any file and no automatic sync of translated files happens.
Further, when I trigger the sync manually, not all translated files even get synced and, for the few that do, their content isn’t even translated :sob:
I most probably have broken everything but can’t understand what and why :confused:

At this point again, any help would be very welcome :pray:

[1] Prompt-Engineering-Guide/rename_l10n_files.yml at l10n_test · silopolis/Prompt-Engineering-Guide · GitHub
[2] Actions · silopolis/Prompt-Engineering-Guide · GitHub

2023-04-23 13_05_42-Crowdin-Prompt_Engineering_Guide_settings
2023-04-23 13_05_42-Crowdin-Prompt_Engineering_Guide_settings1259×974 73.2 KB

6

You followed this guidance in full?

Screenshot you’ve shared belongs to integration (Crowdin - Github connector), not actions

With that connector, once per 1 hour system tracks updates and create a pull request in Github if there’s a new translation. Also, once this 1 hour it checks if you added new content or not.

You can use 1 thing only, or the integration, or the action, not in combination.

1 Like
7

Hi @TailorWeexed

No, I’m not using the GH action yet. I discovered it while toying with this integration setup.

I would like to get this integration working and fix my understanding of how it works before, maybe, migrating to the GH action-based workflow.

Any idea why this doesn’t work like it’s expected ?

Thanks for your help :pray:

8

I guess would be better to just connect the fresh integration from the scratch. Just maybe delete the yaml and follow the UI configurator to see all the path.

I’ve just tried in my test branch, played with all possible paths like locale, locale with underscore, 2 letters and so on, all works totaly fine.
Or use the actions, but I’d better stay with a native connector or switch to API/CLI workflow instead.