GitHub Connector

GitHub Connector FAQs

Why does Smartling require the user to be an Admin instead of just Read/Write access? And can I change the user's permissions after the installation?

A Smartling user needs to be an Admin because we require the "Change a repository's settings" permission in order to add and remove our webhooks. Starting and stopping the GitHub Connector in Smartling will install and uninstall the webhooks, therefore, changing permissions after the GitHub Connector is installed will result in errors and unexpected behavior from the GitHub Connector. Users should keep their Admin level permissions.

Each time you add a new Admin to your Github, you will need to create a new configuration set in Smartling for that user's repo.

Furthermore, any configuration set created uses OAuth and therefore the account you are logged into in GitHub is the user account the connector uses to authenticate the configuration set. If your developer creates configuration sets, they must be logged into GitHub as an Admin user and not any other user role they may use in GitHub. Overlooking this may result in multiple configuration sets relying on the permissions from multiple different accounts from the various people who created them.

When setting up the GitHub GitHub Connector in Pull Request Mode, which branch should I select?

For most users, the main (master) branch can be used. However, to avoid any localization issues corrupting the main (master) branch, it is worth considering creating another branch, such as a dev branch, for translations to be returned from Smartling to before the main (master) branch. If you already have a process where localization happens in a different long-lived branch, you can select that branch instead.

How do I add a new language?

For options on how to add a new language to the GitHub Connector, click here.

Can I map custom locale codes to my configuration?
Yes. Click here to read how.

Why are some strings being duplicated in Smartling?

Smartling will generally avoid repetitions and duplications, especially when a file is simply being updated/revised. In some cases, repetitions or duplicates are created by design. For example, if a string exists with a different key, or in a different file, it is captured as a separate, unique string. This is important because when used in a different context, the translation might be different. For more detail on how this works, see string uniqueness and SmartMatch, as well as how to optimize the translation process when you have repetitions.

For more information, read our Strings article.

Do I have to wait for all translations to be completed? (Pull Request Mode)

As a best practice, we recommend that your resource files get fully translated in all of your project’s languages. However, if you need to unblock the original pull request or just get the latest translations, there are a few options that all have different pros and cons.

  • Option 1: Keep the translation process going (keep the pull request blocked), including the dependent branches, active, but get the latest translations to use. Using either the Smartling Dashboard or APIs (via the CLI tool or other methods), download the translated files for the languages you want (optionally downloading pending translations for any language) and then deploy them as needed.
  • Option 2: Unblock the pull request by merging just the languages that are completed. Using the Smartling Dashboard UI, update the job for the corresponding branch by removing the languages that you do not want to wait for. When all languages that remain in the job are completed, the job will automatically update to be "Completed", and trigger the standard flow for the GitHub Connector. In this case, only the languages remaining in the job will be in the resulting pull request. Note: Removing the language from the job will unauthorize the translations of the strings that are not yet published, losing any translation work that has already been done.
  • Option 3: Unblock the pull request completely, without any translations merged.
  • Option 4: Depending on your GitHub configuration, you can disregard the flag and proceed with the merge, or if it is configured to block pull requests from the merge, it can be overridden by an admin.
  • Option 5: Completely cancel the job in Smartling.

Can I connect to a self-hosted GitHub instance (GitHub Enterprise)?

No. However, if your GitHub Enterprise is hosted on, this is compatible with the GitHub Connector. For alternative options, consult the Options for Automation With Source Repositories article.

Can I change the branch that the GitHub Connector monitors for pull requests? (Pull Request Mode)

No. If you'd like to configure the GitHub Connector to monitor a different branch, you'll need to create a new Smartling GitHub GitHub Connector project. During the project wizard, you can choose the repository and branch.

If you want to change the branch, and need help migrating from one project to a new one, contact

Why are translations not being delivered using the translation path that is in my current configuration?

The configuration information present at the moment a file is uploaded to Smartling from a pull request or commit is persisted with that version of the file and used for its delivery.  Changes to the configuration will be in effect only for new pull requests or commits and files uploaded after the configurations is saved.

How can I update translations?

Translations should always be updated in Smartling. Find out what options there are available here.

If you need to make an update to translations and have them delivered back to GitHub, content must move back in the Smartling workflow to a step before published, meaning, back to and In Progress state.

Was this article helpful?