The WebTranslateIt Blog · Page 56

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!

I rolled out an important update to Web Translate It’s File API. The upgrade is transparent to the users, and no changes are necessary on your side. If anything, you will probably only notice that downloading language files is much faster.

Instead of only saving the translations in database and generating language files on the fly, Web Translate It now maintain in parallel a language file, always fresh and ready to be downloaded.

This is so much faster. For instance, if you miss the HTTP cache, downloading a 5,000 strings project used to take 25 seconds. It now takes less than a second.

Web Translate It’s business is growing, and almost all the hosted projects use the API, so it was critical to make the File API work cheaper and faster.

Direct downloads from the File Manager

Now we have these always fresh language files handy you can download your files directly in the File Manager. No more export procedure with the progress bar. It is much easier to use and will save you a few seconds.

I just pushed a new feature to Web Translate It, and removed another one.

RIP Filters

Filters was a feature I introduced 6 months ago. It was a way to group strings by very specific criteria. For example, you could create a filter to group all the strings having the word bacon in their source text, or all the strings having their key starting by users.new. Then the filter would list all the strings matching these criteria. It was a very powerful feature, but it was too much work for the users to setup these filters manually.

Usage statistics show that this filter feature is not are not what users need: out of more than 1,6 million translations on Web Translate It, only 13 filters were created.

Automatic String Grouping

This new feature replaces the filters, and only applies to Gettext users for now. I will extend it to other file formats in the upcoming weeks —at least for Ruby yml, based on the string’s flattened key names.

To use this feature on your project (using the Gettext .pot/.po language file format), all you have to do is to upload a new version of your master language file (categories are only created during the language file import).

Web Translate It now uses the string location metadata that is included for each strings in pretty much all .po/.pot files.

What it means is that the translation interface is now capable of grouping your strings by the file name they were extracted from.

Select the category you want to filter by, and it will display only the strings that belong to that category. It makes it much easier to translate, because it restricts the size of the list of strings.

And, icing on the cake, you will see all the categories a string belong to on the String History page.

If you click on a category, it will bring you back to the translation interface, filtered by that category.

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