Maintaining an Intensive Production System and Template/Partial Localizations

[ozataman]

Hey all,

I am working on a project where, really, the whole app will actively be used in several languages. This means that the interface, e-mail messages, and all the little things that come with a good app need to be translatable. Needless to say, I've been using globalize from day one and I love it.

However, a few things have been keeping me worried for quite some time now and having failed in finding an elegant solution, I figured I'd ask for some advice here.

1. As far as Agile Development goes, we're quite agile and keep changing things on the interface almost every day. Every time though, a bunch of translation keys become useless in the database, and we end up having to translate all the new additions to several languages. How do you guys manage all this cleanly? I realize this is going to be hard work either way, but I keep thinking someone must have figured out a good way to do it. I just hate the feeling that my translations table is getting messier and messier by the day.

2. There are certain components, like little help boxes and popup explanations, where partial translation seems to make more sense. As far as I'm aware, there are two reasons for this. 1. When you first write a long sentence in your base language, it's very hard to make sure you'll never change it again. If you do .t style translation, then with each correction you make on your original text, you have to re-translate it in every language you use. What a loyal pain in the ...! 2. Since the content is static and quite lengthy, it just feels like better practice to give it its own translated file.

The problem is that we are already using Rails 2.0.2 and we simply couldn't get the _<partialname>.<en-US>.html.erb path system to work. We also tried a bunch of variations on the path, albeit, with no success.

I appreciate any solutions, insight, ideas and advice.

Best,
OA

[elijah-5]

ozataman wrote:


> Every time though, a bunch of
> translation keys become useless in the database, and we end up having to
> translate all the new additions to several languages. How do you guys manage
> all this cleanly?

In the case where the UI changes before translations have been entered,
we do this:

ViewTranslation.delete_all "text IS NULL or text = ''"

> There are certain components, like little help boxes and popup
> explanations, where partial translation seems to make more sense.

What I do is make the keys be symbolic placeholders, so that the
application is not really usable until an english translation has been
made (in our case). For example, "help: password_change".t or "info:
first_name".t

"help: password_change" in this case would be the key to a much longer
body of text that described to the user how to change their password.
Then, by adding updated_at to the translations table we can easily
figure out which of these larger bodies of text need to be re-translated
(in our case, by volunteers through the application itself).

-elijah