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

[Jose A. Reyero]

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".......)
  to('views', $view, array('title', 'name', 'footer'....)

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)

It all is pretty much the same philosophy, using the locale's textgroup
support for translation interface, that may have its quirks but allows
easy import/export of translations  (I.e. export 'views' translations)
and a common familiar interface to translate everything, without too
much work.

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.

Like views_t($view) before any display operation

function views_t(&$view) {
  if (function_exists('views_t_implementation') {
    .......
  }
}

Or, alternatively, let me know how could I improve i18nstrings module to
meet your requirements. For what I see below we'd be already almost
there for views translation.

Earl Miles wrote:
> Okay, so I have this idea for a module that will allow contrib modules
> to have their objects translated. I just did a scan of the modules
> available for Drupal 6.x involving translation, and #translateable
> seems close but not quite what I'm looking for, but it might be
> possible to turn it into what I'm looking for. Here's what I'm thinking:
>
> Many modules work with objects of some sort; particularly my modules.
> Because of the complexity of my objects, I've gone a long way to
> disengage them from the form. It is not possible to use duplicate,
> related objects to do translation, as is often done with nodes,
> because a view object does a LOT of stuff and it's very important not
> to have duplicates that try to do the same thing. This is also true of
> Panels.
>
> One thing I can do, is pretty easily identify any string I store as
> translateable. This is my proposed API:
>
> Views loads a view. Upon rendering, if the global $language->language
> is not the default language, and this module is enabled, Views will
> call MODULENAME_translate_object('views', 'view', $view->name) and
> do an inline replacement of all strings on the object itself. Views
> will also provide a 'translate' link which will lead to a URL provided
> by this module to translate that view. It may be possible to do some
> fapi integration with ajax translation but that's a 'bonus' feature.
> Could be cool, as long as it's not too hard to implement in my already
> crazy UI.
>
> /**
>  * Return an array of translated strings, or NULL if there are no
>  * translated strings for this object.
>  *
>  * @param $module
>  *   The name of the module that owns the object.
>  * @param $type
>  *   The type of object being translated. Example: 'node', 'view', etc.
>  * @param $id
>  *   The unique identifier of the object. May be a string!
>  * @param $language
>  *   The language to translate to. If not specified, use the current
>  *   langauge from global $language.
>  */
> function MODULENAME_translate_object($module, $type, $id, $language)
>
> /**
>  * Tell MODULENAME what objects your module has available for
>  * translation.
>  *
>  * @return
>  *   An array of object identifiers. Each one must be unique.
>  */
> function hook_translateable_objects() {
>   // example
>   return array('view');
> }
>
> /**
>  * Tell MODULENAME what strings a particular object has available.
>  * Because some objects may be dynamic, this is called for every
>  * unique object id when translation is actively occurring.
>  *
>  * @param $type
>  *   The object identifier that corresponds to that used by
>  *   hook_translateable objects
>  * @param $id
>  *   The unique object ID being translated.
>  *
>  * @return
>  *   An array of strings; the key is the string identifier, and
>  *   each value is an array that contains the following:
>  *     - title: The title of the field.
>  *     - description: The description of the field.
>  *     - value: The current value of the field.
>  */
> function hook_translateable_strings($type, $id) {
>   // example
>   return array('view');
> }
>
> From the API perspective, that's about all I have to do. I have to do
> some extra work to make sure each component of the view provides the
> strings properly, but that's not hard.
>
> The translation interface will need to record state information on the
> strings, so that it can tell the user if the string has changed since
> the last time it was translated, making it easy to highlight what
> needs to be updated. It might be nice to provide a way to browse, but
> I think it's better to let the module provide that and require the
> module to provide a link to the translator; that's less work for this
> module and is likely to be much less clumsy.
>
> If someone implements this, I promise Views will use it and will use
> it very quickly. If a module like #translateable wants to use
> something like this, so much the better; I would really prefer it if
> an existing translation module can take on these features, so that we
> get more widespread usage. That said, my belief is that any module
> that Views uses for translation will see widespread use in the
> localization community, and thus, if well maintained, will become a de
> facto standard and we can convince other module developers to use it
> too. I'm willing to be flexible, too, but Views has special needs;
> you'll need to cater to it to get this working, and translating Views
> is a very important thing for a truly multi-lingual site. But also,
> with this API any of my modules will be easily translateable.
>