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

[Jose A. Reyero]

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.

More comments below.

Earl Miles wrote:
> 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.
Agreed. This was just an example of similar features already implemented
and working so maybe we could build on that.

Also that module has some in progress (not really working yet but
coming) support for object prefetching (fetching all 'views:xyz:*' 
strings with a single query...

The issue is actually more complex than that. While for some objects you
may want to retrieve all the strings in one hit, for other cases (think
of a taxonomy autocomplete with localized terms) we may need to fetch
instead all the translations for a bunch of different objects. So I
think in principle single string storage, one string per row, is more
flexible and may fit all these needs.
>
>> 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.
There was some version of the patch that included also a possible
callback function to be defined for given 'text groups' (I'll have to
dig in my dev logs...)
>
>> 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.
I'm greedier yet and I want one solution that will work for everybody's
modules :-)

However I don't think there's anything wrong with an open wrapper that
allows any other multilingual solution to plug in there, but better if
it's not 'views' specific. See this patch instead,
http://drupal.org/node/155047

As a side note, when dealing with multilingual sites (specially for big
ones), the main problem for translators  is to have one single generic
UI and workflow to handle *all* translations, so it's really a major
nightmare if every module or group of modules implements its own
translation solution. On this sense, all these solutions proposed here
have the real advantage of using the same translation UI (locale module
with textgroups), which also can handle export/import of single or all
text groups, so external tools can be used too.
>
> 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.
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.

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)

So I'd really be happy if we could find any good solution that would
work for all modules. I'd be happier yet if you just provided one I
could reuse for i18n so I could drop that i18nstrings module :-) Btw,
there are modules in that package -like i18nstrings- that are spinoff
candidates so they can be reused by other modules without needing the
whole i18n stuff. I'm just figuring out how to make it best. So if you
thought we can build on that for some better solution I'd be happy to
create a new project for it and add your name to the list.

Whatever I'm glad you've brought up this issue in the list because we
badly need some good solution for Drupal 7 string translation and if we
can have one that is shared and tested by many Drupal 6 modules we may
be almost there for the next version..

(Btw, developers still wanted to build *the complete multilingual
solution* for Drupal 7)

Cheers,

Jose

>
>