From Integrations

Are you Providing Enough Support to your Customers?

The holiday season is upon us, which got us to thinking… The holidays are supposed to be a joyous time, but for many shoppers, the holidays can be a frustrating experience filled with traffic jams, crowded stores, and long lines at checkout. To make matters worse, Salesforce sponsored a study that found that holiday expectations have grown so low among Americans, 42% expect customer service to plummet over the holidays, too.

Knowing that nearly half of shoppers expect poor customer service, we thought we’d offer insights into the customer service process – like how to define your customer service strategy and how to improve it – not just for the holiday season, but for all 365 days of the year. At the end of the day, it’s about making your customers happy, right?

Defining your customer service strategy

One of the biggest customer support mistakes is not including your customer service strategy in your go-to-market plan. Companies of all sizes, from early-stage startups to multi-million dollar enterprises, find themselves guilty of waiting until support tickets and emails come pouring in before creating a dedicated action plan. If you don’t have a customer service strategy in place, start by:

  1. Making sure your strategy revolves around your core principles and values
  2. Figuring out the type of experience you want customers to have
  3. Determining how to best communicate brand through support interactions

Defining a strategy specific to your company can help you create one that is helpful to customers, while still being a great fit for your company and support team.

Creating an awesome support team

With any strategy, you need the right people to carry it out, meaning you have to hire smart. When companies hire for most positions, they look at experience, skills, and qualifications. Conversely, with a customer service position, you need to look for people with that “special something.” You can’t teach someone how to care about customers; that’s a trait that’s often intrinsic to the person. Seek individuals who believe helping others is rewarding, and you’ll often be rewarded with an exceptional support team that goes above and beyond their job description.

This leads us to the next logical question. How will a customer service team go above and beyond? Great customer service teams don’t just help customers in the proverbial “red,” but strive to support customers that are already happy. These customers are your company’s evangelists and oftentimes your biggest supporters, so it’s important not to forget about them. Shift the way you think about customer service, and try to make all your customers happy, whether they asked for help or not.

Debunking customer service misconceptions

Now that we’ve outlined how to create a great foundation for how to serve your customers, we’ve got to tackle common customer service misconceptions.

  1. Customer support is a cost center. Many companies look at their support centers as a cost; a place where employees are paid to help customers, often reversing costly mistakes or offering a discount to make up for an error – whether it’s the company’s fault or not. The companies that are most successful, however, flip this concept and view support as a revenue center. Companies that embrace the concept that each support ticket should be an opportunity to create a great experience (not just mitigate bad experiences) often succeed and become trusted brands among their community and customers.
  2. Customer service must be done in-person. Yes, historically, customer service is an in-person interaction between a store representative and a client. However, in today’s technology-driven society, customer service experiences have moved online. Aaron Franklin, Product Manager at Pinterest, shared that “In many cases, users are now getting help instantly with experiences that exceed those offered by human beings.” Providing a way for customers to serve themselves online with a comprehensive help desk allows users to find the answers they need, when they need them, which ultimately means satisfied customers.

How you can improve your customer service?

Whether you’re just starting your business or you’re an industry veteran, there’s always room for improvement when it comes to how you serve your customers. Check out these tips for how to create an even better experience for anyone who’s interested in your product.

Make data your best friend

Todd Park, formerly the second Chief Technology Officer of the United States, said, “Data by itself is useless. Data is only useful if you apply it.” And while this seems like a basic concept, it’s one that’s overlooked far too often.

Examining data, like website visits and how customers interact with your website, can help you understand where you need to make product and service changes. For instance, maybe one of your website’s pages has an extremely high bounce rate, indicating customers aren’t finding the answers they need. Knowing this, you can make changes to this specific page, maybe adding clarity, and then can train your staff to respond to these changes. By spending time with your data, you might be able to find a new service opportunity that you never would have thought of.

Stick to your word

As a customer, there’s nothing more disappointing than seeing a “live chat” option, and then not being able to chat with someone. It’s understandable that not all companies, especially those with limited budgets, can provide 24/7 support. But don’t tell customers you’re going to provide immediate assistance, and then ask them to leave a message. If you tell your customers you’re going to be there for them, be there. A simple workaround? State the hours that live chat is available or ask customers to leave a message and tell them you’ll be in contact within the next twenty-four hours. Sticking to your word is the first step in gaining customer trust.

Help customers help themselves

Zendesk, a customer service software and support ticket system, is a huge advocate of the “customer self-serve” model. The concept behind this model is to provide customers with all the resources they need to help themselves to the simple and frequently asked questions, which includes:

  1. Building a better FAQ. Your FAQ is the perfect place to implement the self-serve concept. Create an easy-to-navigate and robust FAQ, including step-by-step instructions, graphics, and videos, and provide customers with a way to find out more information about your product or service. Also be sure to think of your FAQ as a living, breathing document that requires regular updating. When a customer asks a great question that doesn’t come up often, add it to the FAQ!
  2. Make your website searchable. Adding a search bar to your website is an easy way to give customers a channel to find answers to their own questions. You can even think about adding an auto-populate feature where frequently typed queries pop up as the user starts typing, providing even more convenience.
  3. Create a separate social media presence. Many people turn to social media to ask other customers questions or to speak directly to the company. Creating a strong presence on various social media channels (Facebook, Twitter, and LinkedIn) gives your customers another way to reach you. While these channels can only be successful if monitored regularly (they can have the opposite effect if inquiries go unanswered), when done correctly, they give your company a voice and show your community that your company cares and is working to provide the best possible experience for users.

Support ALL your customers

76% of consumers say they view customer service as the true test of how much a company values them. So for companies who serve a global audience, it’s extremely important to provide customer service and support in that customer’s native language. Localizing your Zendesk help center is one of the best ways to do this, and with help from Transifex, it’s as simple as linking up your existing help center with our platform.

For more information about translating and localizing your help center, don’t hesitate to reach out to Transifex. We offer personalized demos, so schedule a time to chat and see how we can help you support customers all over the world!

Support Documentation: Job #1 for Localization?

You’re a software or mobile app provider and you’re thinking about developing localized content to enter international markets for the first time. That’s great! But which pieces of content do you start with? Oftentimes, the task of translating support documentation seems like it would be far down the priority list, well behind translating your marketing website or product interface. The thing is, that prioritization could be totally wrong. Localizing your support materials might be the most important information to translate as a first step to cement your global growth.

Does this seem counterintuitive? Let’s look at some data and examples to understand why this just might make sense for your business.

The Case for Making Support Documentation Top Priority for Localization

First, let me share an anecdote I heard recently at a localization conference I attended. Another attendee from a large, well-known software provider* shared her company’s experience with the decision process for initiating localization projects. (*I was not able to make personal contact with this attendee, nor did she provide blanket permission to share her story officially, so I am omitting the company identification, but trust me, you’ve heard of them.)

Her company had not localized the user interface to one of its key products, only offering it in English. A few years ago, when the company started thinking about whether to localize the product and for what markets, they dug into the details around their users’ experience, and they realized they already had a large base of international users. Their product was powerful enough and their interface simple enough that many non-English speakers were adopting it despite its lack of a locale-specific interface.

But that’s where the good news ended. The company also realized they had a customer support issue on their hands. Multiple international users’ forums had sprung up online to answer questions from the users who had no way to get adequate support directly from the company. That meant users were depending on the quality delivered by other users who spoke their language, rather than the official, vetted documentation from the company itself. So that’s where all the company’s localization efforts began — with customer support materials.

We see a similar prioritization in the results of our 2014 Localization Benchmark survey. Among the organizations surveyed (all of whom are at least thinking about localization) the content that rated as the second highest priority for localization was Documentation / Knowledge Bases. This prioritization is also consistent with the finding that the number one benefit of localizing is delivering a better user experience, noted by 51% of respondents.

Customer Service — A Critical Element of the Customer Experience

It’s important not to lose sight of customer service’s strategic importance to your business. According to the 2015 Global State of Multichannel Customer Service Report, 68% of US consumers stopped doing business with a brand due to poor customer service. Selling excellent products to customers at the right price through their preferred channel isn’t enough in and of itself to create a robust customer experience with your brand. How you provide customer service must be top of mind to fully satisfy customers because in today’s competitive landscape, it’s not about not meeting, but exceeding customer expectations.

This same study also reports that 90% of consumers surveyed globally expect companies to have an online self-service support portal or FAQ. So if you’re planning on delivering an exceptional online experience for customers around the world, you must have the support aspects of your business ready from the start. Providing online support through localized content is no longer an option, but a must.

Preparing for Localization Before You Begin

In much the same way that customer service design is now an integral part of the go-to-market strategy, planning for localization can no longer be an afterthought. A product development approach that anticipates localization tasks smooths the process when you are ready to go global. If you’ve already implemented a solution like the one from Zendesk that helps your U.S. customers help themselves, you can easily leverage that solution internationally via the Transifex Sync Zendesk App, easing the process of meeting customers’ high expectations in each market that you enter.

If you’re interested in seeing how the Transifex Sync Zendesk App works, schedule a personalized demo with one of our team members, and you’ll be one important step closer to achieving your global growth objectives!

Automating Transifex Updates with Jenkins

Jenkins, an Open Source continuous integration server, supports Transifex projects using a few simple shell commands. In this post, we’ll show you how to configure Jenkins to automatically synchronize with a Transifex project.

Jenkins Basics

Jenkins automates the process of running repeating tasks such as executing scripts or building software packages from source. Jenkins also monitors the status of running jobs, provides alerts, and integrates with external build services such as Maven and Ant.

Each job is assigned a workspace, which is a directory where copies of the job’s source files are stored. For instance, in Ubuntu, these directories fall under /var/lib/jenkins/workspace/. If your project is managed by source control, Jenkins will automatically pull the latest revision from your source repository. Otherwise, you’ll need to copy your source files to the job’s workspace after creating the new job in Jenkins.

Integrating Transifex

One of the benefits of Jenkins is that it can execute shell scripts during the build cycle. This makes it easy to integrate Transifex by simply calling the Transifex Client. Using tx push and tx pull, you can have Jenkins automatically update your source and translation files as the project is built.

Configuring Your Project

Before Jenkins can use the Transifex Client, it has to be able to read your project’s configuration. By default, the Transifex Client stores its configuration settings on a per-user basis. On a Linux environment, this is typically /home/<user>/.transifexrc. However, Jenkins executes commands as the Jenkins user. For instance, in Ubuntu, this means that any user-specific configuration files for Jenkins should be stored in /var/lib/jenkins/.

To configure your project for Jenkins, copy your transifexrc file to /var/lib/jenkins/.transifexrc. If you manage multiple jobs with Jenkins, you can store .transifexrc in the job’s workspace. Keep in mind that .transifexrc contains sensitive account information and shouldn’t be viewable by anyone but the Jenkins user.

You’ll also need to make sure that your project is configured to use the Transifex Client. Running tx init in your project folder will generate a .tx directory containing a configuration file. This configuration file tells the Transifex Client how to connect to your localization repository. Unlike the .transifexrc file, we recommend checking the .tx directory and config file into your source control repository. That way, when Jenkins checks out the project, it has everything it needs to connect to Transifex.

Configuring the Jenkins Job

Once you’ve granted Jenkins permission to access your Transifex project, you can configure your Jenkins job. As the job executes, Jenkins will call the Transifex client and update the project’s localization files.

Jenkins project

Navigate to the job’s configuration page. Under the “Build” section, click “Add build step”, and select “Execute shell”. A text box appears, allowing you to enter commands. Enter the following commands and click Save:

tx push -s
tx pull -a

Jenkins configuration

The next time a build occurs, Jenkins uses the Transifex Client to not only push your source files to Transifex, but also to pull the most recent translations into the build.

Modifying Downloaded Translation Files
If you need to further modify your language files before including them in the build, you can run additional commands by either adding new statements or by adding a new build step. You can perform any command-line task supported by the operating system running Jenkins, such as converting between file types or moving files to a separate directory. For instance, if you haven’t set up your project using a file expression, you’ll have to manually move your translation files into the target directory.

Handling Problems

Integrating Transifex with Jenkins is fairly straightforward, but problems can arise during the process. Two issues in particular are extremely common: file permissions, and build failures due to the Transifex Client.

File Permissions

As we mentioned earlier, the Jenkins user must have access to project files. If permissions aren’t properly assigned, this could result in opening Jenkins or your Transifex project to outside access. When copying files to a Jenkins workspace, make sure those files can only be modified by the Jenkins user. If you’re copying a .transifexrc file to the Jenkins workspace, make sure the file can only be read by the Jenkins user.

If you manage your project using version control, Jenkins will automatically fetch and store files as the Jenkins user. However, this does mean providing Jenkins with access to your source repository. Some version control systems such as Git allow you to use file permissions to prevent users from modifying checked out files. Alternatively, hosting providers such as GitHub provide advanced controls for limiting users’ ability to push to repositories.

Build Failures

Common causes of build failures are a missing .transifexrc file, or Jenkins not having the right permissions to read your project’s files. Make sure your .transifexrc file is not only stored in Jenkin’s configuration directory, but is also readable by the Jenkins user.

You should also make sure that your project configuration and source files can be read by Jenkins. If you copied your source files manually, you’ll need to grant permission to the Jenkins user to read and modify files in the project directory.

If the build continues to fail, try running the Transifex Client as the Jenkins user and viewing the immediate output. After logging into the Jenkins server, use the sudo command to temporarily switch to the Jenkins user:

$ sudo -iu jenkins cd /path/to/workspace && tx push -s

Any output from the Transifex Client will appear directly in the console. You can also view output from the Transifex Client by opening Jenkins, navigating to your project’s build history, and clicking on Console Output for the last build.

Additional Resources

Using the Transifex Client through Jenkins is the easiest way to ensure your builds are using the latest translations. You can also install the Transifex Plugin for Jenkins, which simply adds a hyperlink to the Transifex project page on the Jenkins job page.

Bridging GitHub and Transifex with Txgh

We previously showcased Txgh, a tool for automatically bridging GitHub with Transifex. Txgh is an Open Source Sinatra server that uses webhooks to trigger updates between GitHub and Transifex. It allows both developers and translators to share localization updates in an automated and seamless way. Changes to either a GitHub repository or a Transifex project are pushed to the Txgh server, which forwards them to Transifex or GitHub respectively.

Txgh has seen a lot of updates since its earlier release. Txgh can now run as a Heroku dyno for quick and easy deployment. The new release also supports branches, rather than limiting changes to master. Transifex will manage future updates to the project, but the project will remain open sourced. In this post, we’ll walk you through setting up the latest version of Txgh.

Getting Started with Txgh

Txgh requires an existing Heroku account. If you don’t already have one, you can sign up for a free account here. Txgh requires Ruby and Bundler, which you can install using this guide. Note that the Txgh project uses Ruby version 2.0.0, which we recommend installing using a version manager.

Download Txgh

To download Txgh, simply clone the latest version from GitHub:

$ git clone
Cloning into 'txgh'...
remote: Counting objects: 162, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 162 (delta 0), reused 0 (delta 0), pack-reused 159
Receiving objects: 100% (162/162), 34.75 KiB | 0 bytes/s, done.
Resolving deltas: 100% (68/68), done.
Checking connectivity... done.

Configure Txgh

Txgh needs access to a GitHub account, a Transifex account, and information about the Transifex project being managed. Earlier versions of Txgh used a YAML file to store user credentials. With the latest version of Txgh, this information is stored as environment variables in Heroku. We’ll add these environment variables after deploying the server to Heroku.

In the meantime, we can provide Txgh with our Transifex project’s configuration. Copy the config file stored in your project’s .tx directory to Txgh’s config directory and rename it to tx.config. You should see three files in the directory: key_manager.rb, key_manager_ruby.rb, and tx.config. For more information on setting up your project configuration, click here.

Deploying to Heroku

Heroku provides a command-line tool for interacting with applications. When you create a new application, Heroku creates a remote Git repository (with a branch named heroku), which you can then push your code to. Change your current directory to the Txgh project’s root directory and enter the following command:

$ heroku create
Creating nameless-eyrie-4025... done, stack is cedar-14 |
Git remote heroku added

By default, Heroku provides a randomly generated name, but you can supply one as a parameter. Once the new application has been created, you can deploy your app by using git:

$ git push heroku master
Counting objects: 156, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (71/71), done.
Writing objects: 100% (156/156), 33.84 KiB | 0 bytes/s, done.
Total 156 (delta 65), reused 155 (delta 65)
remote: Compressing source files... done.
remote: Building source:
remote: -----> Ruby app detected
remote: -----> Compiling Ruby/Rack
remote: -----> Using Ruby version: ruby-2.0.0
remote: -----> Installing dependencies using bundler 1.9.7
remote: -----> Compressing... done, 18.3MB
remote: -----> Launching... done, v4
remote: deployed to Heroku
remote: Verifying deploy.... done.
 * [new branch]      master -> master

You can verify the success of the deployment by opening the Heroku dashboard in your web browser and navigating to the newly created dyno:

Heroku dyno

Updating the Configuration

Before you can start pushing updates between GitHub and Transifex, you’ll need to provide the Heroku app with information on how to access each service. Txgh uses a set of environment variables to manage connections between each service. The name and description of these variables is shown in the table below:

transifex_project_config_tx_configLocation of your Transifex project's configuration file relative to Txgh's root folder../config/tx.config
transifex_project_config_api_usernameYour Transifex username.txuser
transifex_project_config_api_passwordPassword to your Transifex account.1324578
transifex_project_config_push_translations_toName of the GitHub repository that Txgh will push updates to.ghuser/my_repository
transifex_project_config_push_translations_to_branchGitHub branch to update.heads/master
github_repo_config_api_usernameYour GitHub username.ghuser
github_repo_config_api_tokenA personal API token created in GitHub.489394e58d99095d9c6aafb49f0e2b1e
github_repo_config_push_source_toName of the Transifex project that Txgh will push updates to.my_project

There are two ways to apply these to your Heroku app:

  1. Add the environment variables through Heroku’s web interface.
  2. Create a local file containing your environment variables and apply it using rake.

Add Environment Variables Through the Heroku Dashboard
Open the Heroku dashboard in your web browser. Click on the Settings tab and scroll down to the Config Variables section. Click Reveal Config Vars, then click Edit. You’ll have access to the application’s existing variables, but more importantly you can add new variables as shown in the screenshot below. Add the variables listed above and click Save.

Config vars

Note that the RACK_ENV variable defaults to production, but in order for it to work with Txgh we need to set it to test.

Add Environment Variables Using txgh_config.rb
The txgh_config.rb file stores our environment variables inside of the Txgh folder. To create the file, copy and paste the following into a new text file. Replace the placeholder values with your actual values and save the file in the config directory as txgh_config.rb.

# 'test' only ENV['RACK_ENV']
config_env :test do
    set 'transifex_project_config_tx_config', './config/tx.config'
    set 'transifex_project_config_api_username', 
    set 'transifex_project_config_api_password', 
    set 'transifex_project_config_push_translations_to', 
    set 'transifex_project_config_push_translations_to_branch', 'heads/master'
    set 'github_repo_config_api_username', 
    set 'github_repo_config_api_token', 
    set 'github_repo_config_push_source_to', 

To apply the changes to your Heroku dyno, use the rake command:

$ rake config_env:heroku
Running echo $RACK_ENV on nameless-eyrie-4025... up, run.2376
Configure Heroku according to config_env[test]

=== nameless-eyrie-4025 Config Vars
LANG:                                          en_US.UTF-8
RACK_ENV:                                      test
github_repo_config_api_token:                  489394e58d99095d9c6aafb49f0e2b1e
github_repo_config_api_username:               ghuser
github_repo_config_push_source_to:             nodejs-test
transifex_project_config_api_password:         12345678
transifex_project_config_api_username:         txuser
transifex_project_config_push_translations_to: ghuser/nodejs-test
transifex_project_config_tx_config:            ./config/tx.config

This command updates the configuration of your Heroku app with the values specified in txgh_config.rb. If you have any issues running the rake command, run bundle install in the Txgh project’s root directory. This compiles and installs the Ruby gems required by Txgh. Once the install completes, run the rake command again.

Since this file contains sensitive information, you should avoid committing it to your Heroku repository or to your GitHub repository.

Once the rake command has completed successfully, open the Heroku dashboard, navigate to the application’s settings and click Reveal Config Vars.

Final Configuration Steps
The last step is to change the value of the RACK_ENV variable. By default, Heroku sets the value of RACK_ENV to production. However, we recommend testing Txgh by setting this value to test. If you haven’t already, open your application’s environment variables in a web browser and change the value of RACK_ENV from production to test. When you’re ready to deploy, you can change this value back to production.


Meanwhile, check the values of your other variables. If any values seem incorrect, you can edit them in your browser or edit and re-apply the txgh_config.rb file using rake. Once everything looks good, you can add your webhooks to Transifex and GitHub.

Connecting Transifex and GitHub to Txgh

Txgh synchronizes your Transifex and GitHub projects using webhooks, allowing Txgh to respond immediately to changes in either service. The webhook URLs follow the format, where is the name of your deployed Heroku app and is either “transifex” or “github.” For instance, we’ll use the following URL with Transifex:

and the following URL with GitHub:

Connecting Your Transifex Project
Open your project in Transifex. Under More Project Options, click Manage.

Transifex manage

In the Features section at the bottom of the screen is a text box titled Web Hook URL. Enter in the URL you created from your Heroku app, then click Save Project. Secret keys are currently unsupported, so leave the field blank for now.

Transifex webhook

Connecting Your GitHub Repository
Connecting a GitHub repository is similar. Open your repository in a web browser and click Settings.

GitHub repository

Under Webhooks & services, click to add a webhook. You may be asked to confirm your password. Enter the Heroku app URL for the Payload URL and change the Content type to application/x-www-form-urlencoded. Just like with Transifex, keep the Secret token field blank.

GitHub add webhook

Click Add webhook to create your new webhook. GitHub will ping the URL to test its validity. You can check whether the ping was successful by reloading the page.

Next, we’ll test out the integration by moving translations between GitHub and Transifex.

Testing It Out

To test the integration, we’ll push a new commit to GitHub, then we’ll use the new commit to update translations in Transifex.

First, add a new string to the language source file in your Transifex project. Save your changes, then push the code to your GitHub repository. The push will automatically trigger the webhook. You can verify that webhook was successful by opening GitHub in a browser, navigating to the Webhooks & services, clicking on the webhook URL, and reviewing Recent Deliveries.

Recent deliveries

If successful, you should see the new source strings in your Transifex project:

Transifex new strings

Update the translations in Transifex. Back in your GitHub repository, review the latest commits. You should see a commit from Transifex with the latest updates to the target language:

GitHub results

Going Forward

This project represents an early look into automated integration with GitHub. Going forward, we plan on making it easier to setup automated integration with code repositories and other third-party services. If you have any questions, feel free to contact a Transifex team member for a personalized demo or leave a comment below.

Integrating Transifex with Bamboo (Part 2)

Earlier this week, we shared a post about integrating Transifex with Bitbucket. In addition to Bitbucket, Atlassian offers a continuous integration server called Bamboo. Bamboo lets you automatically setup, build, and deploy projects. Integrating Transifex with Bamboo lets you update your project’s localization files in an automatic and seamless way.

The Bamboo workflow is split into five components:

  • Tasks are the individual work units in a Bamboo project. A task is any discrete action such as checking out a project from source, executing a script, or, in our case, calling an external program such as the Transifex Client.
  • Jobs are used to control multiple tasks. They specify task execution order, enforce requirements, and collect artifacts created by tasks.
  • Stages represent steps within a build process. As an example, you might use three separate stages for compiling, testing, and deploying code.
  • Plans organize work units, builds, and tests. They also allow you to link to code repositories, generate notifications, configure permissions, and specify variables.
  • Projects organize multiple plans under a single logical unit.

For more information on Bamboo’s structure, click here to go to the Atlassian documentation site.

Installing Bamboo

Bamboo can be installed on a server or hosted on a cloud instance. This article assumes Bamboo is being installed on a server.

Navigate to Bamboo’s download page and download the executable for your server operating system. From there, navigate to Atlassian’s documentation site to find more information on installing Bamboo for your particular OS. When the installation is finished, access Bamboo by opening a web browser and navigating to http://<server IP address>:8085. You may need to open the port in your server’s firewall.

Bamboo requires a valid license before it can start. If you haven’t already, generate a trial license by logging into your Atlassian account and requesting an evaluation license. After Bamboo verifies the license, it will ask you to create a new administrator account for the Bamboo agent. Once the account setup is complete, you’ll be greeted by the Bamboo home screen.

Creating a New Project

To create a new project, click the Create button at the top of the screen, then click “Create a new plan.” This brings you to the plan configuration screen where you can enter details about the new project. We’ll create a new project for our Node.js app:

Make New Project in Bamboo


Click “Configure plan” to create the new project. Along with the new project and plan, Bamboo creates a default stage and a default job. Since we specified a Bitbucket repository, Bamboo automatically creates a task to retrieve the source code from the repository. Next, we’ll add tasks that synchronize the source code with Transifex using the Transifex Client.

Adding a Task Command to Bamboo

To run the Transifex client during the build process, we need to add a new task to our default job. Bamboo supports a variety of tasks for generating logs, deploying to cloud services, or even executing Maven or Ant tasks. In this case, we’ll use the Command task to run a command that calls the Transifex Client.

Before we do this, we need to register the Transifex Client as an executable. Navigate to the Bamboo administration page by clicking the gear icon in the top-right corner of the screen, then click “Overview”. Under the “Build Resources” section on the left-hand navigation menu, click “Server capabilities.” This will show you the actions available to the Bamboo server, including the executables available to your build plan.

Scroll down until you see the “Add capability” section. Under “Capability type,” select “Executable,” then select “Command” for the type. Enter an identifier for the command, followed by the path to the executable that you want to run (in Ubuntu Linux, the Transifex Client executable is found at /usr/local/bin/tx). Click the “Add” button to register the new executable with Bamboo:

Adding Transifex Client to Bamboo

Navigate back to your project by clicking “Build” at the top of the screen, then “All build plans.” Edit the project by clicking the pencil icon on the right-hand side of the screen, across from the project name. Under “Plan Configuration”, click on the default job. Switch to the “Tasks” tab, then click the “Add task” button. Bamboo prompts you for the type of task to add:

Add a New Task

Click the “Command” task and select the “Transifex Client” executable we defined earlier. In this task, we’ll push the latest source files to Transifex. Under arguments, type “push -s.” Add a small description, then click Save. Repeat this process to create a new command that pulls the latest translations from transifex using the command tx pull -a.

Note that you may need to specify the “Working Sub Directory” field before the command will successfully execute. The working sub directory tells Bamboo to run the command in a folder relative to the project’s root folder. If your Transifex configuration is stored somewhere other than in the project’s root directory, you’ll need to specify the directory here. The best way to determine this is to run the Transifex Client in your project, note which subfolder you ran the command in, then enter that subfolder as the working sub directory.

How to Create a New Command

Next, we’ll run the plan and generate a new build.

Run the Plan

To generate a new build, click the “Run” button in the top-right corner of the screen. Your build will begin in the background, and the results will be displayed in the Build Dashboard.

Build Dashboard on Bamboo

Click into the build to see the results. If it was successful, you should be able to see output from the Transifex Client in the Logs tab.

Client Output in Tx

You can use this same process to integrate Transifex into an existing Bamboo project. Once the Transifex Client is registered as an executable, add two tasks to your project that call the tx push and tx pull commands. Make sure you do this earlier enough in your build process so that you can reliably test and package the localization files with the rest of your project.

For more information on integrating Transifex into your projects, visit the Integrate Transifex documentation page.

Integrating Transifex and Bitbucket (Part 1)

Bitbucket is a service that lets you host and share code with other users. Bitbucket supports version control using Git and Mercurial. In this post, we’ll show you how to synchronize changes between your projects hosted in Bitbucket and your localization projects in Transifex. We’ll also post a blog on how to integrate Transifex with Bamboo, a popular continuous integration service, so don’t forget to check out our blog later this week!

What is Version Control?

If you’re unfamiliar with version control, we recommend reading our previous post on version controlled translations with Git. Version control systems (VCS) track changes to files across multiple users. Most version control systems are based around three core concepts:

  • Repositories, or directories that hold code files.
  • Commits, or changes to source code that are applied to a repository.
  • Branches, or deviations in the code base.

Version control helps developers coordinate code changes while reducing the chances of conflicts or data loss. While there are multiple version control systems available, the examples in this article use Git simply due to its popularity.

Getting Started with Bitbucket

To start, we’ll create a new repository in Bitbucket via the web UI. After logging into your account (new accounts are free), click on the “Create” dropdown button, then click “Create Repository.”

Enter the details of your repository. You can modify the visibility settings of your project and allow other users to “fork” your project, which lets them create and work on a copy of your repository. You can also add bug tracking, add a Wiki, or select a base language for the codebase. When you’re ready, click “Create repository.”

How To Make New Repository in BitBucket

By default, your new repository will be empty. You can use a version control system to push project files to Bitbucket, or you can import an existing repository from another code hosting service. In this example, we’ll use an existing Git repository for a NodeJS project stored locally on a Linux desktop. We’ll change the working directory to the project folder, use git remote add to add the remote repository, then push our project to the remote repository.

$ cd /home/transifex/projects/i18n
$ git remote add origin
$ git push -u origin --all

Once the command completes, you should be able to browse your Git repository through the Bitbucket website.

Syncing Changes with Bitbucket

As you make changes to your local code files, you’ll need to update the Bitbucket repository. Imagine we have a file named “i18n.js,” which contains a list of all the locales used in the project. We decide to change a locale, so we update i18n.js. With Git, you can view changes between the repository’s current state and the last commit using the command git status:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

	modified:   i18n.js

no changes added to commit (use "git add" and/or "git commit -a")

Git uses a staging area to temporarily store files before committing them, allowing you to customize a commit by including or excluding certain changes. We’ll add i18n.js to the staging area, then create a new commit:

$ git add i18n.js
$ git commit -m "Added new locale: es_ES"
[master 6a9f8d5] Added new locale es_ES
 1 file changed, 1 insertion(+), 1 deletion(-)

To update the Bitbucket repository, use the git push command. origin specifies the name of the remote destination, while master specifies the name of the local branch being pushed. You may be prompted for your Bitbucket account password:

$ git push origin master
Password for '': 
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
   45cff79..6a9f8d5  master -> master

If you need to pull changes from a remote repository into a local repository, for instance, to incorporate changes from another developer, use the git pull command:

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
   6a9f8d5..776aa6d  master     -> origin/master
Updating 6a9f8d5..776aa6d
 i18n-node-http.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

You can use git log to review the latest changes:

$ git log
commit 776aa6d5375037f009f4d4dc8acbe06bd228c214
Author: Other Developer 
Date:   Mon Aug 24 16:41:40 2015 -0400

    Changed default locale to es_ES

commit 6a9f8d57dab0db5fb50d4be1b863307bd10c9c0c
Author: bitbucket
Date:   Mon Aug 24 16:25:08 2015 -0400

    Added new locale es_ES

Syncing with the Transifex Client

You can use the Transifex Client to push source changes to Transifex. The benefit to this approach is that it ensures everyone has access the latest translations. However, it could potentially make it more difficult to control who updates the latest translations and when. Features that are still in development can change entirely, and having your localizers work on text that might not appear in the final product would be a waste of time and money. Developers will also need to remember to update localization files when committing their code changes. Enforcing a push policy ensures everyone knows exactly when to sync their changes to the Transifex project.

To update your Transifex project from a local Git repository, make sure your repository is up to date with the remote Bitbucket repository by using git pull. Install the Transifex Client if it’s not already installed. The Transifex Client is based off of the Git client and uses a similar command structure. For instance, use the tx init command inside of your project’s root folder to create a new Transifex configuration:

$ tx init
Creating .tx folder...
Transifex instance []: 
Creating skeleton...
Creating config file...

You should now have a .tx folder inside of your project. Inside of this folder is a configuration file, which contains the information used to identify the project on a Transifex server. For instance, this Node.js app has the project name “i18n” and stores its localization resources in the “locales” directory as standard JSON files.

host =

file_filter = locales/.json
source_file = locales/en.json
source_lang = en

You can add the .tx folder to your Git repository by using git add. When other developers pull your changes, they can use the same configuration file to connect their Transifex clients to the Transifex project.

When you’re ready to push your updated files to Transifex, use the tx push command. The -s flag pushes source files, while the -t flag pushes translation files:

$ tx push -st
Pushing translations for resource i18n.enjson:
Pushing source file (locales/en.json)
Pushing 'de' translations (file: locales/de.json)
Pushing 'es' translations (file: locales/es.json)

To pull changes into your local project folder, use tx pull:

$ tx pull -a
New translations found for the following languages: de, es
Pulling new translations for resource i18n.enjson (source: locales/en.json)
 -> de: locales/de.json
 -> es: locales/es.json

From here, simply stage, commit, then push the updated localization files to your Bitbucket repository.

Again, don’t forget to check in for part 2 of this post, Integrating Transifex with Bamboo! And until then, check out the Transifex localization website for more information about localizing digital content!

Using Transifex with Google Drive

Combining Transifex with Google Drive gives you the ability to edit and share your project files with your entire team. In addition to managing your project with the Transifex client, you can use our auto-update function to update resource files without the need for a third-party service.

Using the Auto-Update Function

Transifex offers an auto-update function that periodically scans a remote file and updates your resources based on changes to that file. The only requirement is that the remote file has to be publicly accessible. To do this, we’ll use a feature in Google Drive designed for hosting static web pages. We’ll then create a URL that Transifex can use to access our resource files.

Start by opening your project in Google Drive. Navigate to your project folder, right-click your resource file, and click “Share”. The Share Settings popup window appears: by default, the file is limited to specific users. We need to make the file publicly available so that Transifex can access it. Note that this has the side effect of making your resource file available to anyone on the public Internet.

Click “Get shareable link” at the top-right corner of the window to show the link sharing dropdown. Click “More” under the dropdown, select “Public on the web”, then click “Save.” Your share settings should look similar to the following screenshot:

Google Drive share popup

Using Google Drive’s Host Feature

After clicking Save, Google Drive gives you a link to the file. Accessing the file through this link will open a file preview, which prevents Transifex from correctly parsing the file’s contents. Instead, we’ll use Google Drive’s host feature to access the file’s contents exactly as they are.

A regular Google Drive link looks similar to the one below. The file ID is a unique string of alphanumeric characters that identifies the file:[file ID]/view?usp=sharing

Copy the file ID into the following URL:[file ID]

Test the link by opening the URL in a browser. If you can see the contents of the file, then the link works.

Supplying the URL to Transifex

In Transifex, navigate to your project’s resource list and click “Auto update resources.”

Transifex resources

A new dialog box appears. Enter your newly-created URL and click “Update URL.” If Transifex can successfully access the URL, then the URL turns green.

Auto-update source files

Back in Google Drive, update your source file and save the changes. There’s a small delay Transifex polls the URL for changes once a day, so the updates won’t appear immediately. You can disable the auto-update function by removing the resource’s URL.

Handling Changes

When the auto-update function detects changes, it performs one of three actions:

  1. New strings are added to the project as expected.
  2. Modified strings are added to the project as new strings. The old string and its translations are kept in the project’s Translation Memory.
  3. Missing strings are removed from the resource. The string and its translations are kept in the project’s Translation Memory.

Using the Transifex Client

If you choose not to use the auto-update function, you can manually sync your resource files using the Transifex Client. While it’s less automated, the benefit is that you have control over when the Transifex project is updated. You can use Google Drive to share your project with other users, including the project’s configuration files. This way, another user can run the Transifex Client in the project folder without having to first configure the project. Just be careful not to store your .transifexrc file with the project, as it contains your account credentials.

Google Drive share

For more information, read our FAQ on updating source files.

Using Transifex with Dropbox

Dropbox is shaking up the way many businesses share files. The ability to instantly update files across multiple users and devices makes it easy for companies to stay in sync. With Transifex, you can easily update localization files stored in your Dropbox account.

Using the Auto-Update Function

Transifex provides an auto-update function that modifies your project’s source file based on a contents of a URL. Transifex periodically checks the URL and adds or removes strings based on the contents of the file. This file can be hosted anywhere – Dropbox, GitHub, or even a simple web server – as long as it’s publicly accessible.

To use the auto-update function, you’ll need to create a public URL for your Dropbox file. Using either the Dropbox desktop app or website, right-click your source file and click “Share.” Dropbox will automatically generate a public link to the file, which you’ll provide to Transifex.

In Transifex, navigate to your project’s resource list and click “Auto update resources.”

Transifex resources

A new dialog box appears. Enter the URL generated by Dropbox and click “Update URL.” If Transifex can successfully reach the URL, the URL turns green.

Auto-update source files

Over in Dropbox, update your source file and save the changes. Transifex polls the URL for changes once a day, so the updates won’t appear immediately. You can disable the auto-update function by removing the resource’s URL.

Handling Changes

When the auto-update function detects changes, it performs one of three actions:

  1. New strings are added to the project as expected.
  2. Modified strings are added to the project as new strings. The old string and its translations are kept in the project’s Translation Memory.
  3. Missing strings are removed from the resource. The string and its translations are kept in the project’s Translation Memory.

Handling Syntax Errors

In some cases, Transifex will experience a syntax error when trying to parse text files. This is due to Dropbox’s preview feature, as shown in this screenshot:

Dropbox preview

To ensure Transifex receives a plain text copy of the file, append “?raw=1” to the end of the URL (if the URL already contains a parameter, such as “?dl=0”, use “&raw=1” instead). For example:


Dropbox raw

Using the Transifex Client

If you need a faster approach, you can use the Transifex Client. While it’s less automated than providing a URL, the benefit is that you have control over when the Transifex project is updated. By storing your project configuration with your project files, you can easily share your project with others as shown in the screenshot below. Just be careful not to store your .transifexrc file with the project, as it contains your account credentials.

Dropbox share

For more information, read our FAQ on updating source files.

Translate your Zendesk Knowledge Base with Transifex Sync

Knowledge bases help your customers get answers to questions instantly. It’s key to customer success. To make translating your Zendesk knowledge base easier, we’ve built the Transifex Sync Zendesk app.

Transifex Sync Zendesk translation app

Transifex Sync automatically detects all the articles, sections, and categories in your Zendesk Help Center. With a click, you can upload the content to Transifex and translate it like you would any other content in Transifex. When the translations are done, just download them into Zendesk using Transifex Sync and you’re ready to provide answers to users worldwide. Easy!

Learn more about Transifex Sync, or check it out in the Zendesk Marketplace.

Translate your Help Scout Docs with Transifex

Help Scout is a popular help desk software with a built-in a knowledge base solution called Docs. If you use Docs, you can now translate it with Transifex Live. Not only can you provide great email support, but you can offer answers to your users 24/7 in their native language too.

Multilingual Help Scout Docs

Translating your Help Scout Docs with Transifex Live is simple. Just add the Transifex Live JavaScript snippet in your site’s settings, save the articles, translate, and publish. Best of all, when you use Transifex Live, you only need to set up one knowledge base to offer it in multiple languages.

Check out our sample Help Scout knowledge base that was translated with Transifex Live, or get started by following the instructions in the documentation.

P.S. If you haven’t heard, we’ve also built a Transifex Live-based WordPress plugin for translating your WordPress site.