Questions on best practices

A few questions…

  1. What is the best practice for specifying languages in crowdin? en/en-US is my project default… should those be included or excluded from Crowdin/Settings/Languages/Target Languages? (I want to ensure the english options are still selectable from language pickers, like in the JS Proxy Translator)

  2. Should I select English or English, United States as the source language?

  3. Currently I have English selected as the source language, and it’s also selected in the target languages. This is somewhat annoying as it requires the English to actually be translated. Is there a way just apply the default strings to a language? Ideally I shouldn’t have to do any translation for English or English, United States

  4. Given the below configuration in a GitHub repository, is there a way to rename a file when uploading it to Crowdin? It seems that below option (translation_replace) only renames when sending files back to GitHub if I were to use %original_filename%. Basically, I don’t want the file to appear as en.json in Crowdin if possible.

---
"base_path": "."
"base_url": "https://api.crowdin.com"  # optional (for Crowdin Enterprise only)
"preserve_hierarchy": false  # flatten tree on crowdin
"pull_request_labels": [
  "crowdin",
  "l10n"
]

"files": [
  {
    "source": "/strings/en.json",
    "translation": "/strings/%two_letters_code%.%file_extension%",
    "translation_replace": {
      "en": "strings"
    },
    "languages_mapping": {
      "two_letters_code": {
        # map non-two letter codes here, left side is crowdin designation, right side is project designation
        "en-GB": "en-gb",
        "en-US": "en-us"
      }
    }
  }
]

Hello @ReenigneArcher

For the 1,2,3 questions - it depends on your setup. Usually, there’s no need to have English as both source and target, because you already have sources in English.

As for en-GB or en-US, from my personal experience, en-EN (English) is more popular and is used as a Source language more often. I can suggest only having the same source in all projects, if it’s en-US, then have it in project1, project2, etc. In this case, Translation memory can be easily shared because of the source language match.

Do you have a specific issue with JS Proxy (JS Proxy Translator by Crowdin | Translate & localize your content)? If yes, please reach us by email to support@crowdin.com with a full problem description.

As for file name, “dest” is used to replace the name in Crowdin (translators will see the name you give, not the actual file name):

1 Like

Thanks for the fast response!

I don’t have a specific issue with JS Proxy. Was just curious if I removed English from the target languages if it would still be selectable from the language selector. It’s probably moot though, as I think I need to keep the target languages enabled (or handle it in the build process by copying those specific languages)

dest is perfect, that is exactly what I was looking for.

… I guess I’d like to request a feature.

In the target languages, it would be amazing if you could select a checkbox to make that language automatically match the source. So no translation or approval would be required.

I know this can be done through the CLI tool with some scripting, but it would be a lot easier if it were just a configuration option.

It’s great to hear that you don’t have any specific issues!

Sure thing, feel free to submit your feature request idea here:

If it receives a lot of votes, we will definitely bring it to life :slight_smile:

1 Like

@Dima

I’m having an issue with the dest option.

Here is my full crowdin.yml

---
"base_path": "."
"base_url": "https://api.crowdin.com"  # optional (for Crowdin Enterprise only)
"preserve_hierarchy": false  # flatten tree on crowdin
"pull_request_labels": [
  "crowdin",
  "l10n"
]

"files": [
  {
    "source": "/Contents/Strings/*.po",
    "translation": "/Contents/Strings/%two_letters_code%/LC_MESSAGES/%original_file_name%",
    "languages_mapping": {
      "two_letters_code": {
        # map non-two letter codes here, left side is crowdin designation, right side is babel designation
        "en-GB": "en_GB",
        "en-US": "en_US"
      }
    }
  },
  {
    "source": "/Contents/Strings/en.json",
    "dest": "/themerr-plex.json",
    "translation": "/Contents/Strings/%two_letters_code%.%file_extension%",
    "languages_mapping": {
      "two_letters_code": {
        # map non-two letter codes here, left side is crowdin designation, right side is plex designation
        "en-GB": "en-gb",
        "en-US": "en-us"
      }
    }
  }
]

I previously didn’t have the dest option, so the file was uploaded directly as en.json. When I added the dest option, I noticed it wasn’t updated in Crowdin, so I manually renamed it in the sources tab.

After two languages finished translations on that file, I tried to sync it back to GitHub and it wouldn’t sync. So I paused the GitHub integration and resumed it… when I did this it recreated the en.json file and that is the file it is trying to send back to my repo. It is ignoring the themerr-plex.json file. Any ideas?

The project on crowdin is here: https://crowdin.com/project/lizardbyte

And on GitHub: https://github.com/LizardByte/Themerr-plex

Hi!
You need to sync the file via integration in both ways in order to successfully send it back to my repo, you can’t just rename it manually. Please make sure that you correctly specified the file pathes for the themerr-plex.json file and try one more time

Hi Tetiana,

Thank you for the reply. I have “synced” about 100 times, it doesn’t make any difference.

The config is shown properly when I go to branch configuration

It seems to be ignoring the dest option.

I also tried changing dest to /Contents/Strings/themerr-plex.json as a test, but the issue is the same.

I wonder if the "preserve_hierarchy": false option is messing with dest?

Hi @ReenigneArcher , if you use the dest parameter, the configuration file should include the preserve_hierarchy parameter with the true value. Coul you please try it?

1 Like

@NataliaM if I change preserve hierarchy to true, can I use "dest": "/themerr-plex.json"? Ideally, I don’t want contributors having to navigate a nested folder structure.

I think it’s working like this. I’ll have to keep an eye on it to see if it’s syncing correctly.

Dear @ReenigneArcher , yes, if you change the preserve hierarchy to true, you can use "dest" parameter. Sure, you’re welcome to track the correctness of the sync

1 Like

I think this is working (at least in 2 repositories).

In a 3rd repository, I think I discovered a bug with the github integration.

crowdin.yml

---
"base_path": "."
"base_url": "https://api.crowdin.com"  # optional (for Crowdin Enterprise only)
"preserve_hierarchy": true  # false will flatten tree on crowdin, but doesn't work with dest option
"pull_request_labels": [
  "crowdin",
  "l10n"
]

"files": [
  {
    "source": "/Jellyfin.Plugin.Themerr/Locale/en.json",
    "dest": "/themerr-jellyfin.json",
    "translation": "/Jellyfin.Plugin.Themerr/Locale/%two_letters_code%.%file_extension%",
    "update_option": "update_as_unapproved"
  }
]

This will not load on crowdin. There’s no useful messages that I can see to help diagnose it.


This is my 6th repository I’m setting up in this project, and the first one I’ve had this issue on.

My guess is it doesn’t like the . in the directory names. If that’s what’s causing it, I’d consider this a bug.

Same issue if I use /Locale/en.json

YAML really likes indentations, you can try following config:

base_path: .
base_url: https://api.crowdin.com
preserve_hierarchy: true
pull_request_labels:
  - crowdin
  - l10n
files:
  - source: /Jellyfin.Plugin.Themerr/Locale/en.json
    dest: /themerr-jellyfin.json
    translation: /Jellyfin.Plugin.Themerr/Locale/%two_letters_code%.%file_extension%
    update_option: update_as_unapproved

I’m aware. I run yamllint on all yaml files in my repos before they’re merged.

I’ll try the format you suggested, but wouldn’t make sense if that works versus mine. I have used the format in mine on 5 other projects without issue… And it’s also what’s used in all the examples in the docs.

Same issue using that format. It’s functionally equivalent yaml, so that makes sense.

I found the issue.

This project is a C# project, using JetBrains Rider as an IDE. By default, this IDE adds a BOM to newly created UTF-8 files, and the BOM is what was causing the issue.

I only thought of this as I had the issue previously with docker files.

I just tried fork repo and replaced yaml with the content I provided and the system accepted it. Yeah, maybe it is because it was resaved without BOM.

Thanks for trying to help!

It was definitely the BOM. It’s tough to diagnose crowdin issues because you get no logs or useful messages in the UI.