[development] Seeking help internationalizing Views (and Panels and maybe other modules for D6)
merlin at logrus.com
Sat Apr 26 16:55:51 UTC 2008
Jose A. Reyero wrote:
> Yes I actually share your concerns about queries/performance/full object
> translation. If you read the story of that 'dt' patch you'll see the same.
Yea, I read the dt() patch after I wrote that part. It definitely
addressed the performance issues there and they are what I brought up
and much more.
> I guess if you have such 'evil' recursive handler objects ;-) we'd need
> recursive translation handlers too. But also, you know many other people
> may build on your views module and add even more stuff in there. That's
> why I'd leave the door open for translation callbacks that can be
> implemented by other modules.
Well, my hope would be that the onus for understanding the depth would
be on me. With the API I specced out, I just provide you a list of
strings when you ask for it. The issue is, you can't assume that the
list of strings you asked for yesterday will be the same list of strings
you asked for today. One of the reasons that my API has a string
identifier plus a textual label is that
'viewname/displayname/field/fieldtype/option/separator' isn't going to
mean much to the user, but I can translate that into a string which, at
least in English, will mean something, but also that stuff can all be
run through t().
And the idea of organizing the strings is that you *can* group them all
together, so the textgroup concept, at least, works; I'm not sure about
the mechanism itself as I'm not familiar with it. As long as it can
handle strings coming and going arbitrarily then it should work fine.
> 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.
More information about the development