Add consistent translation tabs for objects

We already have a tab for menu items (needs i18n strings tab yet)
It seems one more for taxonomy terms is coming, #1155238: Create translation tabs for terms

I think any of them: menus, menu items, fields (though I'm afraid that is gonna be harder, field options and that..)
and taxonomy terms once we've got at least a placeholder tab, working on that... (the issue on #2)

Looks great!

I just have some concern, that is actually moving the menu item definition (looks almost the same) into our hook, and maybe overloading that _object_info().

Could we simplify it a little bit by having each module produce its own menu item that then add some page callback passing the object type and the object itself to be localized?

Otherwise it looks great to me. There some left over 'dpm' btw.

Thanks a lot. Committed.

(Though I didn't mean you drop that much of the original patch, I do need to take a look at it again when I can have some rest...)

Letting open for further improvements. The idea, basically is that we add the info somewhere so we can get rid of some more intermediate callbacks.

My ideal callback (though not possible atm) would look like:

i18n_string_translate_page('taxonomy_vocabulary', $vocabulary, $language...)

Anyway I still need to make up my mind about how to get it (more info, more classes, etc...).

Thanks again!

This is a first try, example implementation o how I think it could look.

Just implemented for taxonomy, breaks the i18n_string_translate_page api, which should be a quick replacement, but still supporting that object_meta, for maybe other edge cases (small textgroups that don't want to implement the whole thing, etc..)

Support for core objects (fields, menu items, nodes, even this taxonomy part...) could be added into the base class so we don't have to add too many classes here...

The long term idea being: given any object (on any page), figure out which translation options we've got for that and simplify info hooks by using classes (one for translation set, one for textgroup), while adding flexibility by having overridable methods instead of a mess of info options.

After talking with berdir on the chat, who suggested some good ideas, here's the first chunk, translate taxonomy.

Now we can go module by module and maybe eventually replace the whole $form_meta thing, we'll see.

Does this look good?

Ok, committed your version, but fixed some notice ($object instead of #object).

I'll be doing the rest of the modules, so back to needs work.

Replaced the menu tab for the standard one in i18n_string module. In the way, added some function for returning object/array keys (i18n_object_key) and some default edit and translate path

Standard translate/edit paths for most objects should be a combination of 'base path', i18n_object_key() and 'edit' or 'translate'...

Added more reusable functions (implemented for paths, menus) here, #1164072: Move menu translation sets tab one level down, so they don't depend on a specific menu

Added some functions and changed some others for consistency between both translation methods (strings, translation sets). These functions are i18n_translation_object_info() and i18n_string_object_info().

Using these, we can auto generate a bigger number of tabs, no need anymore for overriding the i18n_string_textgroup class. Done for node type information as an example.

More:
- Some generic object level information is handled by i18n module, like the edit path for an object, see i18n_object_edit_path()
- Atomated placeholders handling for paths, see also i18n_object_placeholders()
- Also updated some other functions for consistency.

Attached the path that was committed. We need to update contact form translations too. Still working on more general translation tabs, ideally all of them should be handled by i18n_translation, i18n_string, using object meta data.

Next patch, still WIP, that will add some more consistency all through the API and translation tabs for fields. This patch includes some api clean up, some (backwards compatible) extensions and more object related string functions.

Committed the patch with a minor change (there was a bug with string name).

Fields got a translate tab! (actually two, one for field instance and one for the field itself, to translate options). And btw, added field 'label' into the strings too, once Drupal core issue is fixed (label wrapped in t), that will be some use.

Now we should look into taking advantage of the new object api extensions maybe saving some code in other modules. The main goal here is to provide an easy way for other contrib modules to translate their strings so if it could work only with some i18n_hooks() implemented in the module.i18n.inc file, that would be great.

And this is the big one: we can already generate most translation tabs with metadata from hook_i18n_object_info().

Now a module could get most of string translation features by
- implementing this hook in module.i18n.inc
- Update object strings with conditional calls
module_invoke('i18n_string', 'object_update', [object_type], $object);
module_invoke('i18n_string', 'object_remove', [object_type], $object);

For most complex cases though, it may need to extend the textgroup class.

Fully implemented for taxonomy, menu, and node_type objects.

We need to consolidate some code now, remove left over functions, document, etc, and this will be done. As most objects can now autogenerate their strings we can simplify further string refreshing and string list hooks.

Note: looks like i18n_string_object_translate needs fixing.

Attached the big patch that got committed.

Added automated tab for i18n_contact too, applied the attached patch.

The automated tabs work with the 'translate interface' permission which I think should be ok.

At this point we have enough meta-information to keep strings up to date for most objects. These are:

i18n_string_object_update()
i18n_string_object_remove()

Used them for the contact form, which is simpler now. Also added comments for hook_i18n_object_info(), which can help other module maintainers.

This is done.