[development] Seeking help internationalizing Views (and Panels and maybe other modules for D6)

[Daniel F. Kudwien]

> > About the translation UI you may think also of a specially 
> suited one 
> > for views, but as I mention above the problem most usually 
> is to have 
> > a generic one for all translations. Also to keep in mind, 
> translators 
> > are not necessarily tech savvy people so any UI needing 
> admin access 
> > to translate strings has some fundamental problem. However, we can 
> > also build an object UI on top of the single strings one (So the 
> > single site-admin-developer-I-just-want-my-site-in-two-languages is 
> > happy too)
> 
> It's not so much that this is specially suited for Views so 
> much as I'm trying to set up something that works for lots 
> and lots of things and is able to take into account the 
> flexibility needed. The translator shouldn't actually see 
> what's going on; but instead be presented with a list of all 
> current, known translatable strings for a given object, and 
> highlights for which of them have changed since last time.

I have to disagree here.  Most of the translators I had to deal with in the
past always asked first: "What's the context?" or "Where does this appear?"
Locale's/Translation's interface for adding/editing translations is
currently built for developers/advanced Drupal users, not translators.
Developers speak programming languages.  I guess only a minority of
developers can speak additional languages and have also skills of real
translators.

To translate a content correctly, translators are more comfortable with the
approach taken by #translatable.  They see the original form and thus, have
an idea of how all strings and contents of an object relate.  #translatable
stores the translations and does not alter the original data.