Making Education Available Anytime, Anywhere Across Language Barriers

Localization opens up many opportunities. So does education. When combined, the world-changing potential becomes limitless. Today, we are proud to announce a partnership with Coursera, a leading Massive Open Online Course (MOOC) provider. Together with Coursera and nine other organizations from eight countries, complete course lectures across multiple disciplines will be translated for students around the world, for free.

Leading translation companies, philanthropic organizations, mobile carriers, nonprofits, corporations, and universities have joined forces in this Global Translation Partners Program with Coursera. Each of these organizations will begin by translating 3 to 5 select courses into Russian, Portuguese, Turkish, Japanese, Ukrainian, Kazakh, and Arabic, with the majority of translated courses available by this September.

To make this possible, Coursera is relying on our continuous localization platform. Our cloud-based tool will host Coursera’s translatable content and allow these organizations and individuals to easily contribute course translations from anywhere, using our translation editor.

For the time being, course lectures will be translated via subtitles while all other course material, including quizzes and assignments, will remain in the course’s original language. Coursera’s long-term goal, though, is to have their platform localized to global audiences.

Since their launch, Coursera has been taking big strides to connect people with a great education and help students learn without limits. In past few months, they’ve added 29 new universities to its platform, including 16 international schools that offer courses in Chinese, French, Italian and Spanish. In April 2013, Coursera also kicked off a pilot translation project with Russian organization Digital October.

Just as we strongly support and believe in open source initiatives, we have a passion for education and movements to make learning widely accessible. Now, by joining forces, Transifex, Coursera, and all the other partners are taking a giant leap forward toward making high-quality education accessible to anyone, anywhere — regardless of what language they speak. We are excited to see where this partnership leads to!

Case Study: Connecting Fashiolista’s Global Fashion Community

Fashiolista is a fast growing fashion social network with members from all over the world: New York to London and Rio de Janeiro to Tokyo. Members can save and share their greatest fashion finds from all over the web, as well as get inspiration and discover new fashion items, brands, and stores. Among Fashiolista members are many of the top fashion bloggers and influencers.

Launched in the spring of 2010, Fashiolista now boasts 1.5 million members in over 160 countries. It is one of the world’s largest fashion communities.

With a growing user base from around the world, the Fashiolista team decided to localize their website. It was time to go beyond English.

Choosing a Localization Platform

After the decision was made to offer Fashiolista in other languages, Thierry Schellenbach (Founder/CTO) and Tommaso Barbugli (Developer) began evaluating various services and tools for managing their localization process. “We found Transifex because a lot of open source packages are translated using Transifex,” says Thierry.

“In the past, we were using another translation interface. However, Transifex’s tools for integrating with our development processes made it a clear winner,” he says. The Fashiolista development team relies on the Transifex API to eliminate manual and redundant processes. “When we have new strings that need to be translated, they are automatically shared from Fashiolista’s codebase to Transifex, where our translators can access the strings and submit translations.”

Vanessa Cristão, Communications & Research Manager at Fashiolista, adds, “Not only was it important that the tool we chose would integrate with our development environment, but we wanted that tool to provide translators an interface to translate. Transifex does both.”

Fashiolista’s Translation Process

“Every time a new website feature is launched or a content page is updated, I check for new content on Transifex,” says Vanessa. “Whenever new content or strings need to be translated, I just have to send a quick email to all the translators, and it all gets done in a few days.”

Today, Fashiolista operates with just a single translator per language, all of whom are users of the site. A native Portuguese speaker, Vanessa does all of the English to Portuguese translations herself. She leveraged her personal network to find translators for other languages, such as German and Russian.

All of Fashiolista’s translators translate in the Transifex web editor. “With everything in the cloud, all our translators are using the exact same tools. They get the same user experience,” Vanessa explains. “It’s one less thing to manage.”

Before the translations are made available to Fashiolista users, Vanessa runs tests on a staging server to make sure that all the strings are translated and fit properly in the user interface. If something is not quite right, she contacts the translators and any minor adjustments are made quickly.

In the future, Vanessa plans to leverage native speakers among the Fashiolista user base to review the translated strings for accuracy.

Results

Transifex makes it possible for companies of all sizes to localize their products and go global. Even with 8 languages offered, no one at Fashiolista needs to dedicate 100% of their time managing the localization process. Vanessa says, “With Transifex I can easily manage all languages in one place. It’s very easy to see the state of all translations at the same time. It’s very practical and saves me loads of time.”

Transifex site issue

We experienced intermittent access issues affecting our web users between May 8th and 9th, depending on your timezone. Only a small portion of our users was affected. This issue has now been resolved.

The incident was caused by an issue with our domain name registration. We’ve already taken corrective measures to ensure that similar issues do not occur.

If you were negatively impacted by this downtime, please contact me personally.

We apologize again to the users who were affected and thank you for your patience.

Dimitris
Founder & CEO

10 Rules for Painless Software Localization

Your team built a killer app in English. High-fives all around. Your user-base is growing, reviews are all positive, you even caught TechCrunch’s eye. Life is good.

Then your 15 minutes are up. Sales flatten out. You start losing market share to a new competitor.

The technology sector has the memory of a goldfish. New players rise and fall every day. You stand a cold thing’s chance in a hot place of riding your initial success through a career-full of revenue. Unless you localize.

You just groaned. Software localization is not your favorite thing. You love to build things, and translating is much less fun. Few developers are eager to localize until they hear about all of the business they are missing out. Try this on for size:

• The global SaaS market is forecast to grow by more than 15% in the next year.
• The United States accounted for a paltry 34% of the global revenue from iPhone apps.
• The Arab gaming market is expected to triple in the next 36 months.
• The largest employer in the world is the Chinese crowdsourcing agency, Zhubajie, which boasts a workforce 7.6 million strong.

Consider the social networking site, LinkedIn which heads the Forbes list of 25 Fastest Growing Tech Companies. Founded in 2006, LinkedIn is a relatively young company only available in two languages, English and Spanish, for much of its history. The site now displays content and offers customer services in 19 different languages and counting.

The story is much the same for the other 24 companies on the Forbes list.

Coincidence? We don’t believe in coincidence.

Bottomline, there is a lot of money to be made in software development right now, but most of it is global money. You need to localize your software.

Here are a few things to keep in mind:

1. Use a Continuous Localization Platform

This might sound a little self-serving coming from us, a company whose product is a Continuous Localization Platform (CLP), but seriously, you need one. Before the CLP, you had only two options: Human (great final product but slow and expensive) or robot (fast and cheap and terrible). A CLP allows you to remain in control, access real-time analytics, protect your intellectual property and get your software translated efficiently. It’s really a no brainer.

2. Always Use a Full Locale

Be as precise as possible when you localize. Different regions may speak and spell a shared languages with nuanced differences. What is a trunk to you might be a boot to someone else. You might offer a favor and they might hear favour. Your software should reflect an understanding of those differences.

3. Make Room for Strings to Grow & Shrink

Design should already be part of your most precious intellectual property. You should invest as much energy on your software looks as on how it works. As you design, keep in mind the reality that text will vary in size as you translate it.

“Repeat password” is 50% longer in German than in English; if you have not left enough space, localization will break your design. You will need a 2-pronged approach to this problem. You want to create enough elasticity to accommodate a 40% variance. This will take care of most strings in most languages, but you will also need to test early and often. Let your designers be involved in the process at every phase, so they do not experience a bottleneck of updates once the translations are complete.

4. Start with your Product Page and Description

If you are really nervous about the whole localization scene — not sure your product will have global appeal, or remain unconvinced of the business logic — then start small. Many companies have seen great sales gains resulting from the launch of a localized product page even without making changes to their software. If you decide to use your product page as a test, be sure you do it right. Comb over every single pixel of your product’s LP and every syllable in your app store description. Adjust the username in your screenshots (“Carlos” instead of “John”) change any references to location (maps, pictures, timezones) and make sure you get it right. You don’t want to fail because of poor execution and come to the (incorrect) conclusion that localization does not work.

5. Never Concatenate Strings

Sloppy amendments in CSS or HTML, qualifying one string with another as can often happen in redactive search, is a shortcut that nobody will notice until your software is localized. When you do, you will have bugs out your ears. Even the Romance languages, which are very close to one another, have subtle syntactical differences. Sometimes modifiers come before nouns, sometimes after, sometimes they become a suffix.

Instead, code the entire string together and allow your translators to put the words in the correct order for each linguistic context.

6. Include Punctuation

It is tempting to omit punctuation while you are coding, and plan to add it later. Maybe you hope to re-use the string in different contexts where it will need to be punctuated differently. Don’t.

Include punctuation in context, and create unique strings for each line of text. Even the same sequence of words, may translate differently with different punctuation. In French, for example, a colon is surrounded by spaces. If you omit the colon in your string, and try to add it later, your French interface will have a typo that your translators could have helped you avoid.

7. Pay Special Attention to Proper Names

Some languages alter the spelling and pronunciation of proper names in different contexts. Others alternate the placement of given and family names. Pay special attention to your treatment of names. It’s best to offer all three fields- first, last and username.

8. Never Hard-Code Date, Time or Currency

Time and date formats vary wildly around the world. Currency too. Java can help. Code in a universal format like ISO time and then tap an open-source library like Date.js to format for your specific location.

This can be especially in date selection tools. Estonia marks Saturday as the first day of the week, the US starts on Sunday, the UK on Monday, the Maldives on Friday. Use the jQuery UI date picker to overcome this challenge.

9. Plan for Languages that Read in Both Directions

Most languages read from left to right, but Arabic and Hebrew read from right to left. CSS and HTML provide a directional property, but they will not override a CSS element coded as “float: left” or “float: right”. If you have fixed positioning layouts, you might need to build an entirely new set of style sheets for your left-to-right products.

10. Never Trust the Browser

Yes, the browser can translate. But you shouldn’t trust it. Any extra work the browser has to execute on your app will make it slower, and nobody likes to wait. Let the browser do what it does: browse. Let the people coo about your speed. Localize. Don’t trust the browser.

Software localization can be a painful process, but it doesn’t have to be. Follow these simple rules and you can launch your software into a global marketplace without more than a little pinch. We promise.

By Dimitris Glezos

Why I hired Nico Sallembien as our VP of Engineering

A few months ago, one of the engineers on our team asked me who, in my opinion, was the best engineer in the world we could hire right now. I answered squarely, “Nico Sallembien”. A little later, I gave the same answer when a VC, who was trying to convince us to raise capital quickly, asked me to name the top person I’d compliment my leadership team with.

At the time, Nico was at Twitter, where he built its highly successful localization platform used by close to one million translators worldwide today. Before Twitter, he was at Google building their internationalization stack. And before that, he was at Ariba and Borland.

I’m ecstatic to share that Nico Sallembien has joined Transifex as our VP of Engineering.

We’ve been keeping close tabs on Nico for a while. He’s a visionary who just “gets it”. He understands the true power of localization and its possibilities if you make it work right (painless, automated, accessible, and dead easy). Nico is one of those passionate people who shines working with teams building groundbreaking technologies. And one of those guys who I am never tired of talking technology with.

#ItsGonnaBeAwesome

By Dimitris Glezos

Taggin’ it and lovin’ it

Friday’s updates brought another feature to our beloved translation editor: tags.

You can now tag the entries of your files from within the editor, either one by one…

…or many together:

And you can search for entries by tags:

Of course, you can combine the tag filter with the rest of the filters, so that, for instance, you can look only for strings that have a specific tag and contain a specific phrase.

There are many use cases for tags in the editor:

• You can group entries according to where they are used in the source code or the feature they are for. For instance, all marketing-related entries could be tagged accordingly, so that your translators know to pay extra attention to how they translate them.
• You can give priorities to entries.
• They can work as a basic workflow tool. The project managers can tag specific entries and ask their translators and reviewers to work on them.

Make sure to read more in the docs and let us know of ways this could be even more useful.

Word count change for Japanese, Chinese and Korean

Today, we introduced a change that affects the wordcount of all projects with Japanese, Chinese or Korean as the source language. 

Up until now, the word count for phrases in these languages was calculated by splitting the phrase on whitespace characters (tabs, newlines and spaces) and counting the pieces produced. However, the industry standard states that because whitespace characters in these languages are not used the way they are used in other languages, the word count should take into account the number of symbols instead.

With today’s change, the word count for Japanese, Chinese or Korean will be calculated by multiplying half the number of symbols in your source language by the number of languages Transifex hosts translations for. If your source text consists of 50K symbols, Transifex now considers that number to be 25K.

You can find more info in our documentation.

Changes in how following projects in Transifex works

A new update in Transifex has been rolled out that affects how users can follow the updates of projects.

One of the features of Transifex translators find really useful is to get notified whenever there is more work to be done. Be it volunteers that want to see their favorite project translated as soon as possible or professional translators that have deadlines to meet, it is important to know when there is new content to be translated.

With the latest update we tried to make this feature much more useful to translators and overcome the limitations of the previous system.

If you want to receive updates for changes in the files of a project, you have to watch it. Every project has a link in its main page for that.

Moreover, you can choose to watch a specific language a project is translated in. The relevant link is in the main language page of the project. Keep in mind that it is not possible to watch a language for a project that does not employ teams for the translations. This is a change compared to how the feature worked before, where you were only able to watch the updates for a specific file in a specific language.

In the notification settings, you can find a list of the projects you are watching 

Currently, you will receive updates whenever a new file has been added to the project, a file has been updated or a file has been deleted. You can find more in the documentation.

Let us know what you think.

Changes in notification emails

Today a new update was rolled out that affects the notifications Transifex produces. The goal was to make them much more useful to the users.

The first change is that notification emails have been grouped into well-defined categories, as you can see in the following screenshot. This makes it far easier to identify exactly the categories of notifications you are interested in receiving emails for and enable just those.

In addition, all emails have been revisited with respect to how clear their message was and how easy it was to react to those notifications. We tried to make sure the messages are now precise and have all the necessary information and links to Transifex for you to take an action on. In case an email was redundant, it was dropped.

Another feature of the new notifications is that Transifex now sets the List-ID header based on the project the email is for. This allows for email clients to identify all emails that are related to a certain project and group them accordingly.

Under the hood, there was a complete rewrite of the code responsible for the notifications. We now use a library that implements the observer pattern (no, not django signals), which allows us to generate notifications under more precise conditions — no more multiple emails on the same subject.

We have received in the past a few complaints about the notifications Transifex produces. We hope this update fixes those issues, although more changes are coming. In any case, let us know for any improvements or new types of notifications you might need.

Changes in key-value formats

A change in the way an upload of a source file affects the translations for it was deployed earlier today.

When a maintainer of a project uploads an updated source file, Transifex will extract all entries from the file and save them in the database. At the same time, it will invalidate all translations for the entries that were changed or deleted completely.

Until now, Transifex would look only at the identifier of the entry, to determine, whether the entry had actually changed. For instance, in PO files this is the msgid part of an entry. On the other hand, if the value (source string) of the entry had changed, Transifex would just update the source string, without any effect on the translations for that entry.

The reasoning for this behavior was that in most formats the source string is placed in and extracted from the source code; that is, the identifier for an entry is the source string itself. As a result, any changes in the source string would affect the identifiers, too.

However, there are certain formats that are used in a different way. In these cases, the source code only contains a key as a placeholder for the string instead of the string and the source string lives in a key-value like file. There are many formats that fall in this category, like Java .properties files, YML for Ruby On Rails and Joomla .ini files. The typical workflow in these cases is to never change the key in the source code, but update the source string in the source file instead (the value for that key).

For this reason, Transifex changes the way it works for this kind of formats to better suit this workflow. So, it invalidates the translations for an entry, when the source string changes, even if the identifier is still the same.

This change should not affect in any way the day-to-day operations for any project that does not want to benefit from this feature.