We’ve just finished post-producing a new quickstart video demo. As usual, it’s hosted on YouTube.

Big thanks to Massimo for the voice-over.

At Amanuens we believe that building a great localization platform is the key to make the process as efficient as possible. We also believe that, while providing the platform is enough for some, there’s still something missing. For that reason last year we announced a partnership with Virtual Words Translations, to give you the ability to not only manage the localization process, but to also purchase translations right from within Amanuens with minimal effort.

Today we’re very thrilled to announce three new translation partners:

Thanks to these agencies, we’re now able to offer translations in more than 90 languages with prices starting at €0.10 per word. Our partners cover a wide range of expertise fields and are specialized in software localization, so we are sure you’ll get excellent results.

Ruby on Rails has become a very widely-used platform for building web applications quickly but without losing control of the details of web development. RoR has strong focus on convention over configuration and makes it very easy to build databased-driven web apps without delving too much into database development.

We’re very happy to announces that we just introduced experimental support for .yml resource files used in RoR.

I’ve said experimental because the YAML format is used pretty much only in RoR, or anyway in conjunction with Ruby, so we lack robust libraries to manipulate it. Our implementation should work fine, but with the following caveats:

• we only support .yml files (and not .rb)
• we only support files encoded in UTF-8, with or without BOM
• we only support single-document files
• we do not support associative arrays
• lists can only contain simple items (strings, typically), and not complex objects
• the objectName: ! 'string content' tag syntax is not supported and will be silently treated and output as objectName: 'string content'
• output files are completely reformatted without comments and with arrays turned into lists (string order is preserved though).

All such limitations derive from the YAML library we use and at this moment we cannot change them.

We support the following file naming patterns, regardless of the folder path:

• <language-code>.yml
• <prefix>.<language-code>.yml

<language-code> is typically a two-letter language code, optionally followed by the country code (for example en or en-US). <prefix> is an optional arbitrary prefix.

That’s it folks! Don’t be shy and let us know what you think in the comments, especially since we’re no RoR gurus and we might have got something wrong.

A percentage value is of immediate comprehension to everyone, but you have to first read it. When you have multiple figures scattered across your screen, things quickly get out of hand.

For that reason we just released a minor new feature: progress indicators. You’ll find one for the entire account…

… one for each project…

… and one for each translation.

As you can see, their size and color are subtly made less prominent as they go from global- to project- and to translation-level. This helps giving more information without cluttering the screen.

Each user, obviously, sees progress indicators for the translations and projects they have access to.

Enjoy & comment!

Last week Microsoft released the consumer preview of Windows 8. This new version introduces Metro, a brand-new user interface paradigm and style, specifically optimized for touch and inspired from Windows Phone. Metro apps are developed using a new dedicated SDK, which supports a number of programming languages: C#, Visual Basic and C++ are fully supported, but for the first time it’s possible to develop client apps on Windows also using JavaScript.

Metro apps are localized using an approach that is similar to those found in other development platforms, but that is quite different from .NET’s. There are new resource file types (.resw for C# apps, .resjson for JavaScript apps) and a new file naming convention.

We just added support for both .resw and .resjson file types. It’s been relatively easy because .resw are actually .resx files with a different extension, and .resjson files are, as the name suggests, JSON files.

In both cases, the language code is specified in the folder path, for example:

• res/en-US/resources.resw
• res/it-IT/resources.resw

Or:

• res/en-US/resources.resjson
• res/it-IT/resources.resjson

Given that the documentation on MSDN is still under construction, things may change. .resw support in Amanuens is rock-solid, because it’s almost identical to .resx. However, given the weakly-structured nature of JSON, .resjson support might be revised in the future and may present issues. During our tests everything worked perfectly, but don’t hesitate to report any problem you might encounter.

Are you already developing Metro app? Are you planning to? Let us know!

Another small improvement for Amanuens: it now supports plain text files. Plain text files are typically used to store long texts that do not fit in regular resource files. App stores descriptions are a typical example.

Key points:

• support is experimental: use it at your own risk
• due to the unstructured nature of the files, we do not enforce any kind of markup (except what’s below)
• each line in the file, terminated by \r\n or \n, is treated as an individual string (the last line may or may not be terminated by \r\n or \n)
• empty lines are attached to their non-empty neighbors (this allows us to correctly preserve them even if they are added/removed by translators)
• Unix-style new lines (\n, and not \r\n) are preserved throughout the file and across versions, but as soon as a single \r\n sequence is found, the entire file is converted to \r\n
• encoding must be UTF-8, with or without BOM
• extension must be .txt
• language codes can be specified in file names, for example:
• description.en.txt
• description.it.txt
• or in the directory path, for example:
• market/en/description.txt
• market/it/description.txt

Don’t hesitate to let us know what you think about this new feature, and please do report any issue you may have with it.

A few months ago, when Google announced that the Translator API was going to be a paid service, we decided to remove support for it from Amanuens. It has been operational until the end of November, as Google shut the v1 API down on December 1st.

Amanuens now supports the Google Translate API again, but with a main difference: translations are loaded on demand, and not transparently as if they were part of the TM. Google meters API access and translations are priced at $20 per million characters. That’s very inexpensive indeed, but blindly translating all strings would be a waste and an unnecessary cost.

To enable Google Translate for your account, you’ll have to request an API key and save it in Amanuens. Have a look at the support page for detailed instructions. Please note that Google will require a credit card number in order to use the service.

To translate the current string using Google Translate, you just have to click on the appropriate toolbar button, or hit CTRL+G.

Translations will appear right into the TM area. Keep in mind that you can translate a string only once, then the translation is cached.

While Google Translate is very good for quick-and-dirty translations of short sentences, it does not provide what you would normally find in a common dictionary: curated, high-quality definitions and translations. For that reason, we also integrated WordReference.com into the editor. WR is an amazing online dictionary. It’s free and allows you to get translations and definitions of terms. They also offer and API, and we used it to provide terms’ translations right into the Amanuens editor. Use the toolbar button, or hit CTRL+L, to open the Dictionary Lookup tool.

You can manually enter a term to lookup, or select text in the editor and hit CTRL+L to automatically look it up in WordReference.

Enjoy.

A feature that many of  you have been waiting for for a long time is now available: it’s now possible to assign a translation to multiple users, both administrators and translators.

Assigning, or re-assigning a translation is as easy as selecting checkboxes in a list of users.

Key points:

• all drop-down lists, allowing you to select assignees, display the languages each user is able to translate into, given the current project’s master language
• users can now open multiple files in the same translation at once
• each file can be opened by only one user at a time
• translation reports properly reflect the case when multiple users edit the same translation, so results are always correct.

I believe this is one of the greatest improvements we’ve ever made to Amanuens, as it greatly helps translating projects faster, with fewer mistakes and allowing for more organic workload distribution.

Enjoy!