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.