Multilingual support

Multilanguage would indeed be nice. I'm looking at a breadcrumbtrail that looks like this:

Home › englishMainCategory › englishSubCategory › germanMainCategory › germanSubCategory

Any suggestions?

thanx, bobject

p.s. for my case Taxonomy Breadcrumb seems to work perfectly out of the box.

The attached patch provides this feature.

This language support completely behaves like path.module does for URL aliases:

• The language column is added to the {custom_breadcrumb} table.
• The language setting is invisible from the administration interface unless the Locale module is enabled or the {custom_breadcrumb} table already contains language-specific breadcrumbs.
• The module looks for a breadcrumb in the current language. If there's no breadcrumb defined for that language it will search for one without language.

Marked #219289: Multilingual support as a duplicate.

Maybe in the install file must use new Drupal6 schema API for DB editing: db_add_field() may be usefull...

Regards

Could you be more precise and/or update the patch if needed? What field needs to be added?

I mean: in the .install file instead using SQL to create new "install" field in {custom_breadcrumbs} table, you should use db_add_field() (my 2 cents :-) )
I don't have a multi-language D6 site to test it..

Regards

Ah, got it! Updated the patch to properly use Schema API in the update hook.

I hope this can be committed soon. Without this patch, Custom Breadcrumbs is not usable on many multilingual sites.

Marked #310757: Custom Breadcrumb not translating titles as duplicate.

The patch seems to work fine with 6.x-1.4, but I am wondering if this is the best approach for multilingual sites.

This patch requires manual configuration of all custom breadcrumbs into each desired language, and a new database entry for each language and node type. Rather than translating the breadcrumb trail into the correct language, an alternative breadcrumb is pulled from the database, according to the value of $language->language. This provides a solution, and has advantages and disadvantages.

I suppose this approach would work well if you wanted to provide different (i.e. not just translated) content and breadcrumbs for different languages. But this patch isn't really needed in that case. If you want to do this you can just duplicate content type (english page, spanish page, french page, etc.) and use a different custom breadcrumb for each language.

The primary disadvantage is the effort needed to duplicate all the custom breadcrumbs on a site for each language that you want to serve....with many content types it adds up fast. Personally, its enough for me to simply have a correct translation of the breadcrumb trail. I think this should be possible without duplication of breadcrumbs, and without the new field (language) that this patch adds to the custom_breadcrumbs table.

Also, there is one small typo that I noticed. In the languages section of the admin form <am> should be <em> .

Before thinking of committing this patch, those who are interested should discuss this approach and consider if there aren't better alternatives. Just my opinion.

As I have mentioned in #2, this patch implements the same approach taken by Drupal core for multilingual URL aliases. It also satisfies many use cases—one might just use different breadcrumb titles for each language, use different titles and paths, or even have a different breadcrumb structure depending on language.

I don't think that using a different content type for each language as you suggest is a very common configuration for multilingual sites. By doing that, you wouldn't be able to use the i18n module's translation workflows (which only allows to translate a source node to nodes of the same type). Although it is easy to duplicate a content type, you'd then have to maintain separate content types for each language, and with CCK fields that could mean a lot more work than just managing separate breadcrumbs for each type and each language.

I'm also interested in hearing what others think, but so far I still stand by my solution. ;-)

In the meantime, here's an updated patch to fix the typo.

I'm exactly looking for this feature... using a 5.x drupal website with custom breadcrumb installed (5.x-1.2).
Do you think your patch will work for the 5.x-1.2 release of custom breadcrumb ? Or are there so many changes in the code between the 2 versions ?
Thanks.

@chapo: the patch won't work with 5.x because it uses some 6.x specific code. The changes are small enough, though, that it wouldn't be hard to modify it and make a new 5.x patch. see http://drupal.org/node/114774 for guidance.

So after working with this for a while now and looking at other options, I agree with David's solution - it fits the way Internationalization is currently being done.

Another small suggestion for the patch would be to set the #default value. Otherwise you are continually forced to reset it when you edit the breadcrumb.

  if ($multilingual) {
    $form['language'] = array(
      '#type' => 'select',
      '#title' => t('Language'),
      '#options' => array('' => t('All languages')) + locale_language_list('name'),
      '#default_value' => $bid ? $breadcrumb->language : NULL,
      '#description' => t('A breadcrumb set for a specific language will always be used when displaying a node in that language, and takes precedence over breadcrumbs set for <em>All languages</em>.'),
    );

Re-rolled for the latest version of the module, and made sure that #default_value is now set properly.

Thanks for the update. In reading through the code I noticed that the changes to the install file don't match the Drupal 6 schema. In particular

No longer are switch statements done on $GLOBALS['db_type']; instead, use the variety of schema API functions to perform table manipulation.

See http://drupal.org/node/114774#schema-api for more information.

Fixed. Thanks for the quick review and the keen eyes!

I found another problem with this after disabling locale. When I went to edit custom breadcrumbs, I got a wsod with the error "Call to undefined function: locale_language_list()"

This is happening because of the or clause in the following function...

/**
 * Check whether the administration interface should show multilingual features.
 */
function _custom_breadcrumbs_multilingual() {
  return module_exists('locale') || db_result(db_query("SELECT COUNT(*) FROM {custom_breadcrumb} WHERE language != ''"));
}

I think its sufficient to use return module_exists('locale') . Can you explain why the db_query is needed?

Thanks.

Wow, good catch. The rationale behind this was to avoid offering a choice of language when only a single language has been enabled and no language-specific custom breadcrumb has been created. However, once that custom breadcrumbs have been created with a specific language, that leads to the problem you have found.

The path module uses a similar logic (see path_admin_overview()), but I guess they have been careful to avoid this kind of problem. Still, I think it would be reasonable to use just module_exists() as you suggest.

Made changes to only check module_exists('locale'), avoiding the mostly useless logic that was provided by the query.

This patch looks like it's been made against 6.x-1.4, while the version mark on this issue states 6.x-1.x-dev.
I'm a bit confused about the branches and tags here and which version this patch was made for.

I could apply it to 1.4 (1-8 rows offset depending on file), but a hunk in the custom_breadcrumbs.install file failed for 1.x-dev, so I'm assuming 1.4.

It seems to do its job though. Did not test disabling locale module, only set my language on my existing breadcrumbs and made some new ones for my second language.

Thanks for this patch, my breadcrumbs looked really weird without it!

Well, it seems as it is against 6.x-1.x-dev branch since the 6.x-1.4 tag contains the module file version 1.6.2.4 while the patch is against 1.6.2.5. Furthermore all files of the dev branch still have the same version as this patch is against.

Therefore it would make sense to apply this patch and commit the other pending patches against the new patched dev version.

I've implemented this patch in custom_breadcrumbs 6.x.2.x. See #372648: Custom Breadcrumbs 2.x for a discussion of this development...

committed to 6.x.2.x-dev

Looks like this was never committed to 6.x-1.x ... is that correct? Trying to work out how to do multilingual breadcrumbs with the current recommended D6 version. =/

Edit: Seems not. Anyone mind if this is marked for needing a back-port? Most of the work is done as the original patch was for 6.x-1.4 - it just needs re-rolling against the latest 6.x-1.x-dev code.

For the record, the patch in #20 doesn't quite work. It doesn't seem to save the language in the custom_breadcrumb table - just an empty string. If I manually put the language in there it all works fine, so the front of it works. Just the admin page not saving the language. I'll try and fix this and post a patch in the coming weeks.

For 6.x-1.x, Eaton expressed a desire to avoid "incremental feature creep" See #357367-8: Custom Breadcrumbs has additional maintainers - planning for cb 2.0 and surrounding context for an explanation. So at this time, this feature (and other new features) is only implemented in 6.x-2.x. At this point it would be helpful if you could test the 6.x-2.x-dev version so the next beta version can be released. That will help move toward a stable release of cb 6.x-2.0.

Thanks.

Hi, ok - I understand. Won't be able to test the beta on this project though, because it's production and we only use recommended versions (which is 6.x-1.5, obviously). If I get chance to try it out in my sandbox later on, I will. =)

I need to translate my breadcrumb strings as well, but unfortunately I can't use version 6.x-2.0 because this conflicts with the language switcher block: #980040: Conflict with language switcher (locale).

Would I be able to get this working in 6.x-1.5 with this patch? Or is there a way to work around the other issue I have?

+1 for backporting this. 6.x-1.5 is the "stable" version after all.

I'm using 7.x-1.0-alpha1 how do I make this multi-lingual? Is this patch adaptable?

Same question here...
I just want to see
home-> events in english site and
home-> eventi in italian site

sub

I realize it's been quite some time since comment #13, but...
Back then you've chosen to take the route of adding multiple DB entries for every language-breadcrumb combination.

Have you given some thought to the other solution? Seeing there'a a pretty comprehensive i18n module, wouldn't it be right to try and implement a system in which strings are tested against i18n module to check for translations?

(also, seeing as I've found ~5 different issues opened on this, and people's solution of adding a t() is obviously not appropriate, but raises the issue that a translation might be better than per-language data)

I found a temporary compromise:
It's so people requiring translation can get t() on their strings, but without hacking the entire module.

How about adding an identifier to Custom Breadcrumbs Identifiers, that looks something like this (sorry, failed to create a patch file):

function custom_breadcrumbs_identifiers_cb_identifier_list() {
	...
	$identifiers['<simple_t>'] = t('Pass the corresponding title string through t().');
	...
}

function custom_breadcrumbs_identifiers_cb_identifier_values($identifier, $obj) {
	...
	...
		case '<simple_t>':
			$title = t($obj['title']);
			$crumb_items[] = array(
				'crumb' => l($title, $obj['path'], $obj['attributes']['attributes']),
				'title' => $title,
				'path' => $obj['path'],
			);
			break;	
	...
	...
}

@amitkeret: Please discuss that in another issue. This one is fixed.

For D7, this is a duplicate of #1320056: A small patch to add the home variable to i18n variables for Administrator translation.