The WebTranslateIt Blog · Page 14

The translation interface in Web Translate It just got a bit more flexible.

You now can choose the locale to display to the left side. It means you can translate a software from Nepali to English first, and then translate it from English to other languages.

For instance, here we translate from English to French.

We can also choose to translate from French to Russian. It’s really easy: just select the language on the left side.

We could also translate from Russian to Portuguese. Any combination of locale is possible.

I hope you will find this new feature useful. Thank you for using Web Translate It.

3 new language file formats have been added to Web Translate It:

• JSON can be used to localise Javascript,
• Java .xml, an alternative to Java .properties files,
• and Qt .ts files, used to localise Qt applications. Web Translate It support both .ts 1.0 and .ts 2.0, which includes support for plural forms.

I just released a new feature on I have been working on since a little while: labels.

Many Web Translate It users have been requesting the ability to assign priorities to strings (translate these ones first), or assign jobs to people, or flag a string as typo’d. Labels will allow you to do all that.

It is dead simple to use.

Click on the options button, hover “Add a label”, and click “New label”.

A modal window will appear and let you type the name of your label. For the sake of this example, let’s name it “prime”. “Prime” strings will be the strings I want my translators to translate first.

All good! Now the string has the label “prime”. You can add as many labels as you want.

Adding more “prime” strings is now really quick and easy. Just select “prime” in the list!

Of course, you can filter your strings by label.

Please note that labels is a feature specific to Web Translate It to help you optimise your translation workflow. Just like string statuses or comments ownership, we cannot export this information in your language files.

Enhancements will be made to this feature in the upcoming weeks, right off the bat:

• Ability to assign a label when importing a file, to label strings that added in a release and monitor their translation progress,
• Ability to assign a colour to a label,
• Batch operation to label several strings at once.

I hope you will find labels useful, thank you for using Web Translate It.

Web Translate It went down today around 8AM GMT+1, for about 40 minutes. No data was lost and the service is now back up.

It appears to have been caused by a lack of memory. I took the advantage of the downtime to add more memory to the slice.

I am still investigating on this issue and I will do my possible to make sure it doesn’t happen again.

I am very sorry for any and all problems this has caused.

This minor update handles timeouts more gracefully and complains if the files can’t be saved.

To install this update: gem install web_translate_it.

New features, enhancements and support for 2 new file formats (for Google Android and Blackberry) have been added to Web Translate It.

New feature: Instructions

The Gettext language file format has something great called “developer comments”. In Web Translate It, these developer comments are displayed in the translation interface, on top of the strings to translate.

This is very convenient for developers to give important instructions, and for translators to read these instructions without having to click anywhere.

I just extended this feature to all file formats. Managers can now create or update instructions from the translation interface.

How does it work? Managers will notice a new “pin” icon. Click the pin icon to open a new modal window.

Write your instruction under 140 characters. The message has to be short so it is fast to read and doesn’t clutter the interface. The message can be formatted in Markdown, so you can paste there URLs to your staging site for example.

That’s it! The message is now displayed in the translation interface to all users.

You can also attach as many images and documents as you like.

Attachments appear in the translation interface. Users can click their icons and see the actual file.

The instruction feature is not a replacement for the commenting feature. It’s great to notify translators of the common pitfalls or give them context, because you are sure they will see it. On the other hand, comments are better to ask questions when something is unclear.

Clickable key name

In the translation interface, clicking on the key name now brings you to the string history.

Enhanced timeline

I added a few new useful events, and hid some others. It makes the timeline useful for reviewing translations.

When you upload a new language file and if it contains new strings, it will now be displayed in the timeline to inform the team. It also displays whether the file was uploaded through the web interface or the API.

Every 2 hours, a job collect all the translation activity for your project, and post a summary it in the project timeline.

When you click on “View strings”, you will see exactly what strings have been edited during these 2 hours. Changes in translations of a string are now displayed in a diff view that facilitates reviewing.

Support for Google Android and Blackberry language files

Web Translate It now support language files for Google Android and Blackberry devices. We now support 13 file formats:

• Gettext .pot/.po,
• Ruby .yml,
• Java .properties,
• Microsoft .resx (.net),
• Microsoft .aspx,
• PHP .ini,
• Apple .strings,
• Android .xml,
• Blackberry .rrc
• HTML/XHTML
• Markdown .md, .markdown
• Textile .textile
• Plain text .txt

Support for duplicated keys

Until now, keys had to be unique throughout the whole project. I changed this so you can now have duplicated keys in your project, so long they are unique for each file. It means you can have a key named “title” in one file, and another key named “title” in another file, under the same project.

Better support for file encodings

• Until now, you could only upload language files encoded in UTF-8. When you upload a file not encoded in UTF-8, Web Translate It will attempt to detect your file encoding, and convert it to UTF-8.
• Apple .strings files generated are now served encoded in UTF-16 (Little Endian). This is a requirement for all Apple software.

That’s about it! I hope you will like these improvements. Thank you for using Web Translate It!

Web Translate It is down since 18.50 CET. The datacenter where Web Translate It is hosted is experiencing connectivity issues, and engineers are currently working to restore service.

I sincerely apologise for the inconvenience. I will post updates on Twitter and let you know as soon as the service is restored.

Update 20.00 CET: Connectivity appears to be restored, the site is back up.

I released Wednesday a new version of the web_translate_it rubygem. This update brings one new feature: the synchronisation console.

Introducing the Synchronisation Console

After installing the rubygem (gem install web_translate_it), go to your project directory and run:

wti server

It will start a server on the port 4000. Then, go over to http://localhost:4000 with your web browser and access the synchronisation console. It’s that easy!

The synchronisation console displays all your language files, and whether or not they have been committed to your repository (it only works if you use git) and if a new version of your language file is available on Web Translate it. You can also download the latest version of your language files by just clicking a button.

What is it for?

A translation team works on translating your application. Every time translators want to test their work in your application (to see if a translation fits or doesn’t break your app, for example) they have to ask a developer to pull the translation files from Web Translate It. Using this tool, they can now do it by themselves.

Setup wti server on a staging website, give your translation team access to both the staging site and the synchronisation console and you have an almost effortless way to increase the quality of your translations.

Advanced Usage

I made this tool very extensible. You can choose the host name and the port you want to start the server on. You can also setup hooks in the configuration file, so you can for example restart the application server after refreshing the language files, and regenerate the site if you work a static site.

To learn more about this, please refer to the tool documentation.

All credit goes to Tom Lea from Reevoo.com for his excellent rack-webtranslateit. I pinched his idea and made it less specific to ruby projects, so it can be used for pretty much any kind of application.

Web Translate It now support a bunch of new file formats:

• HTML/XHTML,
• Microsoft .aspx, which really is decorated HTML,
• Markdown (.md, .markdown),
• Textile (.textile)

So we now support a grand total of 10 different file formats. That’s plenty!

• Gettext .pot/.po,
• Ruby .yml,
• Java .properties,
• Microsoft .resx (.net),
• Microsoft .aspx,
• PHP .ini,
• Apple .strings,
• Markdown .md, .markdown
• Textile .textile
• Plain text .txt

Do you need another language file format we don’t support? Let us know on our support forum, and we’ll implement it within days.

I just added a new endpoint to Web Translate It’s API: Create File. This endpoint will allow you to send to Web Translate It new master language files through the API.

This endpoint’s usage is explained in the documentation.

The rubygem has been updated to take advantage of this new endpoint. With the new version 1.6.7 you can now do:

wti add path/to/master_file_to_add

This will send this new master language file to Web Translate It. Note that is should only be used to send new master language files that are not already on Web Translate It.

Updating an existing master or target language file should be done using the usual wti push command.

More improvements are planned for the rubygem, such as the ability to send several files at the same time, or the ability to the language files you have locally that are not sent to Web Translate It.

I hope you will find this new endpoint useful.

If you use Web Translate It extensively you might have noticed a few error pages yesterday, when loading pages or saving strings.

The reason of these errors is that the database server is sometimes overloaded and crashes at peak time.

I take this problem very seriously, and in fact I think most of the issues are now fixed. I tuned the database server, pushed some important optimisations that will make the service much more reliable than yesterday. I will carry on working on optimising the service today.

Tonight I will also upgrade Web Translate It’s hardware, which will require to reboot the server. Rebooting the server should take less than 5 minutes, and the service should be completely operational a few minutes after that. Therefore I reserve a window of 20 minutes downtime tonight from 9PM to 9.20PM GMT+1.

I apologise for the short notice and for the inconvenience this downtime will cause, but this downtime will be very short and make the service a lot more reliable.

EDIT: The maintenance went well. The service was down for about 4 minutes, according to Pingdom, and it took another 5 minutes to restart the workers and search engine before the service was 100%.

I upgraded Web Translate It’s slice memory from 1.2GB to 1.5GB, and I increased the database cache. Some indexes were corrupted due to the crashing, so I also rebuilt the indexes.

Here’s a tiny improvement to help you translate better complex strings.

Non-obvious white spaces are now indicated by tiny blue dashes. By non-obvious spaces I mean:

• Space or spaces preceding a string

• Space or spaces suffixing a string

• Two or more consecutive spaces in a sentence.

In software, extra spaces are often here for a reason, and it is important for the translations to have them, too.

When you hover the string, spaces highlight, so you won’t miss them.

And finally, these highlighted spaces are really spaces, so you can select, copy and paste them as usual.

Managers will find a new feature on Web Translate It’s translation interface: batch operations. This is a very powerful feature.

What does it do?

Batch operations apply a specific action on a batch of strings you selected.

To use it, start by listing the strings you want to modify, using the filters by categories, files, date, status… When you’re happy with your list of strings, click on « batch operations », and choose one of the 6 operations available.

• Proofread— proofread all the translated strings listed on the page.
• Unproofread— unproofread all the translated strings listed on the page.
• Copy text from source— copy the source text to the target strings, and flag these strings as “to verify”, so you can find them and translate them later. I think many WTI users will find this useful: a lot of Web Translate It users want to download their language files including source strings when translations are missing. You now can do it.
• Populate— populate your translations with machine translations from, and flag your populated strings as “to verify”. It’s great for developers to quickly have a full language file to test their app, but really the translations often leave to be desired and have to be verified by a translator.
• “Untranslate”— clean all your strings from their translations. Perfect to start over a translation.
• Delete— delete all the strings listed.

Operations run in the background, so you can leave the page or close your web browser while it is running.

This feature has been designed to be as flexible and powerful as possible. These operations might overwrite your strings. For example, if you choose “populate” on all your strings, even the translated strings will be replaced by machine translations, which may or may not be what you want to do. We leave it up to you to refine your selection to for example, the untranslated strings.

With these 6 batch operations, Web Translate It now can really fit any kind of translation workflow.

Other improvements

• new lines and spaces are now preserved when displaying source and target strings in the translation interface. Useful when translating code.

• Very long strings now wrap and don’t break the layout.

• Animations when editing a string have been removed. Editing a string is much faster now.
• Support for 2 new file formats: Markdown (.md, .markdown) and Textile (.textile). We also extract strings to translate from HTML/XHTML files but this is still very experimental. This is great to translate user documentation.

For example, Web Translate It’s documentation, which is a mix of HTML and Markdown files, is translated with Web Translate It.

More tiny improvements are to be announced this week. Subscribe to this blog’s RSS feed or follow us on Twitter to keep up to date!

When you update a language file on Web Translate It, you will notice two new options:

• Overwrite existing strings,
• Flag missing keys as obsolete.

What does it mean?

These options control the importer’s behaviour when uploading a new language file. These are advanced options and you should only use them if you know what you are doing.

Overwrite existing strings

Let’s consider you have a project in which the source language is English, to translate into French and Italian. The project has these 2 strings already in Web Translate It’s database.

greetings: "hllo {{user}}"
welcome: "Wellcome"

These strings have been written by your developers, contain spelling mistakes, and are considered as placeholders. You want to update these strings from the web interface, so you just add the English language to Web Translate It, and edit these strings directly. Job done! You now have:

greetings: "hello {{user}}"
welcome: "Welcome"

That’s more like it.

Now bad news: the developer has decided to update his language file, which add one more string. The importer does a complete sync and therefore, overwrite your changes and flag all the existing translations as “to verify”. The strings in database are now:

greetings: "hllo {{user}}"
welcome: "Wellcome"
sorry: "Im not so good in Engrish"

So basically all your good work went to waste! Something is wrong, what can you do? The new overwrite option will help you with this problem.

Let’s go back to step 2 where you had:

greetings: "hello {{user}}"
welcome: "Welcome"

Now the developer upload a new language file containing the new additional string, and untick the checkbox “Overwrite existing strings”. Before doing any update, Web Translate It will now check whether this string already exist in database or not. If the string exist, WTI won’t alter it and therefore your changes are safe. You’ll now have in database your nice changes, plus a new string to proofread:

greetings: "hello {{user}}"
welcome: "Welcome"
sorry: "Im not so good in Engrish"

And you can fix the last string from the web interface:

greetings: "hello {{user}}"
welcome: "Welcome"
sorry: "I’m certainly not so good in English, but others can proofread!"

This will be really useful for you if your workflow include proofreading the source string.

Flag missing keys as obsolete

This second option is more straightforward. Let’s consider the same project than above. You have these strings in database:

greetings: "hello {{user}}"
welcome: "Welcome"
sorry: "I’m certainly not so good in English, but others can proofread!"

Now, the developer upload a file containing:

greetings: "hello {{user}}"
welcome: "Welcome"
funny_joke: "This last string should be replaced by a funny joke by the proofreader"

By default, the importer will flag the string “sorry” as “obsolete”, because it has been removed from the file and should not be translated. Additionaly, the new string “funny_joke” has been added.

But what if you never want to remove strings? You now can, by unticking this box. Instead of the above you would have get:

greetings: "hello {{user}}"
welcome: "Welcome"
sorry: "I’m certainly not so good in English, but others can proofread!"
funny_joke: "This last string should be replaced by a funny joke by the proofreader"

These two options can be combined, so it covers pretty much any kind of workflow. This is a very powerful feature.

API

This feature is accessible via the web interface, and also the Update File API endpoint. Optional parameters can now be passed:

• merge=true, to disable overwriting strings (default is false)
• ignore_missing=true, to disable obsoleting strings (default is false).

If you use the API without these parameters the importers will overwrite and obsolete strings as usual.

Web Translate It gem

The web_translate_it gem has been updated and the new version 1.6.6 now propose 2 new options:

• --merge to force WTI to perform a merge of this file with its database.
• --ignore_missing to force WTI to not obsolete missing strings.

You can use these options this way:

$ wti push --merge
$ wti push --ignore_missing

Or you can also combine them:

$ wti push --merge --ignore_missing

To update the web_translate_it rubygem to the latest version: gem install web_translate_it.

I hope you will find this feature useful. Web Translate It can now adapt to pretty much any kind of translation workflow!

Web Translate It now support 2 new file formats:

• Microsoft .net resource files (.resx),
• Plain text files.

These 2 new file formats extend our existing collection of Gettext .po/.pot, ruby .yml, Apple .strings, Java .properties and PHP .ini.

I am also working on HTML/XHTML file support, which will be great to translate static websites or documentation.

So far, the most popular file formats on the projects hosted on Web Translate It are Gettext and ruby .yml, but Java .properties is growing fast!

Do you need another language file format we don’t support? Let us know on our support forum, and we’ll implement it within days.

We’ll have a short maintenance window tonight at 8PM GMT+1 to account for the database problems we had today. I expect the downtime to be no longer than 5 minutes. I apologise for the short notice and the inconvenience it will cause.

Edit 20.07: Maintenance done. I also used this maintenance window to run a few optimisation scripts.

I just launched a new user documentation website for Web Translate It. It now lives at docs.webtranslateit.com.

This documentation is more organised and detailed, with explanations, screenshots and sometimes screencasts for every single feature of Web Translate It.

Have a look at the documentation page for the translation interface. Maybe you missed a feature that would make you life easier?

I will translate the documentation into French shortly.

---

For the nitty-gritty details, the documentation website is made with the help of Jekyll, a fantastic tool to create any kind of static website.

The source code of this documentation website is on Github.

Now the File API is faster than ever, you should totally try out auto-fetch.

Auto-fetch allow you to automatically update your language files on your application when you refresh a page on your development or staging website (this is not suitable for production environment). Invite your translation team to access a staging website and they will be able to test their translations in context. Being able to test translations moments after having translated is an easy way to dramatically improve your translation’s quality.

If you have 2m30s to spare, watch this quick introductory video and you will immediately grok why and how it can help.

Introduction to “auto-fetch” from Édouard Brière on Vimeo.

(or watch it in HD at Vimeo)

If you are looking for manual synchronisation, but still want to allow your translators to refresh the language files without the help of developers, Tom Lea from Reevoo.com also made a great open-source tool to download the latest translation from Web Translate It by just clicking a button: rack-webtranslateit.

You should definitely check it out if you don’t like to connect to Web Translate It for every page requested.

We encourage you to use and abuse of Web Translate It’s API, and to build great tools on top of it.

When I started working on Web Translate It, I thought handling locales would be a piece of cake. Wrong I was.

Web Translate It’s locale builder knows in which countries a language is spoken, which scripts are used for which language, and really helps you creating locales that make sense. It also knows about the plural rules for most languages, which help translating sentences with plurals forms.

In the past two weeks I made two micro-improvements to the locale builder that worth mentioning: hyphened locale codes and default scripts.

Hyphened locale codes

Until two weeks ago locales using subtags used to look like so:

en_US
en_GB
fr_FR
pt_PT
pt_PT_Latn
ar_Arab
zh_Hans
...

These locale codes don’t comply to the IETF language tags, which suggests locales subtags should be separated by hyphens instead of underscores:

en-US
en-GB
fr-FR
pt-PT
pt-PT-Latn
ar-Arab
zh-Hans
...

The API endpoints have been updated and recognise both hyphened and underscored locales, so it is not much of a big deal, unless you use Ruby YAML with language subtags, in which case the root key has changed.

So, instead of getting:

zh_CN:
  contact: 联系

You will get:

zh-CN:
   contact: 联系

Of course, nothing has changed if you don’t use the country subtag for your locales. Hyphens really are a preferred syntax, and Ruby on Rails also use hyphened locale subtags.

Default scripts

One language can be written into different scripts. Some languages’ scripts depend on the country the language is spoken. For example, Chinese is written in Simplified Han in China, but in Traditional Han in Taiwan.

Another example: Kashmiri, spoken in India and Pakistan, can be written in Arabic, Devanagari or Latin.

So the big question when you just select “Chinese” or “Kashmiri” in Web Translate It is: which one do you mean?

Knowing the script is important for Web Translate It, because it relies heavily on the script you use for two important features: the translation memory and handling right-to-left scripts in the translation interface.

To fix these issues I set up a default, invisible script for all locales. When you choose Chinese (zh) it will assume you want to use zh-Hans (Simplified Chinese). When you choose zh-TW (Chinese, Taiwan) it will assume you want to use zh-TW-Hant (Chinese, Taiwan, Traditional Han). If you use ar (Arabic) it will assume you mean ar-Arab (Arabic, Arabic), etc.

These default locales also allow us to “fold” the locales by language and script to serve more relevant suggestions. For example, if you chose fr-FR (French, France), it will fold the locale and look up for fr-Latn, which extends the results to locales such as fr-CA, fr-BE, etc. This is now used for searching suggestions in the global translation memory.

Last week I introduced a new feature for Gettext users: automatic strings grouping by category.

This feature is now available to Ruby YAML users. Users will have to re-upload their language files as categories are only added during the file import procedure.

(try it yourself on the translation project for Web Translate It)

The categories are based on the flattened keys. Technically speaking, categories are subkeys of depth 1, but only if the key group other keys.

For instance this YAML file:

en:
  hello: "Bonjour {{user}}"
  greetings:
    informal: Salut
    formal: Bonjour

will only create one category: greetings. I made experimentations and this depth gives better result. Using deeper keys give more precise results but then the category list is too long to be any useful.

The next step will be to add this feature to Java .properties files. Thank you for using Web Translate It!