The dashboard is an important part of the Transifex experience, showing you key metrics about your projects’ progress and activity. So we set out to make it more useful while simplifying navigation within Transifex.
When you visit your dashboard, you’ll see in the left navigation panel a new “All projects” tab above the list of your projects. Selecting “All projects” will show you the summary information of all the projects in your organization, including overall progress, total number of strings, number of contributors, activity, and progress by language.
To see information on a project level, simply click on a project name in the left navigation panel. Once in the project-level view, you’ll find buttons near the top right of the dashboard that link to your resources page, project details, and the translation editor. Clicking the “Project details” button will lead you back to the familiar project details page (/project/p/foo/) where you can make announcements and manage project settings.
Below the activity graph, there’s a new section showing the languages your project is being translated into. The languages are sorted by progress and include a count of untranslated strings, so you immediately know how much work is left and which languages need more attention. The up/down arrows at the top right let you cycle through the list of all your target languages.
This section has the same information you would find in your project detail page, except you won’t have to navigate back to the dashboard each time you want to see another project detail page. And when you click on a language, such as French, it takes you straight to the translation editor with that particular language pre-selected.
One more thing… the dashboard, along with the rest of Transifex, is responsive now, working beautifully across different screen sizes. We hope you like it!
P.S. Feel free to leave your thoughts about the new dashboard in the comments below.
Happy New Year and best wishes for 2014, everyone!
We hope that you all had wonderful holidays full of joy and warmth.
Our team had its yearly meetup in Paris and, among other things planned, it’s now time to welcome the new year by announcing the replacement of Releases with Categories.
A releases was a group of resources. As such, you could include the same resource in more than just one group, and whenever some translation changed, all the releases would be updated accordingly.
Categories came to take their place, keeping this functionality along with an updated behavior as they are a kind of “labels” applied to a resource. For projects with many resources, categories are like an extra level of hierarchy. By grouping certain resources, every user is able to browse the ones he is interested in.
You can organize project resources into categories via the “Edit resource” page (Project > Resources > Resource > Settings). There can be multiple categories for each resource, as shown below, that group resources according to its content, context, or whatever differentiates it from other resources.
You are able to view your resources categorized in all pages that show them and treat them accordingly. What’s more, resources can be easily filtered by to existing categories.
The categories field is also accessible via our API.
As simple as that.
More goodies are coming, stay tuned!
Four and a half years ago, Transifex was birthed as a tool to localize Fedora. Today, we’ve hit a big milestone: over 100,000 developers and translators are now collaborating on Transifex to translate more than 10,000 projects.
We’re humbled by the diversity of the projects and organizations on Transifex. They help millions of people worldwide to learn new things (Coursera, edX), work more productively (NitroPDF, Prezi), create (Arduino, CKEditor), connect with others (Disqus, Eventbrite), communicate freely (Cryptocat, Tor), unwind after a long day (VLC, XBMC), and so much more. It’s truly amazing.
We’re working hard to simplify the way you localize your websites, apps, and other digital content. Thanks for supporting us in this journey and being part of our community — it means a lot to us. Stay tuned for more exciting things to come. ;)
Official press release: http://www.prweb.com/releases/2013/12/prweb11394701.htm
While Transifex doesn’t have any Easter eggs (or does it?), there are a few lesser known features which can your simplify your localization workflow, improve translation quality, and make you a Transifex expert:
1. String Permalinks
Have you ever needed a specific string translated or reviewed? Each string in the editor has its own unique permalink, so instead of asking your translator to dig up a string, simply select the string, copy the URL, and send it to them. Easy!
This way, you’ll be sure you’re both looking at the same thing.
One thing you can do to help your translators deliver high quality content is to document how the text they are translating appears on the website. A screenshot lets translators know where strings appear in your product, removing any doubts about what the correct interpretation of “manual” is.
To add a screenshot, paste the URL of the image file as a comment in the editor (you can use services such as Dropbox, Imgur, or CloudApp to host your screenshot). Transifex will display it inline.
3. Set Character Limits for Translations
Depending on what you are translating, you may need to keep a translation within a specific character limit in order to not break the user interface. For instance, in menus, buttons, and mobile apps where space is constrained.
To set character limits for a translation, select the string in the Transifex editor, then click on “Character limit” in the middle panel (under the Instructions field). If a translation exceeds the character limit, Transifex will notify the translator and ask them to shorten their translation.
4. Pseudo Localization
A project must test its internationalization support to ensure that a) when rendering a translated language, all strings which should be translated are marked as localizable and b) different sizes and encodings of the original strings are supported.
The way to do such tests is to run the application, website, or document using a special “pseudo” file. This file makes it possible to identify issues before translations begin.
Visit Project Overview > Source Language > Resource, and click on a resource. From the resource details popup, you can download a pseudo file for that resource.
Note: You can read more about pseudo localization in our support documentation.
5. Order Translations
If you aren’t working with a vendor or crowdsourcing translations, you can order translations to 33 languages right in Transifex. Translations are provided by one of our partners and delivered back in your project.
Click “Order translations” at the top of your dashboard to start.
Know of any other not-so-obvious features in Transifex? Share them in the comments below. I’d love to hear them.
Every so often, we highlight great community translation projects on Transifex. This time around, we want to share with you four projects that help support human rights and promote inclusive access to global communications networks.
They impact the lives of many people worldwide, so chip in and lend a hand if you can!
Martus is a tool used across the globe by human rights workers, attorneys, journalists, and others to securely document human rights abuses.
Recently, Martus released an Android application to allow observers to document abuses without needing a desktop computer.
Lantern is a peer-to-peer internet censorship circumvention software to give or get access to internet in places where access is censored.
By running Lantern, every user with uncensored internet access can now become an access point for those without, providing gateways to sites like Twitter, Facebook, YouTube and others that are widely blocked.
Commotion uses mobile phones, computers, and other wireless devices to create decentralized mesh networks and connect these devices directly to each other without going through a centralized point.
Psiphon provides a suite of network software aimed at preserving security, privacy, and access to content.
All Psiphon software is open source and designed to circumvent politically-motivated Internet censorship in countries where such censorship is extra-legally enforced.
P.S. You can discover more internet freedom-related projects here.
Our friends at Strava have proven once more that great brains can come with brawn. Txgh, which they have recently open sourced under an Apache license, is a neat little Sinatra server that serves as a bridge between Transifex and Github.
It ensures you always have up-to-date translations in Github, and that the source text in your Transifex resources are kept up-to-date with the text in Github.
Here’s how I set-it up, from scratch, in a few hours.
What you’ll need:
1) A free Amazon EC2 instance. I chose the basic free Amazon Linux AMI which should be enough. It comes with Ruby, Git and pretty much all you need. If you don’t want to use EC2, you can use any kind of server with a recent version of Ruby installed with the ability to receive and send HTTP API traffic from the internet.
2) Maintainer access to your Transifex project.
3) The ability to add Service Hooks to your Github repo.
Once you’ve got your EC2 instance, connect to it using ssh. You’ll do all your work from there. Take a note of its public DNS name, as you’ll need it later.
# Make sure you have all the build tools installed
sudo yum groupinstall "Development Tools"
# Install dependencies
sudo yum install -y gcc-c++ patch readline readline-devel zlib \
zlib-devel libyaml-devel libffi-devel openssl-devel make bzip2 \
autoconf automake libtool bison iconv-devel # Install RVM bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
# Install Ruby rvm install 1.9.3
# Install Bundler
gem install bundler --no-rdoc --no-ri
# clone txgh
git clone https://github.com/jsilland/txgh.git # cd txgh
Now you will create the txgh config file. It’s a YAML file, which looks like this:
api_username: <your Github API username>
api_token: <your Github API token>
push_source_to: <transifex project slug>
<transifex project slug>:
tx_config: "/path/to/.tx/config, see below if you do not have any"
api_username: <Transifex API username>
api_password: <Transifex API password>
# edit txgh config file
# paste the contents above and edit to fit your configuration
If your Transifex project currently uses the command line client, you probably have a Transifex config file checked into your repo. Its default location is under a .tx/ folder in the root of your git repo. If it doesn’t contain one, use this support article to create one, or use this template:
host = https://www.transifex.com
[<transifex project slug>.<transifex resource slug>]
file_filter = ./Where/Translated/<lang>/Files.Are
source_file = ./Where/Source/Files.Are
source_lang = <source lang>
type = <FILETYPE>
Finally, start the server:
# install bundled gems
# start the server
bundle exec rackup
Puma 2.5.1 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:9292
Now, you can keep the server running, and go configure the webhooks in Transifex and in Github:
How to configure webhooks in Github. You will want to point the new service hook you’ve created to:
http://<public DNS name>:9292/hooks/github
To configure your webhooks in Transifex, you will need to go to your project management page and point the webhook URL to:
http://<public DNS name>:9292/hooks/transifex
That’s it! While this starts the server in development mode in a free ec2 server, if you do any kind of larger scale development, you would probably want to run this on a more stable instance, in production mode, with appropriate monitoring. But once you’ve configured the webhooks, any change that makes a file be 100% translated in Transifex will trigger the server to push a new commit to Github with the updated translations files, and any change in Github to the source files will trigger the server to update the source content in Transifex.
One thing our customers have recently been curious about, yet hesitant of trying, is to tap into their user community to translate their content.
Having been involved with such efforts, I can sympathise. It’s a daunting undertaking. Will it work? How do I make sure my community stays active? How do I deal with quality issues, or even detect them?
I also wanted to expand on my presentation at Localization World. Some interesting points were raised by the audience, and I wanted to share some of the issues we discussed and give those who were not present a chance to participate.
While community translation programs are quite difficult to start, they are also incredibly gratifying: the ability to connect with your early users in a country is key if you want to win a market. As this TED video explains, you have to take care of your first followers if you want to start a movement :-).
The three most common misperceptions about community translation that I hear are the following:
Most people have heard the horror stories: some site having to retranslate their whole user interface after a poor attempt at community translation. While some of these stories are true, what they do not mention is that most sites that had some early setbacks still use community translation to a certain extent, and some quite successfully.
An often forgotten point is that while there are certain pitfalls to avoid when starting down the community translation path, some of the same ones apply to working with vendors as well. There are stories of poor translations in the language service provider world too. I actually found that most of these stories share a common problem: throwing content over the fence to be translated with little collaboration doesn’t work. Translating anything requires a dialog with the initial creators of the content to ensure its meaning is properly interpreted.
Finally, an essential element of quality in a community translation program is the quality of the moderation program itself. We will get to that in a bit.
Another common misperception of the community translation solution is that it prevents any kind of deadline to be set. While some of it is true, it is certainly possible to work with a community of users and have them keep a good enough pace to keep a relatively large website translated. Some early Twitter languages took a while to be translated, but others like Traditional Chinese took just a week.
The critical aspect to speed in community translation is that it is a byproduct of a good moderation program. Steering users to the content with the most priority is important when dealing with their limited time. Keeping the most important content to translate at the top of their list ensures that it gets translated fast.
Most people believe that community translation is a cheaper alternative to hiring professional translators. Careful observation of the costs involved, in my experience, shows that not to be the case. Between the moderation program, research, and software development, most successful community localization programs incur costs that are even or larger than contracting with a language service provider. Salaries, servers, etc. can result in big monthly fees you have to pay even when you do not have a new language or new features to launch. Do not choose this model if you’re trying to cut costs!
An important thing to keep in mind is that monetary incentives are pretty much off the table. Orit Yehezkel, Head of Localization at Waze, says:
"If you give the community money, it’s not a community anymore. They become mercenaries."
A better way to spend that money is to put it to work in community building efforts: organizing conferences, meetups for your community, creating programs to recognize them and providing other types of incentives like access to beta features. While these can represent a large investment, the money doesn’t go directly in the communities’ pocket. It is used to create goodwill, and comes with an investment in some of your time, which will be much more noticed and appreciated.
There are so many different types of content that are produced and translated that attempting to list all of them would be fruitless. I’ve categorized them into seven different types below, but keep in mind that because your content is not listed here doesn’t mean it won’t work.
The most important aspects are to be aware of what kind of category your content fits in and to think about what might drive someone to translate that content or to become disinterested in it.
1) User Interface
This is typically the first thing attempted and historically the most successful. This is what drives most of your community to translate: they want to see the product in their own language.
There are variations on how you would approach this translation process depending on what type of software you’re translating (mobile app vs. website, responsive HTML5 vs. static content…) but those variations apply to how you would handle this content with a traditional language service provider so I will leave them to another blog post.
Short fun stories will be translated very quickly and well, even by volunteers. Some other content may require enlisting the help of a local marketing expert.
I’ve attempted to crowdsource the translation of a slogan at Transifex into French with some good success. The discussion that came out of it was very useful and thought provoking.
3) Static Help, FAQs
Short, simple text can work, but it will require a large community and dedication that is closer to the type of efforts we see for some Open Source projects. Twitter, with up to a million translators, had to decide to translate this with a language service provider. However, forums and social media can also help build a knowledge base. Some companies have experimented with users supporting each other. There are great tools out there to do that already!
4) Support notes
Support notes are time sensitive and need to be right the first time. Translations need to be fast and accurate right away, and their content is often very dry. This makes it a tough sell for a community localization program.
The idea with this content is to have the community help create the terminology, but leave the interpretation / execution to professional translators.
The challenges with this idea is how fluid community translations can be sometimes. Having the right tools to lock down terminology and making sure that it is finalized before sending it to the professional translators can be a challenge.
Today, some tools can do an automatic glossary extraction. With a community translation process applied to the output of these tools, coupled with a modern TMS to perform the actual translation of the content it might be possible to try it out and get a good feedback from a limited community of users.
This might be a good sweet-spot for an organization who wants to try out community translation with a small investment.
6) Style Guides
There are tons of standard ones. An option to involve again the community in this process could be to use a wiki to have the community participate in the definition and creation of how the product talks to them?
7) Terms of Service
This is probably best handled by a lawyer. Most of the time, the work required is not just to translate, but to adapt to fit the customs and rules of the local country. This makes this type of content a poor choice for community translation.
Beyond those different types of content, there are also surprising differences in which languages happen to be successful at doing community translation. While it’s difficult to point to any particular trend, it’s worth keeping in mind a few things:
Some smaller languages are dying to help you translate, so don’t overlook anyone. For instance, you may have a very loyal following in a in lesser known community: a small community of users in Catalonia who email your CEO for an official translation effort so much that he had to crack and ask their engineering team to do it :-).
One nice side effect of community translation, because it is a heavy investment, is that it needs to scale across many languages to be cost effective. But being able to access a lot of these smaller pockets of users quickly can be an effective strategy for some!
In some languages, most early adopters are “perfectly fine with English” and thus will have a limited interest in helping translate your website in English. If this market is important for you, you might have to invest in a professional translation. The risk there is that the translation may not be necessary.
An important feature of a successful community localization program is the quality of its moderation team. While moderation is good in moderation, there is an art to doing it well.
You might think that a core competency for moderators would be to be able to tell the difference between a good translation and a bad translation. For instance, our initial tests showed that the best moderators were not those who provided the best translations, but those who voted up the best translations.
Another important job for the moderators of these communities is to actively find “broken windows” in the community to repair. These jobs can vary from putting out a flame war between translators on which form of the word “you” should be used in your product, to organizing a translatathon where translators get to meet on IRC, or a brief chat to discuss various glossary terms that have been misused.
Finally, as a moderator you have to act as a control and monitoring tool for the health of each community, making sure it has what it needs to be active and productive. This can mean being innovative in creating content, to keep people coming back:
When it comes to translations with the community, with enough volume you can think of the community as a forest fire. It spreads outward translating everything, leaving inactivity behind in the middle. You want the strings and translations that are active to be the most useful ones, or the ones with the highest priority. As the activity increases, there’s more and more trolls on the limited strings available for translations. This makes for a poor user experience. I learned a few choice words in Greek that way…
There are three approaches to moderation:
1) Automated Moderation
In this model, the system is self-policing. Each user is both responsible for contributing moderation and content. This typically uses a reputation system based on votes. In general, 3-5 votes are enough to promote a translation to reviewed.
There are a few ways to automate the moderation, running the gamut through what I call a “laissez-faire” approach to a fully gamified experience.
Laissez-faire: This uses votes as a signal to decide moderation. The underlying assumption is that the community in this case relies on intrinsic rewards; Getting the site translated is an end to itself.
Gamified: This allows you to extend community efforts beyond translations, but actually editing content or personalizing the experience for users in that country.
2) Controlled Moderation
In a controlled moderation environment, users provide the translations, but a paid team of linguists/reviewers/community managers adapts and corrects the translations for consistency. We recently experimented with this approach at Transifex and translated our site into FIGS with the help of our community and e2f.
Quality control can be done using different processes:
a) On signup, using an invite only system: Users can only be invited to translate, using some kind of a referral program, or after having been vetted by a human. This also provides a good way for you to ensure your translators have access to a contributor license agreement if your legal team requires one.
b) After the fact: Users provide the translations, but a paid team of linguists/reviewers/community managers adapts and corrects the translations for consistency.
3) Crowdsourced Moderation
In this model, the responsibility of choosing moderators falls on the community itself.
Used frequently in the Open Source world, this model requires you to steer your community towards a collaborative model rather than a competitive one. The gamification techniques mentioned earlier may thus need to be adjusted.
Another interesting area to explore once the translation effort has settled is to expand the localization effort to other types of work. Now you’re asking your community to not just add translations, but to actually act as editors or curators for some of your content. Waze comes as a very successful example in this area, with users contributing mapping data, gas prices, hazards, with very specific location area. Twitter has a similar effort on-going currently with their country specific suggested user lists.
Transifexians, we have good news for you! From now on you’re going to have even more power in our editor to manage your translations the way you wish, since now you are able to choose the validation checks that will be run against your translations, such as whether a URL is entered correctly by the translators. So, let me introduce you to our new feature.
We have been doing that for you by setting what checks are necessary for the new translations. These checks can be errors or warnings. When an error check for a translation fails, then the translation is rejected, but when a warning check fails, the translation is saved. In both cases translators see an appropriate message.
But isn’t it better for oneself to decide on the rules that will have an impact on his life? We believe so and that’s why we now let you decide in which occasions your translators will be just warned or not be able to save a translation at all, if it doesn’t match the rules you set.
To be more precise, each organization can now set its own translation checks for each type of file that it uses under the Manage Tab of its dashboard. Take a look below:
Example case is the following:
Let’s say I have PO and YAML files: I can choose what checks I want to be run for each file type whenever a translator translates my content.
So for the .po file, initially I see the default checks for errors, warnings along with the disabled ones. Now I can easily change them and switch a warning check to be an error check, and vice versa. I can even turn one check off. So if I switch a check to “Error” then the translation that does not pass the corresponding check will be rejected but if I switch it to “Warning” then the translation will be accepted and saved. If I turn off a check then it will have no effect at all.
Let’s try it live.
Case 1: I set the validation check “Email addresses found on source string are preserved in the translation” as Warning.
Then, if I try to translate a string that has an email and I don’t preserve the email in the translation, I get a warning but the translation is saved.
Case 2: I set the same validation check as Error.
Then, if I try to do the same in the editor, I get an error mesage and the translation is rejected.
And that’s all!
Isn’t it cool? And it’ s available for all. Let me know your opinion!
We’d also love to have feedback on our validation checks. Which ones are the most valuable in general, or the most valuable for a specific file type and so on. We could also have suggestions for new ones!
Happy localization people!
ConcertWith.me is a Russian startup providing concert-goers with a simple web app that answers two questions: “Who are the artists playing near me?” and “Who will go to this concert with me?”
Built for the casual concert-goer, it differentiates itself by keeping the focus on the music and adding a social element, while cutting out the noise in concert listings.
We invited Vit Myshlaev, one of the co-founders, to share about why they localized their app and the results they’ve seen so far.
When we launched ConcertWith.me in June 2013, it was only available in Russian and English. As users started inviting friends from outside our home country of Russia, we expanded our concert database to cover all of Europe.
At the same time, we decided to build localized versions of the app and provide support for users who don’t know Russian or speak English as their first language. This also gives us a competitive advantage when most of our competitors were only in English.
Which Languages to Support?
Using two awesome tools together, we figured out which languages to target first. Intercom.io showed us a map of where our users are coming from:
And Google Analytics showed us the top visitor languages:
Additionally, we researched English language penetration in European countries:
It was clear from the data that we should support Serbian, Spanish, Czech, Portuguese, French, Italian, Polish, and German.
As a small team with only my co-founder and I, we don’t have the extra time or human resources to manage translations, so we turned to Transifex as the solution to get our translation project up and running immediately.
Launching the App in New Languages
After uploading our UX and email strings to Transifex, we invited users from each target country to join our translator community. (Tip: It’s useful to provide step-by-step instructions for your translators and reviewers.)
Many agreed to help and in just two days, we got our first new language: Serbian. Spanish, Czech, and German followed soon after. We were ecstatic.
The initial results have impressed too:
Average page views per visit increased from 1.5 to 2.3. (ConcertWith.Me is a one page app with very few pages to load, so this is a big leap.)
Average time on website jumped from 58 seconds to 3 mins and 40 seconds for Serbian users, a 279% increase.
Our Serbian ad campaign converted visitors to users 50% better.
In Belgrad, Serbia’s capital, average friends per user is now at 2.1, which compares well with 2.3 in Moscow, our home town.
Get Started Early
As a final takeaway, I’d say that it’s key for startups to be global from the start. Yes, you have a never-ending to-do list. But localization is well worth the effort. And with tools like Transifex, localizing your product is more achievable and simpler than you might imagine.
Want to help? You can get involved with the ConcertWith.Me project on Transifex.