September 17th, 2010

As you probably know, Kyero.com is available in 9 languages. Our system allows translators specialising in each of these languages to login to Kyero and translate English text into other languages. more info.

We’re now at one of those Yak-shaving forks in the development road.

We need to upgrade the software framework that Kyero uses from Ruby on Rails 2.0 to 3.0 – and that means that our current translation system will need to be completely rewritten – and all the translations, in every language, carried out again.

There’s a lot of work here – and we got to wondering whether somebody else had already solved these translation problems for Ruby on Rails applications such as Kyero?

If you have, please leave a comment and let us know – perhaps we should be talking?

Equally, if you’re running a Rails application and have similar requirements, let us know – perhaps we can do some joint development?

Martin Dell, Kyero.com

Here’s a PDF with our outline requirements, repeated again below:

Outline requirement for translation software as a service (SaaS)

Overview

Kyero.com is a multi-language real estate portal in Spain. It is a Ruby on Rails application currently being upgraded from Rails 2.0 to Rails 3.0.

As part of the upgrade we need to replace our current legacy translation system and are trying to find a SaaS solution which matches our requirements.

The site is available in nine languages, English, Spanish, French, German, Dutch, Danish, Russian, Portuguese and Italian.

While we currently only run Kyero.com on the technology we’ve developed, our plans are to use it for more than one site. Any solution must be flexible enough to handle this.

The requirements reflect what our current system does, the problems we see with that, and the requirements we think we’ll need over the next few years.

If you have a solution that you think would be a better fit but doesn’t quite match the list below we would be open to considering alternative requirements.

We want to improve our translation quality. Say, for example the English translation uses a variable to specify a property type e.g. beautiful {property_type}. The application will dynamically insert the property type, but the translator will not know what what the content of the variable will be.

In Spanish this causes a problem in translating the word ‘beautiful’ because apartments is masculine and plural, flat is masculine singular and houses is feminine plural.

In French or German, these rules will be different and we are unsure how best to solve this problem. All suggestions would be welcome.

In the following requirements:

must indicates something we think must be present for the system to be a solution
should indicates something we’d really like to have but could probably live without if necessary

Requirements

Technical

The translation system must work with a Ruby on Rails based application (i.e. with the i18n gem)
The translation system must work with more than one application

Security

We must be able to add / remove / edit translator accounts
We must be able to choose what languages a translator can view and translate
We should be able to prevent a translator viewing keys in a list of ‘private’ namespaces that can be kept up to date by us

Translations

We must be able to inform a translator when there are new translations
Translations must be able to contain variables whose values are supplied by the application
A translator must be able to view a list of incomplete translations
A translator must be able to add a new translation
Where a translation contains variables, the system must raise an error if the variable names don’t match in the translated text
A translator must be able to view a list of completed translations
A translator must be able to edit an existing translation
A translator must be able to search for existing translations
A translator should be able to see where a translation is used
The translation interface must support different pluralization rules for each language
We should be able to copy translations between different sites so we’re not retranslating the same content

Deployment

There must be a way of moving the translations from the translation system to local development, staging and production servers either batch or real time. If real time you must tell us what SLA you offer.
We must be able to deploy a new feature without having any translations available (The system should fall back to showing the English text in this case)
If no new keys have been added since the last deployment, deployment of the application must not be held up by the translation system
Updating translations should not mean having to restart the site

Looking for a SaaS translation solution