By Edouard on July 31, 2017
You can now translate Hugo .yml files with WebTranslateIt.
Hugo YAML files are special YAML files which are parsed in a specific way by WebTranslateIt. You can read more about it in our documentation about YAML files.
We hope you will find this new file format useful. Thank you for using WebTranslateIt.
By Estelle on July 26, 2017
After spending a few years travelling the world, Jet has decided it would be time to use his boundless knowledge and experience to help WebTranslateIt’s community to reach out to worldwide customers.
Let’s all welcome Jet for on the long and windy road to globalization, he is going to take you far far away. And fast.
By Edouard on July 26, 2017
You can now translate INNOSetup .isl files with WebTranslateIt.
INNOSetup .isl files are used to translate Windows installers. You can read more about this new file format in our documentation.
We hope you will find this new file format useful. Thank you for using WebTranslateIt.
Want more? Follow us on Facebook and Twitter
By Edouard on July 23, 2017
We made an update about how translation changes are attributed to people on WebTranslateIt.
Before this update, any translation change made was getting attributed to the name of the person making that change. While this is correct most of the time, it wasn’t right to say that a person translated a segment if the only thing that person did was flagging a translation as “to verify”.
From now on, instead of only tracking the person who made the last change, WebTranslateIt now tracks the name of the last translator and the name of the last proofreader and displays this information when you update a translation.
This change also now makes it possible to filter segments by last translator and last proofreader, which is useful if you want to check on the work translated by a specific translator. You will find these new filters in the filters section at the top of the translation interface.
We hope you will find these improvements useful. Thank you for using WebTranslateIt.
By Edouard on July 5, 2017
By Edouard on July 5, 2017
Why should you translate your application?
Because it will open your app to new markets. You will get new customers/visitors
Only 26% of the world’s Internet population understands English. By localizing your application to their languages you will therefore gain customers.
Localization only is an accelerant, though. An application currently having a poor market fit in its current market probably won’t magically work in foreign markets too. You need to already have traction in order to get more revenue. Localizing an app which has troubles finding its market niche is likely to cost you more money than you will earn.
Let’s say your software’s annual revenues are $10,000 per year. You estimate that translating your app in Chinese will open you to the Chinese market and will make your revenue grow 10% a year thanks to that.
10% of $10,000 is $1,000. Given that translating your app into Chinese cost you $1000 it might be worth spending that money into development work or marketing in order to increase revenue before thinking about localizing your application.
Now, if your software annual revenue is $100,000 a year, this is a whole different story. 10% revenue growth represents $10,000 more per year. Growing your company worldwide can be a great way to increase your revenue, at the cost of an increased complexity.
By making your application available into more languages you will increase complexity. If you regularly update your application with new feature, your development team could deploy new features whenever they were ready.
Now the development team will deploy the new feature whenever the new feature is translated and the translations tested.
If your team has more than a few developers it is likely you will need to set up a strict workflow so new features are only deployed after they are translated and so that translators can work on a stable environment where no new segments to translate creep in while they are currently working. This typically slows down a new feature release by about a week. We’ll write an article about workflows for internationalization in the future.
A few week in after having defined a proper workflow having a internationalized application will feel easier. After all with a good process in place and outsourcing the work to good companies things aren’t too difficult. But growing your organization worldwide is not only about translation work.
If you handle tech support for your app you will have to handle it in the supported languages too. It might mean hiring and training customer representatives in these new supported languages.
It might also mean to adapt your application to the local laws, secure local domain names, …
By Edouard on July 5, 2017
In any case, internationalizing your application is a manual process where you extract all the translatable text out of file, and place it in a linguistic file, which compiles all the translatable text of your application.
Then, a mechanism to retrieve the translated text is setup, which lets the application display the translated text from a linguistic file, depending on the requested language.
Will that slow down my application? Usually no. Templates are usually cached into memory. In the rare case it’s not the linguistic file content is likely to be loaded in memory, and the lookup to find the translation is negligible on today’s hardware.
Translators are not programmers. Writing good copy for i18n is not always easy for developers. Here are a few rules to write better copy for your internationalization.
Try to extract complete sentences that will make sense to a translator.
Original text: “Hello, good to see you.”
GOOD: Hello, good to see you # Perfect, the sentence makes sense
BAD: Hello,
good to see you # It can be hard for a translator to understand the context of one or the other string.
Most internationalization frameworks let you interpolate variables. Choose your variable names appropriately, so translators can understand the segment in context.
Original text: Hello #{user.name}, Good to see you.
GOOD: Hello %{user_name}, good to see you # Perfect, the sentence makes sense
BAD: Hello
good to see you # Context can be difficult to understand.
# You don’t necessarily greet people “Hello username” in this order in other languages.
SO-SO: Hello %{var}, good to see you # Context is a bit difficult to understand.
# Give the variable a better name.
If something is not translatable, don’t include it in a linguistic file.
{$starttime|displaydatenotz:'hour'}
Original text: <a href="urlblah" title="Hello!" onClick="$('thingy').toggle(); style="color: pink; font-size: 12px">Hello there!</a>
GOOD: Hello!
Hello there! # Perfect, the sentence makes sense, no code.
BAD: <a href="urlblah" title="Hello!" onClick="$('thingy').toggle(); style="color: pink; font-size: 12px">Hello there!</a> # Too much code! Translators will make mistakes in the code,
# which will break the feature.
Sometimes you have to, though:
Original text: Hello <strong>#{user.name}</strong>!
GOOD: Hello <strong>%{user_name}</strong> # Perfect, the sentence makes sense.
# There are some code but this is acceptable.
BAD: Hello # Context can be difficult to understand.
# You don’t necessarily greet people “Hello username” in this order
# in other languages.
BAD: Hello <strong>%{user_name} # As a rule of thumb, if you include some code in the translatable text,
# include it all the way.
Remember, translators are not programmers! Translatable text is not the place to write clever code. In my experience, it’s better to repeat yourself than to write a clever sentence translators will have troubles translating.
Example:
Hi {if $to}{$to->getLinkText()}
{else}there{/if},
{if $user}{$user->name} {else}{$fromname} ({$fromemail})
was on our awesome website and {/if}{if $attending}thinks you should come along to
{if !$eventname}see{/if}{else}thinks you might be interested in
{if !$eventname}seeing{else}going to{/if}{/if}
{if $eventname}{$eventname}{else}{$headliner->getLinkText()}{/if} at
{$venue->getLinkText()} on {$startdate|displaydate:'shortdmy'}.
This kind of code needs a complete rewrite. It’s best to write conditionals, each containing one full sentence.
Pluralization is a way to change the spelling of a noun depending of the plurality of a variable.
Let’s consider this example: Less than #{@count} minutes.
It displays:
Less than 0 minutes if @count equals 0, which is correct.Less than 3 minutes if @count equals 3, which is correct too.Less than 1 minutes If @count equals 1, which is incorrect English.Developers usually get around this by writing conditional around this sentence, creating two strings for the translators:
if @count equals 1
then display “Less than 1 minute”
else
then display “Less than %{@count} minutes”
The problem is that pluralization differs from one language to another. In French for instance, it’s spelled:
Moins de 0 minute if @count == 0Moins de 1 minute if @count == 1Moins de 3 minutes if @count == 3So, the conditional works in English, but doesn’t work in French.
Even worse: languages such as Polish or Arabic have 4 and 6 plural rules, and languages such as Chinese or Japanese have no plural rules at all!
Thankfully Unicode publishes and maintains CLDR, a database listing the plural rules of most languages. Also, good internationalization frameworks take care of this complexity for you, so you will have to use it.
In your application, you will extract the text like so:
t(“less_than_x_minutes”, :count => @dogs.count)
And in your linguistic in English will look like so:
less_than_x_minutes:
one: “less than %{count} minute”
other: “less than %{count} minutes”
Which will translate in French:
less_than_x_minutes:
one: “moins de %{count} minute”
other: “moins de %{count} minutes”
In Russian:
less_than_x_minutes:
one: "меньше %{count} минут"
few: "меньше %{count} минут"
many: "меньше %{count} минуты"
other: "меньше %{count} минуты"
In Chinese:
less_than_x_minutes:
other: "不到 %{count} 分钟"
Internationalize database content is tricky. Handling the translation of this content depends on the nature of the content itself.
Is you database content static? For instance, is it a list of countries or a list of languages, then I would recommend using a unique identifier (such as a country code or language code), and translate this content in a linguistic file.
On my web application for instance I have a database containing all the languages in the world. Each language is identified by a ISO language code. I then use the language code to get the name of the country from a linguistic file.
Linguistic file:
languages:
en: English
fr: French
es: Spanish
da: Danish
The advantages are multiple. First, the kind of content is standard. It comes, once again from Unicode’s CLDR, which means it’s likely to be correct and won’t offend anyone. Second, this data was already translated on the CLDR repository, so I won’t have to translate this content by myself (This repository contains translated languages, scripts and territories in a YAML format). Lastly, we’re dealing with the real world, and this content is subject to changes: new counties appear, some disappear or get renamed. If that’s the case, it’s just a matter of updating this linguistic file from the source.
If you database content is fairly “dynamic”, for instance it is a list of products in a shop, then save the translations in database.
If you only need to translate one table, add one new column per language in your table to handle the translations. If you need to translate several tables, then create a dedicated table containing the translations of all tables.
[TODO: Develop]
If you develop a web application containing Javascript, then you’re probably wondering how to internationalize the text contained in the Javascript code.
The good news is that there are several plugins for Javascript to help you with this task. For instance i18n-js i18n-node or i18next. They all work by extracting the translatable text into a separate file containing a JSON hash.
If you don’t have much text to translate, a leaner solution is to extract the translatable text to a file compatible with your server i18n framework, and make your server dump these translations as a JSON hash inside your HTML body like so.
window.I18n = {"translations":{"key1":"text1.","key2":"text2."}}
You can then recover your translations in Javascript by calling window.I18n[“translations”][“key1”].
By Edouard on July 5, 2017
By Edouard on July 5, 2017
By Edouard on May 30, 2017
Today we just released a new feature in WebTranslateIt called Language Inheritance.
Language inheritance is only available to organizations on our new plans. It isn’t available to organizations on our “Legacy” plans.
Language inheritance lets you define a hierarchy in the languages of a project. It is useful because it lets you re-use and extend translations for languages having similarities, but yet are different.
For example, the French language is spoken in many countries: France, Belgium, Canada… Using this feature you could define a general language French with the fr language code on which you would save generic French translations.
French spoken in Canada is different from French spoken in France. You could then create a French (Canada) language with the fr-CA language code to write translations specific to the French language as spoken in Canada.
Using the inheritance feature, translations in fr will automatically fill in the translations in fr-CA, unless a specific translation in fr-CA is saved. It means you no longer have to manually fill in the fr-CA translations. You only need to correct the translations specific to fr-CA.
Visit our documentation to learn more about this new feature.
By Estelle on May 29, 2017
Here are 3 tiny but useful features we’ve been releasing over the past few weeks.
You asked for it, we made it! Mass-deleting a label from the filters now adds an activity in your project Activity Feed.
On top of that, it is now possible to recover the label and re-assign it to all the segments it was assigned to. To do so, click on the “Revert this activity” link at the bottom of the list.
On the subject of reverting things, we made reverting translations much better. On the segment history page you will find links to revert a translation to an old version.
Clicking on that link will now open the translation box and fill it with the text of that previous version, so you can do small amendments along the way.
Lastly, we refreshed the design of several pages, especially the page to restored deleted resources (deleted segments, files, languages, …).
That’s it! I hope you will find these improvements useful. If you have questions or feedback don’t hesitate to send us a message on our support form.
By Edouard on May 16, 2017
We just added support for the new Google Translate NMT API in WebTranslateIt.
The Google Translate NMT API is a new machine translation API released by Google using a Neural Network. We find it gives better suggestions for textual segments, but is not as precise as the original Google Translate API for text containing variables, so we found it useful to be able to get suggestions from both the original Google Translate API and the new Google Translate NMT API at the same time.
If you would like to use this new API, just add your Google Translate API token in your project settings.
I hope you will find this improvement useful. Thank you for using WebTranslateIt.
By Edouard on May 4, 2017
Do you have many public projects? If you do, you can now provide your translators with a list of all your public projects by setting your organization as public too.
Organization owners can set the organization as public in the organization settings (by clicking on “Account” and then “Settings”.
Public Organizations are visible to people who don’t belong to the organization, and display a list of the public projects they can join.
Here’s an example:
https://webtranslateit.com/en/organizations/1-atelier-convivialite
I hope you will find this feature useful. Thank you for using WebTranslateIt.
By Edouard on May 4, 2017
The activity feed for translations just got a bit better.
It is now possible to display the exact differences with the previous translation as an highlighted Diff. In order to display it just click on the translation text.
I hope you will find this new feature useful. Thank you for using WebTranslateIt.
By Edouard on April 24, 2017
Today we’d like to introduce you to one of our biggest features so far: Teams. It includes the creation of a new role within an organization: Language Coordinator.
Teams is a completely new feature which will only be available to organizations on our new plans. It isn’t available to organizations on our “Legacy” plans.
Teams simplifies user permission management across projects. It lets you define a team of people with its permissions under one organization.
While you can also invite users directly to a project, Teams lets you create a group of people on the organization level, which means it will be possible to re-use this team on all the projects on your organization.
Once created, the Team can be assigned to as many projects as you want.
This feature is unavailable to organizations on a “Legacy” plan. It is only available for organizations on a Free Trial, or on the Micro, Small, Medium, Large, Extra Large plans and onwards.
You can upgrade your organization from a “Legacy” plan to the one of the new plans on the organization Billing page.
You can learn more about Teams in our documentation.
Teams are also available through the API using the Team and TeamMember APIs.
Since we were busy building Teams, we tackled another important feature request: Language Coordinators.
A language coordinator is a person on a project who has the same permissions as a translator, but also has the permission to add or remove translators in his language on a Team or Project. This is useful for translating projects with very large teams.
You can learn more about the role of Language Coordinators and other roles in WebTranslateIt in our documentation.
We hope you will find these improvements useful. Thank you for using WebTranslateIt.
By Edouard on March 24, 2017
If you are using machine translation from Bing Translator, please note that Microsoft is deprecating its current Microsoft Translator API found on the Azure DataMarket in favor of a new Microsoft Translator Text API that you can find on the Azure Portal.
Starting on March 31st, the legacy Translator API won’t serve translations anymore. It means that in order to keep using translation suggestions from Microsoft Translator you will need to sign up to the Azure Portal and get a new API token. Old tokens aren’t compatible with the legacy implementation of Microsoft Azure Translator.
We released an update to WebTranslateIt to support the new Microsoft Translator API, so you can now use the new Microsoft Azure Translator credentials delivered on the Azure Portal with WebTranslateIt.
First, head over to WebTranslateIt’s documentation on Machine Translation to learn how to get your new Microsoft Azure Translator API credentials.
Once you have your new key, go to your project settings and paste it to the Microsoft Translator API field and that should be it.
Should you have any questions, please visit the support site and we will get right back to you.
By Edouard on February 22, 2017
Here are 8 tiny but useful features we’ve been releasing over the past few months.
Project managers can now upload project icons to differentiate their different projects.
In order to upload a new icon, just go to the project settings and upload it next to the “Icon” title.
You can now filter segments by multiple labels in the translation interface.
This is an advanced feature, so we don’t have an UI for it, so you will have to edit the URL to use this.
For instance, if you’d like to filter by the label label 1 and label 2, you’d need to use this link: https://webtranslateit.com/en/projects/406-WebTranslateIt/locales/en..en/strings?label=[label+1,label+2]
If you’d like to only show segments not having any labels it is now possible to do so. Click on “Filters” » “Labels” and select “None”.
We also added a new filter to let you display only segments having instructions or those not having instructions. This will make it easier for you to specifically list segments needing some commenting. Adding instructions greatly helps translators doing their work.
Autoscroll is a new translation feature. In the translation interface having Autoscroll on moves the translation box to the top of the screen to make room to list the translation suggestions.
This new feature is turned on by default but you can turn it off in your personal settings.
We improved our WebHooks a lot. First of all, we now log the output of each WebHook call and you can review it in your project settings. It will be useful to determine why a WebHook hasn’t been working.
We also improved the WebHook payload so if you use the WebHook feature to post to Slack it will now display a message detailing the changes. More improvements and a tighter Slack integration are in the pipeline.
That’s it for today. I hope you will find these new features useful. Thank you for using WebTranslateIt.
By Edouard on February 13, 2017
You can now translate Apple .stringsdict files with WebTranslateIt.
.stringsdict files are files used for iPhone applications to define language plural forms.
Here’s an Apple .stringsdict file example:
<plist version="1.0">
<dict>
<key>files</key>
<dict>
<key>NSStringFormatSpecTypeKey</key>
<string>NSStringPluralRuleType</string>
<key>NSStringFormatValueTypeKey</key>
<string>d</string>
<key>one</key>
<string>%d file remaining</string>
<key>other</key>
<string>%d files remaining</string>
</dict>
</dict>
</plist>
We hope you will find this new file format useful. It was the file format the most requested so far. Thank you for using WebTranslateIt.
By Edouard on February 13, 2017
You can now translate react-intl JavaScript files with WebTranslateIt.
react-intl files are JSON files which are parsed in a specific way by WebTranslateIt. Descriptions will be extracted out and displayed as a developer instructions.
{
"key.confirmation.title": {
"description": "{variable} Title for that dialog",
"message": "Hello"
}
}
We hope you will find this new file format useful. Thank you for using WebTranslateIt.
By Edouard on February 13, 2017
In the past few months we have been working on improvements to the Translation Memory on WebTranslateIt. Here’s what’s new.
We improved the design of the translation suggestions coming from the Translation Memory or Machine Translation. It should now be clearer to see where the results come from. We also added the date this suggestion was translated. Moreover, if the results comes from your own Translation Memory (as opposed to the Global Translation Memory) you should also see the author’s name.
Listing all suggestions
Selecting a suggestion highlights it in yellow.
We also reworked the algorithm used to fetch translation suggestions. The new algorithm should be much better at finding Complete Matches and at finding suggestions for very short sentences or for segments containing code.
It also means that the Complete Matches Batch Operations should be working much better now too.
We hope you will find these improvements useful. Thank you for using WebTranslateIt.