[development] Seeking help internationalizing Views (and Panels and maybe other modules for D6)
Daniel F. Kudwien
news at unleashedmind.com
Sat Apr 26 17:27:30 UTC 2008
> > 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,
> > 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
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.
More information about the development