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

[Earl Miles]

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.