Translate all custom block titles (not only custom blocks)

I've created this patch for translating the block title when the user has customized a block title. The customized block title will be translatable from the translation interface.

subscribing. I have the same issue.

subscribing. I have the same issue. (II)

Nothing is broken, so setting back to normal.

There is at least one code style issue inside with a missing line break before "else {". Additional I do not understand why

doesn't not become

and

what looks more readable to me.

The
elseif ($i18nmenu) {
is replaced with
else {

Then we need to do 2 things:
1) check if we have i18nmenu enabled and supply translated content for menu blocks
2) and finally supply a translated title for the block

A new slightly modified patch is attached.

There is no feedback to the above suggestions and patch has not changed this way + indention code style bugs.

if
elseif ($i18nmenu && $block->module == 'menu') {
and
elseif ($i18nmenu && $block->module == 'user' && $block->delta == 1) {
are used, then the custom block title for these menus wont use any translations if they are available.

That is why the pseudo code is

Of course you can change it to the following if it is more readable

Fixed the indentation bugs

Hey, I am still fairly new w/ Drupal and of course having the same issues as others where the menu block titles are not translatable. Well I guess I should say titles of blocks made by other modules are not translatable.

I have tried the above patched, but there seems to be no difference. After refreshing the strings, I am still unable to find any translatable strings for the menu block title. Has anyone gotten this to work?

I will offer one solution here that has worked for me, that is to code the menu into a regular block using an unordered list. Then ran it through the translator. Its not elegant, but it is old school and it works. Would be nice to be able to just pull the menu module generated block titles through t() but and do it that way, but I still haven't gotten that to work either.

The strings wont appear in the translate interface until you view them in a different language. Can you first try viewing your site in a non-default language so that your menu block is visible. Then go to the translate interface to see if your block title is there.

Thanks for the help. I tried what you said, and it worked, sort of. I was able to generate the strings while I was viewing the foreign language version of the site, and I could translate them. But they don't seen to stick, that is, I refreshed the strings again in my default language, and they disappeared. I dunno if this is an issue with il8nblock itself or what.

--EDIT--

Actually I tried using the unpatched version of the modules too and got the same result (minus the additional translatable strings provided by the patch). Is this normal behavior for the block translator, because the menu translator doesn't do this?

Can you give me an example of what you are doing. I don't know what you mean by "I refreshed the strings again in my default language, and they disappeared."

Basically I am trying to translate the title of a menu block that was created with the menu module. I can get it to work per your instructions---view the block in a language that is not the default language to create the strings (Japanese in my case). And yes in non-default language view, the strings are created and you can translate them w/ the Translation Interface. But then I noticed that if you go into the Translation Interface while viewing the site in its default language (English for me) and then refreshed the strings, then all the block strings that were translated would disappear.

This happens with both the patched version of the module, and unpatched official version of the module. I am not sure if this is normal behavior for the block translation module or not though.

If you need anymore info, please let me know.

Attaching two images to show what I mean.
First image is in Japanese language and Block strings show up fine.
Second image is in English language w/ refreshed strings. Block strings are gone.

I can reproduce what you describe, after doing a refresh the translations are gone.

If you don't do a refresh are the blocks translated OK?

Yes, the blocks are translated fine, as long as one does not refresh in the sites default language. Maybe this is a bug?

The refresh problem looks the same as what is described here: http://drupal.org/node/442428

Thanks :-) Will start replying in other thread.

Hi,

I just came across this after writing a patch of my own for this very issue. I've taken a slightly different approach in that the patch allows all blocks to be set to 'All languages (translatable)' (not just custom) and creates the title i18n strings for all translatable blocks when they are created/saved so no need to switch to required languages or attempt the refresh of doom... i18n strings for content are created for custom blocks only.

Apologies if it's bad form to attach another patch to an existing issue.

Andy

Sorry - that last patch included patch 500662. This one is just my i18n block title patch.

Patch have trailing whitespace.

@chaps2 I'll have to check your patch out, seems the previous patch has stopped working for me as of the latest core update. I don't know if that should be an issue or not though. Yay for smart people!

Awesome! 2nd patch by chaps2 works a charm! And actually I found out that the previous patch brucepearson was still working as well, I just had some IIS issues. You guys rock!

Subscribe

Subscribe

You seem to have solved a long standing issue!
When can we get this committed?
I don't know how to patch and the modifications are to heavy to be done manually.
Possibly I would appreciate the patched i18nblocks.module and i18nstrings.module fully coocked...

Looks good. Committed the patch in #8, which looks much simpler with some changes:

Removed this part

This may cause normal block generated titles, which should be already translated to be retranslated....?

(Btw, the module is ready for a new release, some quick testing welcomed)

Three test results, possibly for further confirmation:

A - After applying the patch manually to 6.x-1.1, as #28 (#8). Using a block created by the ed classified module (Latest ads...):

- a block string (i.e. block:3:title) is found and can be translated
- the translation does not show in the block heading, where it is expected
- in the translation ui, the translation is retained after strings refresh

B - since the translation did not show in the block heading, after adding the omitted elseif statement:

- two translation strings appear, the original one (block:3:title), and a new one specifically identified with the module (i.e. ed_classified:12:title), the new one can also be translated
- the translation (presumably ed_classified:12:title) appears on site in the block heading, as intended (super)

- after refresh strings, the first string (block:3:title) disappears from searches (and does not return), the second one (ed_classified:12:title) is found while its translation is lost from the translation ui
- the block heading translation is lost

I checked my patching and think it's correct, yet could this be further tested?

C - After uploading i18n 6.x-1.x-dev Last updated: November 7, 2009 - 07:08, using the same block as above, and after clearing cache etc.:

- one block string, module related (ed_classified:12:title), is found and can be translated
- the translation does not show in the block heading, where it is expected
- the refresh checkmark option for blocks is not available anymore, string refresh not done

So, something is not yet quite right, while result B with the original patch #8 did show a translated block heading...

@jeyro:

Thanks for the thorough testing. Some things to consider:

- The patch should be already in the -dev version, or you should apply it to the dev version. Other versions / combination are useless as for module development purposes.

- Test with core modules. I.e. customize a title of other Drupal core blocks. Other contrib modules may have issues of their own.

- The refresh option for blocks is not implemented so only option here is switch page language, then check string. See #442428: refresh strings in translation interface causes translations to be erased and then cannot be found in search

@jose

thanks. Above I'm using the contributed ed classifieds module as an example - please note that its translated block heading shows nicely in test B. To clarify:

C above tests the -dev version: Result: no translation shows for the contrib module heading
B above tests patch #8. Result: --- the translation shows as intended ---
A above tests patch #8 minus the elseif code: no translation shows for the contrib module heading

The removed part of patch #8 appears to be responsible for showing a translated contributed module heading. The current -dev version apparently translates the string, but the translation does not appear in the contrib module heading.

I'm not coder, so I can't make a code suggestion.

---
PS: I've now also tested a core module block, specifically Recent comments: yes, the translated heading shows as intended.

Need to add to C above for -dev version:
- for core module block (recent comments), translation ok for each: default and "override" titles/headings.
- for contrib block (ed_classified), translation no show for the default but *does* show for "override" titles/headings.

Automatically closed -- issue fixed for 2 weeks with no activity.