Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.While writing http://hojtsy.hu/blog/2011-apr-03/drupal-7039s-new-multilingual-systems-... it came to me that it would be relatively straightforward to provide context specific UIs. The block module for example can provide a structure about the items it offers for translation.
An imaginary page callback for a translation tab on a block could show up like:
function i18n_block_string_translation_ui($block) {
$form_meta = array(
'blocks:block' => array(
'title' => t('Block title'),
'body' => t('Block body'),
),
);
return i18n_string_generic_ui($form_meta, $block->id);
}
And it could then display translation fields for blocks:block:$block->id:title and body respectively with the titles provided and a language overview page or just a dropdown for selecting which language to translate to. It can be made a bit more friendly maybe by also allowing a description somehow. The form would then save the values to the appropriate local table.
I think this would help tremendously in moving block translation in-context with a translation tab like people expect on other objects, and can be a reusable pattern for other objects. The tab and page callback would be provided by the specific module (in this case block languages) but the generic UI callback would generate the actual form with submit callbacks based on the string IDs computed from the object metadata.
Then i18n_strings could even provide a full overview table like core translation module or entity_translation to show whether certain versions have translations, etc.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | StringEditor.png | 158.53 KB | Gábor Hojtsy |
| #8 | i18n_strings_reusable_ui.patch | 10.91 KB | Gábor Hojtsy |
| #6 | i18n_strings_reusable_ui.patch | 8.03 KB | Gábor Hojtsy |
| #6 | BlockContext.png | 27.45 KB | Gábor Hojtsy |
| #4 | i18n_strings_reusable_ui.patch | 7.84 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor HojtsyHere is a proof of concept implementation that covers blocks. Maybe the menu tab creation should be put as well with i18n_string module, so we can avoid this happening in the subject specific module. But I was trying to make it as much general as possible... Neither the locale neither the i18n_string API has no way yet to save the translations, so that part is not there yet. I think this could be made really reusable for contrib modules to just tack on translate tabs on their objects, with their involvement only to define their objects and some labels proper. I think it would be great to make this simpler even instead of complicating it. Of course we can make it however complex in i18n_string, but need to make it as simple as possible on the API side.
This is how the workflow looks:
- you translation enable the given block in its configure page
- suddenly a Translate tab will show up on the block
- this tab displays an overview of the translations like the node page does (this is implemented in i18n_string)
- that page displays edit and translate links for items; the edit link is for the source item, the translate link for all others
- when you hit a translate tab, it actually shows the strings related to this project
A couple screenshots follow.
Comment #2
Gábor HojtsyOnce you translation-enable a block, it gets a translation tab:
Which is deliberately designed to mimic the node translation overview (which is the same/similar in core and entity_translation, so can be considered a well known applied pattern to reuse for user comfort). The edit link leads back to the configure screen, the translate links lead to actual translation screens (see next):
This is an actual translation screen. We only know the keys for the strings, like the locale UI would do, so we only display the fields as plain old textareas, which users can use to fill in. I don't think we have a lot of opportunity to do this form any richer:
All this is implemented with blocks as a proof of concept. Once again the idea is that modules would only need to describe their objects, so that i18n_strings can provide a generic translation screen with an overview, which would comfort users with a familiar interface to translate objects, like the one used for nodes regardless of the core copy or contrib field based approach. I've implemented it for blocks because it should be a good proof of concept item I think.
Comment #3
Jose Reyero CreditAttribution: Jose Reyero commentedLooks great, go ahead and commit, we can work on improvements (and more tabs) later.
Comment #4
Gábor HojtsyAttached patch now actually saves the translations. One caveat. This still needs to check permissions for strings with input formats, and display the input format information like it does on the core UI interface. This one is still to be done, before this can be considered committable.
Comment #5
yoroy CreditAttribution: yoroy commentedCould I access this through a contextual link on the block? I think I'd like that.
Comment #6
Gábor HojtsyYour wish is my command :) This time at least :D
Comment #7
yoroy CreditAttribution: yoroy commentedSeems like that makes sense, nice! :)
Comment #8
Gábor HojtsyAnd now with actual validation of input format permissions and locale XSS prevention like it was on the the locale UI. Also fixed the format explanation display bug that was in i18n_string and added the format help here too.
Comment #9
Gábor HojtsyOk, committed this one :)
Comment #11
miro_dietikerNote that there's a followup
#1172298: improved translate tab concepts?