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

[Earl Miles]

Jose A. Reyero wrote:
> Hi Earl,
> 
> I'd invite you to take a look at i18nstrings module (Drupal 6) in i18n
> package, which implementes 'named strings' translation, and some basic
> object support, http://drupal.org/project/i18n (i18nstrings)
>   tt('views:viewname:title', "String in default language".......)

I don't like tt() for Views for three reasons.
1) Each call to tt() will cause a database access. For a lot of strings 
this is unfortunate. This is one reason that the API I outlined has a 
function that will get all the strings for a given object, which I can 
then go through in that object.
2) The pluggable nature of Views actually makes me worry that trying to 
use tt() on strings at render time will cause spotty behavior. Whereas 
the system declares what its default options are, so in that same 
function it can also declare which of those options are translatable, 
and once declared the developer of that particular plugin/style/whatever 
never has to worry about it again.
3) Because of how Views are stored, I don't want the onus of knowing 
when a string has changed to be on Views. Gathering a full list of 
strings for a given object makes, IMO, the management of those strings 
quite easy and the translation module can compare that list to what it 
had before and hilight what has changed on that object for the user. 
Also it makes it much more convenient to translate an entire object at once.

 >   to('views', $view, array('title', 'name', 'footer'....)

This doesn't work for Views; Views objects are not flat, and they can 
have plugins which come and go which will drastically change which 
strings are available.

> and also some patches on the issue queue, like this one by Gabor, which
> implemented full object localization and was proposed for Drupal 6, no
> luck though, http://drupal.org/node/141461
>   dt('view', $view)

Reading this makes me realize that I left out setting a type on the 
string, because obviously I'll have some textareas that need to be 
translated as well, and you'll need to know about that. It does look 
like there's some definite similarities with that patch to what I 
propose, but it suffers from the problem I have with to() which that 
Views objects are not flat AND they are very dynamic, so I need a more 
fluid way of telling the system what has changed. It's close, though, 
and I think it could be made to work for me.

> Also if you want to allow translations at some point but don't want to
> do all the work now nor introduce aditional dependencies into views, you
> can use some t-style wrapper for all the views so other modules
> (i18nviews would come next :-) ) can implement it.

This solution would work but I'm greedy and I want one solution that 
will work for all of my modules, and this one means each module would 
need a companion module.

So it does look like, perhaps, modifying the dt() patch to be able to 
handle the crazy crazy Views objects. By the way, just to give you an 
idea of what I'm talking about, here is a simplified look at the View 
object:

$view (views_view object)
   -- displays (array, minimum 1, no maximum)
     -- display (views_display object)
       -- options, style_options, row_options (all arrays of data)
       -- fields/filters/sorts/arguments/relationships (array)
         -- options (guess what? Can also data)
         -- can contain further plugins. With options. Like argument
             validators.

As you can see, there's a huge amount of nesting. Every view has at 
least 1 display but any useful view has 2 and possibly more. I've got 
real uses for Views with 6 or more displays. I have handler objects that 
can be used to basically recursively compile all the data, and I think 
that's important to this design because it will keep translation code, 
for Views, all in one place. That's one less thing for the developer to 
have to worry about, and trust me, there's plenty for the developer to 
worry about when creating this stuff.