Starting from today, we’re launching a new blog entirely dedicated to Amanuens. It is located at http://blog.amanuens.com.
We’ll keep posting occasional updates regarding Threeplicate here, but all content about Amanuens will go to the new shiny location.
Oh, and don’t forget about the ScrewTurn Wiki Blog!
Starting from today, Amanuens allows you to manually upload and download files without the need to connect to your source code repository.
Using the Stand-alone File Repository, as we call it, is very easy. Just launch the new Project Creation Wizard from your account Dashboard, and select “No” when it asks if you want to connect to a source code repository.
The new Stand-alone File Repository allows you to:
Apart from being managed by Amanuens, the repository works 100% like a regular source code repository. Actually, it’s a plain Subversion 1.6 repo, so we might even make more versioning and diffing features available in the future.
We think that the Stand-alone File Repository is very useful when you want to try Amanuens without having to configure a connection to your repository, but still getting 100% of the platform functionality and workflow management. We’re still convinced that connecting to your repo saves you lots of overhead, but after all zipping all your resource files and uploading them isn’t that complex either.
What do you think about this new feature?
A few days ago Google announced that the Translate API will be shutdown this December. All hell broke loose.
My take on this decision is that it will change exactly nothing, and the reason is that Google Translate is quite poor in terms of translation quality. Since when we integrated Amanuens with the Translate API, I started getting quite upset at the quality of translations. I’ll make an example. The source text is:
Warning: this Page is being edited by another user
Google Translate comes up with (in Italian):
Attenzione: questa pagina viene modificato da un altro utente
Not only the translation sounds weird in Italian, but it’s even wrong as “modificato” is masculine, while “pagina” (page) is feminine.
Sure, Google Translate is great if you have a piece of text in a language you don’t understand and you need to get a grasp of its meaning, but using it for translating text for production is just plain dumb. I also believe that using Google Translate to get a first draft of a translation is not a good idea because, oftentimes, it’s harder to fix an existing translation rather than writing it from scratch. Taking the example above, the translator should just fix one word, assuming she spots the error, (“modificato” -> “modificata”) – yet the sentence still sounds weird and should be rewritten from scratch.
So, for very short sentences, Google Translate might work well (e.g. “Save document”), but for those we already have pretty powerful translation memory technologies. So, Translate becomes useless even in this case.
For all these reasons, although shutting the API down is a bit lame, I think that that decision will not affect the translation and localization industry at all. Possibly, it will give us back the feeling that professional translators are extremely valuable, even for often-undervalued software localization jobs.
We’re announcing today that Amanuens will be completely free at least until December 31st, 2011. I’m sure the rationale behind this decision requires a bit of explanation.
We see that there are quite a few web-based platforms for people involved in software localization, which is great (competition is always great). Each platform has its strengths and its weaknesses, including Amanuens, however all platforms are increasingly focusing on one major theme: collaboration.
Improving collaboration is one of the main goals Amanuens has, so that theme is fully welcome here. But to really get collaboration to a new level, we first have to fully understand it. And what is the best way to understand it? Involve many users.
Our current business model is holding us back. It’s preventing us to drive Amanuens to the next level. We want to focus on building the best software localization platform on the market, and we really need many people involved in the journey, and best way to do that is giving free access to our platform.
We’ll stop charging existing customers starting this night. Remaining account balance will be preserved and can be used to purchase professional translations.
One of the first thing we should take into account when internationalizing an application is how to handle complex localizable strings. This is particularly important in web applications, where text is usually interleaved with links or other markup, for example:
When you are done, click on the <b>Save All</b> button to save your changes.
It’s tempting to assume that including markup in resource files is bad, so we split the string in three pieces, like this:
When you are done, click on the Save All button to save your changes.
Those pieces would be assembled at runtime, adding the appropriate <b> and </b> tags.
The problem with this approach is that we are assuming that, in each language, the pieces would still make sense after assembling them (or that the translator would be able to figure out what the pieces mean at all). This is one of the most common mistakes we could do when internationalizing an application.
In the example above, however, we could simply leave the markup in the string and have the translator figure out what to do with it. If you’re using Amanuens, then you don’t have to worry because the editor assists the translator when strings contain markup.
At Threeplicate we use another way to handle the same string, or a more complex one (BTW, Amanuens is still available only English, but it’s fully internationalized). Lets use this example:
<b>Note</b>: before committing changes, you should <a href="dynamic URL" title="Go to translation synchronization" class="navigation active">synchronize</a> the translation.
In this case the <b> and </b> tags are the least of our problems. As you can see, there is a link whose URL can only be determined at runtime that makes things much more difficult.
The obvious solution would be to use a placeholder to inject the correct URL at runtime. In my opinion, that is a sub-optimal solution, for a number of reasons (see below).
Instead, we can store the string in 3 pieces, but with a rationale:
<b>Note</b>: before committing changes, you should {0} the translation. // {0} = "synchronize"
synchronize // As in "you should synchronize the translation"
Go to translation synchronization
We specify in the comments (or translator instructions) that {0}** is a placeholder for “synchronize” and how “synchronize” is used. At runtime, we replace {0} with a working link (whose URL is determined according to application’s logic and whose title is pulled from resource files as-is), regardless of where the placeholder is.
This approach gives us 4 benefits over the URL-placeholder solution:
Your turn. Tell us what you do in similar cases!
* Better and not Best because there surely are other options. It’s just that this one works quite well for us.
** I’m using {0} in this example because it’s the placeholder format used by the string.Format method in .NET – you can use any type of placeholder. Remember that Amanuens assists the translator with placeholders too, not just with HTML markup!
Quite a few of you asked whether we have an API to push and pull files. Most of our competitors do, so it’s a perfectly legit question.
The answer is no, we don’t have an API, and there’s a good reason: there’s no need for it.
The rationale behind this is that you already have an API on your side, and it’s called SCM or VCS or source control. It’s an API that works spectacularly well, designed exactly for storing files and managing their subsequent revisions. But above all, it’s already there, waiting for you and us to exploit it.
There’s an important mental shift here: a custom API requires you to spend time and effort to (try to) integrate your tools with it. It does not make your life simpler (quite the opposite actually). We strongly believe that it’s our duty to integrate with the tools you already use, rather than forcing the other way round on you.
I have to admit that I wish we simply had an API, because programmatically exchanging data with Subversion, Mercurial, Git and Microsoft Team Foundation Server is far from being simple (proof is that we sometimes have problems), but ask yourself why you should spend time writing convoluted sync scripts when you can simply configure a connection to your repository and let us figure everything out. After all, we’re all used to source control and we understand how it works. Above all, source control acts as a safety net when things go awry. Why reinvent the wheel, introduce more bugs, generate more work when we can simply use what we already have at our disposal?
The obvious problem about this approach is privacy and IP protection. I perfectly understand this concern, and I can say that keeping everything as secure as possible is our top priority (that’s one of the reasons why Amanuens runs on the Windows Azure Platform). We still have access to your source code repository, but rest assured that we never, ever store anything other than resource files, and we’re open to sign NDAs if you like (just drop us a line).
From a broader point of view, we’re quite happy that more and more companies are migrating their in-house repositories to project hosting services, because it means that people are becoming increasingly aware of the advantages of the cloud. For example, at Threeplicate we don’t have anything stored locally and the only non-dev machine we have is our continuous integration server – only because we can’t purchase it as a cloud service!
All of that said, we might offer an API in the future, but that is not our top priority at this moment because – remember – we already have an API and it rocks!
As always, your thoughts and opinions are welcome.
Just a quick note to announce a small yet useful new feature of Amanuens.
When assigning a new translation, or when adding files to an existing one, you can now specify how to treat translated strings found in the repository. The two obvious choices are to mark all strings as either translated or untranslated. That’s easy, although it was not possible before today.
The most interesting option instructs Amanuens to analyze every string and figure out whether it’s already translated or not. It’s an heuristic algorithm that might be inaccurate, but I believe it’s a good triaging tool. Don’t forget you can manually mark individual strings as translated or untranslated at any time.
Just a quick notice to let all translators know that the Amanuens editor now sports a new cool feature: markup highlighting.
How does it work? It’s very simple: all markup and placeholders included in source text are highlighted so it’s easier to spot them and make sure they’re preserved in translated content. This currently works for:
The editor also warns you if the translated text does not contain the same markup elements found in the source. Order is not considered as obviously translated sentences might be constructed differently.
BTW, if you haven’t noticed it yet, the editor now suggests you translations via Google Translate. Learn more on how to enable the feature.
As usual, don’t hesitate to send your comments and suggestions.
During the last few months we’ve been working in the background to build a new translation editor from scratch. Many of you said the old one was a bit… overwhelming and in fact the table-like structure was far from perfect. The ideas that led to the new editor, which we’re happy to release today, are:
I mentioned keyboard shortcuts and here is the complete list:
Keyboard shortcuts have been designed so you can translate an entire file from start to finish without ever touching your mouse. This is true also because when you open a string, the editor automatically selects the translated text so you can start typing right away. Also, when you open a new string, the previous one is saved automatically.
If you want to learn more about the new editor, have a look at its manual in our new support portal. As usual, don’t hesitate to send feedback and comments.
It’s been a long and hard journey, but I’m now very, very happy to announce that as of today, Amanuens integrates a professional translation service, provided by our partner Virtual Words Translations.
We’re giving you the best of two worlds: advanced, developer-friendly software localization management infrastructure, and professional translations. It’s like a having a team of hand-picked translators without the hassle of managing them. Offering a library of more than 50 languages, the guys at Virtual Words are experts in localization projects and they have clients like Comcast and NCR.
It’s very simple. Instead of assigning a translation to one of your translators, you assign it to Virtual Words. You’ll be presented with a simple wizard allowing you to checkout files from version control and to view a quote for the job. We’re very fond of translation quality, so we offer a couple of value-added services that you’ll surely find interesting.
Firstly, you can tell Amanuens that your project refers to one of our many supported expertise fields, ranging from Medicine to Politics. This will surely give you the best translation result, no matter the industry you build software for.
Secondly, you can opt to purchase, for a small additional fee, a proofreading pass (a.k.a. review) that will be performed by a second translator once the first one has finished translating the content. This optional service also gives you the right to request amendments to individual translated strings, should you find them unsatisfying.
An important aspect of the new service is that you can mix your own translators with our professional service as you like without any limitation. You could even split a translation and purchase the most complex parts from us, while doing the rest internally. It’s really up to you.
To learn more about integrated translations, simply visit Amanuens.com (renewed for the occasion) and keep in mind that you can view quotes for any translation job for free and in quasi-real-time (you just have to checkout from version control), right from your Amanuens account (sign up here for free).
But there’s more… we also added quite a few new features that will benefit anyone, regardless of whether they use the integrated translation service or not.
We introduced support for GetText-style resource files. It’s preliminary because, well, .po files are quite convoluted. So far we support .po files only if they refer to a .pot master (which is not exactly common, but easier for us to manage). We plan to add more flexibility as soon as we get users feedback.
Administrators can now add instructions for translators, bound to individual strings in a translation. This helps if a piece of text requires special attention or has particular constraints. Mind you, this feature is totally independent from comments usually found in resource files, as those are not even supported by all formats.
To provide even better control over the status of translations, Amanuens now handles the “completion” status of individual strings, providing more accurate global status information. Administrators can also mark individual strings as “not completed”, thus automatically pushing them to the translation’s attention.
So, head over your Amanuens account and explore the new service and features. And don’t forget to send feedback!
Copyright ©2010-2012 Threeplicate Srl. All rights reserved. Microsoft and BizSpark are trademarks of the Microsoft group of companies.
New Posts