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:

• upload and download individual resource files
• upload and download resource files in ZIP archives
• email a ZIP archive containing all the files in the repository to a recipient of your choice (or to yourself)
• easily manage the repository structure, ensuring that all files are always named correctly (file naming and directory structure are enforced).

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?

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:

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 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.

When you are done, click on the <b>Save All</b> button to save your changes.

The Wrong Way

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.

A Better Way*

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:

1. we are certain that the {0} placeholder is in the right position, regardless of the current language
2. we avoid to store too much markup in resource files (a bold tag is fine, a whole link is perhaps too much)
3. we avoid to include any kind of logic/navigation/semantic in resource files that could easily be broken during translation
4. the translator has context information helping her producing high-quality results.

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!

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.

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.

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:

• HTML and XHTML tags, e.g. <strong></strong>
• HTML (or XML) entities, e.g. &amp;
• C-like string placeholders (used in C/C++, Java and Android), e.g. %d
• .NET string placeholders, e.g. {0}.

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:

• you don’t really have to see the entire file, but instead focus on one string at a time
• having a large-enough, but not too-large text area is important
• keyboard shortcuts boost productivity
• the Search function should be easy and provide no complex options (by default at least)
• items, tools and TM suggestions related to a string should be displayed near that string, not at the top or bottom of the screen.

I mentioned keyboard shortcuts and here is the complete list:

• CTRL+S saves the document
• CTRL+DOWN and CTRL+UP open respectively the next and previous strings in the current file
• CTRL+D marks the current string as translated
• CTRL+K toggles the “starred” status on the current string
• CTRL+F opens the search dialog.

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.

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.

How Does The Service Work?

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.

Preliminary Support for .po/GetText Files

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.

Translator Instructions, New String Status Management

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!