Make paragraph bundles translatable with i18n_string

Thanks for the patch! Could you add a translation context so it's easier to translate specific terms?
(I had issues with the word "Case" in multiple projects, they always resulted in "Hoofdlettergebruik" ;) )

I updated the patch to work with 7.x-1.0-rc4

Whoops, filename contained a space...

I added a translation context as requested in comment #2.

Attached is a patch that adds another translation when you are editing a node with paragraphs.

This patch is being used successfully here but other people might want to review it also

Sorry to be a party pooper, but putting user-defined strings (i.e. bundle names) into t() is generally not the accepted way to do this sort of thing. This would look to be a job for the i18n module.

I agree, worst case this could result in a recursion situation.

It would be cleaner to make the paragrah names itself translatable. Just like i18n_node provided options to translate content type names.

So this needs a different approach like outlined here:

i18n module integration | Drupal.org

Since Paragraphs already depends on Entity API, we can leverage the EntityDefaultUIController and EntityDefaultI18nStringController to make Paragraphs bundles translatable. As a bonus, Paragraph bundles are now entities so the CRUD operations and Features exports are now available for 'free' by the Entity API.

Attached patch converts Paragraphs bundles to entities and applies i18n_string translations through the EntityDefaultI18nStringController in the paragraphs_i18n submodule.

I have regenerated the Features module that is used to test the Paragraphs module to reflect the changes in the export hooks. This should also fix the failing test.

Entity api, wooooot! Great work.

Using Entity API to export config creates monstrosities like this:

  $items['image'] = entity_import('paragraphs_bundle', '{ "bundle" : "image", "name" : "Image", "locked" : "0" }');

Entities in D7 are definitely not for exporting config. Feature exports should be hardcoded, sorted, predictable. It takes 3 features hooks to do it correctly. I doubt all this is necessary to translate a few labels.

#17: i don't see the monstrosity in this. quite some module use this approach, first of all rules. and we get some other benefits of it. +1 for entity api.

I think using Entity API is not unreasonable. If you take offence with the format it produces for exportables, that's probably something to be taken up with Entity API. If others agree, all modules that use entity API might benefit. FWIW, I think this format might be less conflict-prone than the usual lines and lines of nearly identical array structures Features tends to produce.

Patch works for me, i've created an rc4 only patch from the patch in #14

Reroll against -dev

Another reroll against latest dev.

+1 for entity api

This issue seems to be abandoned for a while, but it would clearly be an useful feature.

Patch for the rc5 version.

Previous patch did not include the ParagraphsBundleEntity.inc file. This patch is complete.

#27 confirmed working.

The patch no longer applies to dev and may require functional changes due to more recent commits. Please re-roll and retest.