1. Why does Smartling require the user to be a Repo 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 on the repository and a member of the GitHub Organization. This is because we require the "Change a repository's settings" permissions 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.
Each time you add a new member 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 a member and Admin in the Repo. Overlooking this may result in multiple configuration sets relying on the permissions from multiple different accounts from the various people who created them.
2. When setting up the 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.
3. How do I add a new language?
For options on how to add a new language to the GitHub Connector, read Setting up your GitHub Connector.
4. Can I map custom locale codes to my configuration?
Yes. For more information, read Setting up your GitHub Connector.
5. 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 intentionally. 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 documentation on Strings.
6. 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.
7. Can I connect to a self-hosted GitHub instance (GitHub Enterprise)?
No. However, if your GitHub Enterprise is hosted on github.com, this is compatible with the GitHub Connector. For alternative options, consult our documentation on Options for Automation With Source Repositories.
8. Can I change the branch that the GitHub Connector monitors for pull requests? (Pull Request Mode)
Yes, you can create multiple configuration sets within the same project to target different repositories and/or branches. We recommend creating a new configuration set in the same project and completing the jobs associated to the obsolete configuration set before stopping the one you no longer require.
9. 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.
10. 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.
If a completed Job goes back into progress before the translations are merged and the initial PR is merged then the connector can/will update just files that have been changed. This is seen only when the Job is re-completed. In this case, you will see a single file with multiple commits.
If the translation PR with multiple languages has already been merged and then the job is re-opened and only one or some languages worked on, for example:
Then, you may see that only the files have changed are delivered in a new translation PR.
11. Does prepublished translations republished once the content moves to the published step?
No. Only published content is picked up by the Connector and delivered back to GitHub, once the entire Job is complete.
12. I want to use Git rebase to merge feature branches. What mode should I configure my GitHub Connector in?
The GitHub Connector does not support rebasing when set to Pull Request Mode. It may lead to unexpected results with the PR and unexpected Connector behavior. However, as Single Branch Mode works with commits only, there are no issues with rebasing of feature branches when the Connector is set to Single Branch Mode.