improved translate tab concepts? [#1172298]

The current translate tab is a huge improvement and i like it.

However current implementation has a few caveats:
- The translate tab is per-element only
This means the per-content-type form only contains the content type name and helptext. Fields are missing there. There's a separate translate tabs per-field, but one needs to click through all fields to add translations. That's 11 forms for 10 fields with about 50 clicks instead of 12.
In comparision, the translate tab concept doesn't apply well to ajaxy UIs like views. More later
- Collective translate tables lack structure
For Views we've added a per-view translate tab that finally lacks structure. The form should be splitted into e.g. displays
- Missing default values
In a translate tab we miss the original values. We miss a revert (per item) or a "show original" to have proper reference.
- Missing context
In the original form, we have already great labels and descriptions for translateable fields. There are also tokens to be described. With the current concept, a translate tab limplementation has to duplicate those description texts to feed the tab.
- Overhead per i18n_string supporting element
The menu callback is pretty much overhead to add a translate tab. Also as previously stated, some help text need to be added as duplicate

We previously have seen the i18n variables thing that allowed in-form translation. While this was confusing for users, it's still inspiring me.
- We could extend the formapi with a #i18n_strings_key definition that can be added per form.
- i18n strings could then analyze forms and provide a dynamic translate tab
- The presentation might be somehow similar to now.
- Enough structure and context and description could be extracted from the original form.
- No menu callbacks needed to be implemented.

What do others think about that?

Comments

Comment #1

Jose Reyero CreditAttribution: Jose Reyero commented 29 May 2011 at 18:06

Yes, some very good points here.

However, we are running late for a 1.0 release, which should happen within the next week so I suggest we better postpone most of this for 1.1.

The variable translation forms have got some remake btw, see #1172462: Better UI for multilingual variables

Comment #2

miro_dietiker

Switzerland

CreditAttribution: miro_dietiker commented 29 May 2011 at 19:22

Fully agree, Jose. This where not thoughts for a quick solution. It was much more material for a next near / far iteration cycle.
Sure i'd love to see you work on such improvements for 1.1 already. ;-)

At the moment we absolutely need to concentrate on a clean release with the current concepts.

Comment #3

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 30 May 2011 at 07:29

I agree with the limitations, and API problems. Ideally, we could reproduce pieces of forms. Technically, most modules don't write forms in a modular way. Eg. instead of assigning validation handlers to individual elements, they have an overall validation handler for the whole form which validates all elements that need to have validation. Similar problems apply to submit callbacks (or rather the form structure being hierarchical in creative ways) If we could reproduce part of the form that would be great. In fact, fields API does that, it has component definitions for widgets and UI details for form components. Writing all other Drupal forms that way sounds like a new approach to forms, not sure it can be applied right away to most Drupal modules, but it is definitely a great approach to strive for. To be honest, I've assumed we can introduce this approach with Drupal 8 in core (and I'm not sure lots of individual validation functions will be received well, especially for interconnected fields), so any great idea as to how to do this for Drupal 7 core and/or modules would be very welcome :)