Add i18n support for Label and other property translation (+ entityform name)

Ok this is not supported right now.

My plan is probably to implement i18n module integration like this: http://drupal.org/node/1512494

It would be a submodule like entityform_il8n and require some changes in entityform.
If someone wants to take this on right now I can help. Otherwise it is on my list.

I will have to think on a work around for right as far as hiding.

Ok, I have started a new branch to work on this. It will creates a new submodule entityform_i18n module.

I am just working on translating strings part not the actual outputting of the translated strings(which should be easy).

Right now I am running into a problem on pages like this admin/structure/entityform_types/manage/[entityform_type]/translate/fr

All of the text boxes are disabled except for the label. I haven't found the problem yet.

But I have found that in file i18n_string.admin.inc in function i18n_string_translate_page_form_strings

Around line #165
$source = $item->get_source();
$source is empty and this disables the textbox. Also probably related none of the properties besides label are in the i18n_string" table.

If I could help on this issue it will increase the chances of this getting into 2.x. I don't personally do many multi lingual sites.

changed title

Ok. So just pushed some changes to the branch.

I fixed the disabled text boxes by creating the magic functions __get and __isset on the EntityformType class.

I am not sure this the way to go might have side effects...

I did this because in the function i18n_object_field

elseif (is_object($object)) {
    return isset($object->$field) ? $object->$field : $default;
  }

In EntityDefaultI18nStringController it states

Current limitations:
* - Translatable property values cannot be updated via the metadata wrapper,

So it doesn't use the getter callback that is used by the rest of the Entity API.

Other ways this could be handled.
Implement i18n_string_list_entityform alter which is called from i18n_string and passes the Entityform Type objects. The string values could be updated here.

Extend the class i18n_string_object_wrapper so that we could get properties via entity_meta_data wrapper or directly from the data array.

Pushed changes that to the branch that outputs translated values of the properties.

I have tested the label and submit button.

I have not looked into text properties that can be other than plain text.

Right now this is not working with properties that aren't plain text

I asked a quesiton in the Entity API issue queue related to this #1973024: Does Entity i18n integration support Text Formatted properties properties?

#tedbow thanks for this change
labels get translated in general but FILE FIELD labels don't

maybe the solution lies in entity_translation module ?

Also Entityform name is not translatable by any means (other than coding/hacking)
entity form name is used in Title of page it appears in so its useful

RE #8 check out my comment here: http://drupal.org/node/1689854#comment-6514674
Concerning field labels

Also Entityform name is not translatable by any means (other than coding/hacking)

Do you mean the "label"? Entityform types don't have a name.

Also are referring to the title of the submit page? I see the translated label there as the page title

#10 I have translated succesfully the rest of the fields of entityform
but not FILEFIELD labels, i have succesfully translated FILEFIELD labels on nodes

it actually gives me the chance to translate it but after several cache clear and string refresh of translations
admin/config/regional/translate/i18n_string
still not seeing translated labels

#11 each entity form has a NAME and this name is used as TITLE when you visit the entityform URL
but nowhere within drupal configuration I have found a way to translate it

Hi everybody, I have been working on it last day, finally i got an approach.

I made a patch for two modules: i18n_string (http://drupal.org/node/1252144#comment-7389868) and entity (http://drupal.org/node/1973024#comment-7389780)

My principal problem was the instruction_pre wasn't in translatable strings group.

Well, I drop here my patch against updated 7.x-2-i18n branch. Maybe this is not the correct way, but works for me. In first instance, my site is working fine with those changes.

Regards

Hi,

i can confirm that the above 3 patches are working very well.
Would be awesome to see this committed in the dev release soon :)

Thank you for the awesome module :)

Was the patch committed to the last dev version? I'm getting errors while patching the 2013-Jun-14 dev version:

158:entityform Sahaj$ patch -p1 < entityform-Add-fully-translatable-properties-1848018.patch
patching file entityform.admin.inc
Hunk #1 FAILED at 257.
1 out of 1 hunk FAILED -- saving rejects to file entityform.admin.inc.rej
patching file entityform.info.inc
Hunk #1 FAILED at 70.
1 out of 1 hunk FAILED -- saving rejects to file entityform.info.inc.rej
patching file entityform.module
Hunk #1 FAILED at 1296.
Hunk #2 succeeded at 1546 (offset -17 lines).
Hunk #3 succeeded at 1555 with fuzz 1 (offset -17 lines).
Hunk #4 succeeded at 1631 with fuzz 1 (offset -11 lines).
1 out of 4 hunks FAILED -- saving rejects to file entityform.module.rej
can't find file to patch at input line 82

The last patch in #13 was not committed because I believe it requires the other patches referenced in the other projects.

There has been any feedback on the other patches. I just updated those other issues to "needs review" to run testing. Setting this issue too.

Hi all,

i can confirm the patch to work really great.
however there is one little thing that makes an issue :
i want to render entittyform within a panel and as it is entity it is working perfectly but the entityform title it not translated :(
that made me investigate the issue and it seems that the entityform_type actually doesn't has a 'label callback' defined and therefor the title is directly returned.
When i add 'label callback' => 'entity_class_label', to 'entityform_type' defined in entityform_entity_info() then it is working great.
I think that should be correct but wanted to ask if that is correct way :)

Kind Regards,
Dobromir

Seems to me that some strings as 'Your submission has been saved.' or 'Thank you' are not translatable. Is it right?

Edit: May be wrong. I think the way to translate these terms is through the Entityform Types edit page (bottom vertical tabs).

@sahaj if so this is an oversight please provide a patch or file/#line numbers.
Thanks

@tedbow I tried to add t() in the code be wasn't successful.

But is the patch still working with the last version?

Just a note than #13 is working for me as well. I merged the i18n branch against HEAD for 2.x, and resolved a couple of minor merge conflicts, and it seems fine. The other patches in #13 are definitely required as well...

Would be cool to get this pulled into -dev, seems like you could include a note that the entityform_i18n module won't work without those patches to i18n and entity...

@stockliasteroid could you make patch against 7.x-2.x-dev ?

Would be cool to get this pulled into -dev, seems like you could include a note that the entityform_i18n module won't work without those patches to i18n and entity...

The patches would only be needed for formatted text fields like intro text, correct?(its been awhile)

I would up for merging in as long as you could use the unpatched versions of these other modules if you didn't need to translate these properties.

I believe so, yes... The main thing #13 fixed for me was to add instructions_pre as a translatable field, those other patches to entity and i18n are to handle formats.

Changing to needs work because it it needs to be re-rolled

Just want to bump this one up again :-)
Any news?

I've merged branch 7.x-2-i18n with 7.x-2.x and then manually reapplied the patch, cherrypicking the differences. Here's the resulting patch against 7.x-2.x HEAD.
Needs to be reviewed thoroughly.

I also applied patches from https://drupal.org/comment/7776517#comment-7776517 and https://drupal.org/comment/7389780#comment-7389780
Done some more debugging. Patch applies but translatable fields in the entityform are still greyed out.
Changing issue status back to needs work.

@basvredeling thanks for taking this back up.

I have updated the 7.x-2-i18n branch with your patch.

I wish the fix would be made into 7.x-1 branch as well coz I'm quite concerned about any upgrade issues from 7.x-1 to 7.x-2 since my forms are now working well as intended except for the lack of translation. Thanks a lot.

This change is only going to be made to the 7.x-2.x version all the changes in 7.x-2.x can't be backported.

If there are problems with upgrading forms that should be addressed in another issue.

Hi,

my results with the patch:

it applies only against 7.x-2.0-beta2 (2013-Dec-10):

patching file entityform.admin.inc
patching file entityform.info.inc
patching file entityform.module
patching file entityform_i18n/entityform_i18n.info
patching file entityform_i18n/entityform_i18n.module

but not against 7.x-2.x-dev (at this moment 2014-Mar-05)

patching file entityform.admin.inc
patching file entityform.info.inc
Hunk #1 FAILED at 60.
1 out of 1 hunk FAILED -- saving rejects to file entityform.info.inc.rej
patching file entityform.module
Hunk #1 FAILED at 1338.
Hunk #2 succeeded at 1796 (offset 15 lines).
1 out of 2 hunks FAILED -- saving rejects to file entityform.module.rej
patching file entityform_i18n/entityform_i18n.info
patching file entityform_i18n/entityform_i18n.module

Also after the patch I only can translate the label of the form and all other fields (instruction_pre, submit_confirm_msg, submission_page_title etc...) are disabled.

Thanks for the work.

Hi, any progress here? The patch fails to apply also against 7.x-2.0-beta3 (2014-Mar-27)

26: entityform_i18n-1848018-26.patch queued for re-testing.

Tried to re-roll the patch against latest HEAD of 7.x-2.x.
I'm sure, this isn't the best way to implement i18n support but it works for us ;)

@stBorchert, thanks for doing this!

I'm sure, this isn't the best way to implement i18n support but it works for us ;)

So does mean this is strictly a re-roll of the previous patch or did you rework functionality?

> So does mean this is strictly a re-roll of the previous patch or did you rework functionality?

Hm, I would say "both".
I applied the patch from comment 26 and added/reworked some stuff.

@stBorchert could you explain what you have added/reworked or provide an interdiff?

When you say

this isn't the best way

Are you referring to your additional changes or the patch in general?

@tinkalink

Can you explain how did you translated the field labels?
I'm struggling to find the way to do this without hacking it via the hooks or templates.

Are you using Entity_translation or i18n?

Hi,
I tested this patch on my local project and works fine. So I export the configuration (with the features) on my production site. After this job, I import the .po file for translate the string of the entityform and so it's good.

BUT when i do another revert for the features that's include the enitytform configuration, it overwrites the old translated string that I imported before (with watchdog: delete old string (translated) and create new string (not translated)).
So, I import again the .po file for works again.

it's possible to fix?

@axelpezzo, I am sorry I don't know how this is suppose to work.

If we are going to Entityform translatable we are probably going to need someone working on this issue who know more about the translation system.

There seems to be an issue with #36 where the entityform_type->get_prop() function is double-encoding the translated plain-text fields. Any properties with a text-format set seem to work fine, though. This can be seen by adding an apostrophe to the language translation.

I had to modify the following line to the getTranslation function in entityform.module from:
return entity_i18n_string($name, $property_value, $langcode);
to:
return html_entity_decode(entity_i18n_string($name, $property_value, $langcode), ENT_QUOTES);

This basically reverts the encoding so that entityform can do it's own encoding afterwards. Patch files to follow.

If you haven't applied any of these patches yet, just apply entityform_i18n-8809303-43.patch.

If you have already applied patch #36, use patch-from-36-to-43-entityform_i18n-8809303-43.patch as it was made for people who have ALREADY applied patch #36, to try to make their lives easier.
(EDIT: Use the version in #46. I had to fix the paths. It failed because it's comparing it to the master, which hasn't applied patch #36, obviously) If the owner or someone could clean this up, that would be great. Sure wish I didn't suck at submitting patches!

Patch applied cleanly against beta3, field translation works but i'm unable to translate form title. i

Looks pretty good. I just found some nitpicks on a mainly visual review.
Functional review will be done the next days.

1. +++ b/entityform.info.inc
   @@ -62,6 +62,25 @@ class EntityformTypeMetadataController extends EntityDefaultMetadataController {
   +      // Testing if this will allow property to be transalted
   

   Typo translated

2. +++ b/entityform.info.inc
   @@ -62,6 +62,25 @@ class EntityformTypeMetadataController extends EntityDefaultMetadataController {
   +      // @todo remove flag all formatted properties
   

   Inline comments must end in full-stops, exclamation marks, or question marks.
   And I'm not sure if I understand the todo.

3. +++ b/entityform_i18n/entityform_i18n.module
   @@ -0,0 +1,93 @@
   + * Profile2 i18n integration module via entity API i18n support.
   

   Copy paste leftover.

Did some further testing. Functionality seems to work pretty good so far.
Some remarks:

• Is there a reason why we use entityform_i18n_entity_property_info_alter()?
  I don't think it's worth the overhead introducing an own flag entityform_i18n and then use the alter hook to convert it to what's needed by the entity i18n integration. Why not set translatable / i18n string straight in EntityformTypeMetadataController::entityPropertyInfo()?
  So far it's just one location where that has to happen and we could save the overhead of triggering an alter hook.
• I think we should enhance the documentation of EntityformType::getTranslation() - we change the original implementation from Entity, why?
  Also this line raised question marks on first sight: html_entity_decode(entity_i18n_string($name, $property_value, $langcode), ENT_QUOTES)
  Why do we've to do our own encoding?

Is there a working patch out?

Re-rolled patch.
Just found one issue during our tests.
When using with a install profile it could lead to notices - added more defensive code to cover that case.

Hi,

Is the patch in #52 versus beta4 or is it versus the seperate branch itself? It applied without errors on beta4, but I have the disabled text boxes again. Any idea how I could solve that?

@pieterdt I haven't test this patch yet but usually the patch is versus the Version that issue itself is set to, in this case 7.x-2.x-dev which is 7.x-2.x branch

Goodmorning,
patch #52 applied but I can't translate entity form name (and so entityform title), only "Intro form instructions". Any suggestions?
Thanks!

Any suggestions?

@enrik4drupal The only thing I can think of is a string refresh: admin/config/regional/translate/i18n_string

Patch #52 re-roll against latest dev snapshot

Entityform name is not translatable yet

Can somebody either update the summary or leave a comment about how to test this?
Other modules needed? Configuration of them? Anything else I need to do?

What is working? What not to expect to working?

Also require a specific version of Entity API or other modules? Need patches against those modules?

I would like to review this patch and get this committed but it has been a long since I delved in here.

Thanks!

Ok, so lets get it done then :)
I updated the issue summary too

Solution

Proper integration with i18n_string module

Usage

Dependencies :

1. a multilingual website with at least two enabled languages :)
2. entity api module
3. i18n_string module (part of i18n module)
4. entityform latest dev snapshot with patch #57 applied

Configuration :

1. Enable entityform_i18n module
2. Go to admin/config/regional/translate/i18n_string and select entityform and refresh strings

Usage :

• Either open admin/config/regional/translate/translate and search and translate any entityforms related strings
• Or open admin/structure/entityform_types and click on the translate link for any entityform you wish to translate

Known problems :

• Entityform name is translatable but entityform submission page title (page title in browser tab) still appears untranslated
• Formatted text are not translatable #1973024: Does Entity i18n integration support Text Formatted properties properties?

So, how can we address:"Entityform name is translatable but entityform submission page title (page title in browser tab) still appears untranslated"? It seems to me that this is not limited to entityforms. From what I'm seeing, similar page titles are not translated on other entities (including nodes).

Updated patch against latest dev.

I hope this issue gets solved soon. I managed to translate the field labels using Entity Translation module while using Entityform 7.x-2.0-rc1. I also translated the field options with this method. However, I need to translate the title and the submit button label too. I look forward to a working patch.

Let's try again...
@rcodina it should solve your problems.
Please test it.

@yogaf Ok, I will let you know the results

Hi @yogaf. I already tried your patch. My feedback is the following:

1) I managed to translate the submit button label thanks to your changes. However I'm not able to do the same with the form title. How can I do that?

2) Under translation tab of an entity form, all the languages already translated have the link of the final column as "translate" instead of "edit". The label must be changed once a translation is set up. The rest of the feature works fantastic (See bug_edit_button.png for more info).

3) Inside translation page, I miss my wysiwyg. In my case I use the CKeditor module. I think this is a must have, if the rich editor is not present you can mess up the content of your text fields (See missing_wysiwyg_edit_translate.png for more info).

Keep up the good work. I think once this issue is closed, this module would deserve a new release ;)

Moreover, I just found out that every time I change the language of the site via the language dropdown, it concatenates "?ulang=1" to the browser url. So you end up with a URL like www.yoursite.com/es/eform/submit/url-of-your-eform?ulang=1?ulang=1?ulang...

EDIT: Forget this. This is due to a custom module. Not this module fault.

Regarding my points 2 and 3 on comment #67, I just found out that the behaviour is the same while translating taxonomies with the i18n_taxonomy module. So it's not your patch fault. I guess it's drupal core behaviour.

Setting to needs review

@yogaf, what's the difference between patch on #70 and the one on #65?

@yogaf, what's the difference between patch on #70 and the one on #65?

Hey rcodina, no difference.
Sorry for the confusion, the patch from #65 wasn't tested by simpletest so I tried again.
On #67.1 - I can translate the "Submission page title", is that what you're looking for?

@yogaf, what I can't translate is the entity form title (look at entity-form-title.png). As a workaround, I have done a simple custom module which implements hook_form_alter. Inside the hook I call:

drupal_set_title(t('English version of my title'))

Re-rolled patch.
Contained some seriously malformed code.
Further 'submission_page_title' => t('Thank You.'), was duplicated in EntityformTypeController::get_text_labels().

Oh, patch lost :)

Manually removed \r - looks like somehow I messed up creating the patch...

Hey everybody thanks for all your work on this. I finally got back to testing this out.

It seems to work great. A couple things I noticed. I don't know if these are fixable with the way i18n works

1. Values such as Form Overrides section that don't have value for the original can't be overridden translation. I am not sure if this would actually be needed(would some want to do this? edge case?)
2. I couldn't figure out how to translate the default entityform type values at 'admin/config/content/entityform'. I was thinking I had to turn on i18n_variable but that didn't work. Would we have to implement variable module hooks into entityform to make this possible?

Thanks

This works with Entityform 7.x-1.x-dev ?
I can't use Entityform 7.x.-2.x-dev because I have this issue: https://www.drupal.org/node/2188579

@giupenni: No this is a patch for 2.x

Damn :-(

Thank you.

+++ b/entityform.module
@@ -1314,18 +1361,37 @@ class EntityformTypeController extends EntityAPIControllerExportable {
+      'instructions_pre' => '',

This must be in singular.

---

For instruction_pre with plain_text format, string is passing twice through check_markup(), producing a result like

<p>&lt;p&gt;{translated string}&lt;/p&gt;</p>

Whereas for the original string the outputted html is

<p>{original string}</p>

In i18n I've traced the code until i18n_string_format(), where a check_markup() happens, but I wasn't able to trace entityform to the point where the second check_markup() happens. Even If I supress format in the result of $entityform_type->get_prop('instruction_pre'), it is producing a scaped p.

Attached a patch that fixes #84. Attaching also an interdiff for clarity.

ps - i18n_string() sanitizes by default. entity_i18n_string() is a wrapper of it that doesn't allow to pass options to i18n_string().

So the way its working with the field translation is to let the title exchange to a field with the title module. So the title then can be placed in the window title aswell. Wouldn't work this the same way here? Meaning to allow the title variable among the field managing config. And then you could do the exchange the title with the title module once again. Obviously you can hide the title with panels but you will still have them in the window title i think.

This still needs work. I'm getting this notice, and the untranslated text doesn't show up when there's no translation.

php  Notice: Undefined variable: default in EntityformType->getTranslation() (line 1214 of /var/www/project/htdocs/profiles/iao/modules/contrib/entityform/entityform.module). 

Was just working on that.

Some fixes needed, and added the Label to be translated, 'cause I needed that.

Changes are against #85

Patch applied, the translations are correctly set. I did not see any error currently.

Everything works perfectly with #88

+ RTBC from me

Committed!!!!!! Thanks everyone for all your hard work and feedback!!!!(this all comes out of the box in D8 right?)

whoops, sorry @das-peter meant to credit you with authorship(no offense @Lendude) since you provide most of the code. but I got it wrong.

@tedbow Yeah no way I deserve author credit for this, great to see it in though, thanks!

thanks everyone, great work

Thanks for getting this in.

@tedbow No worries, I'm not here to horde credits but to get sh*t done :D So absolutely fantastic this got committed. Thanks all!

I figured out that this patch breaks the the Entityform Type: Label (Form Type) View field. It may have broken other things but haven't any.

I think the problem is that EntityformTypeMetadataController::entityPropertyInfo() was overriding all the property info from the parent class(from Entity API)

I attached a patch that merges that instead if it exists.

Please let me if this works.

I can confirm that this patch makes that field available (and functional) in Views. That led me to try and pull in the translated label into my VIews config and I couldn't figure out how to do that - am I opening up a can of worms here?

I don't have much insight on the Views translation. If someone knows that would be great.

Otherwise since the main patch is already I would like to get more reviews for my patch in #99. I would like a few more eyes to determine it doesn't break anything else.

Patch in #99 Fixes the Views problem outlined. I can't find any other issues at the moment, but only tested on very minimal installs, so can't speak for more complex implementations.

On the translated label in Views: thats not gonna work with the i18n_string implementation that is currently used (no way to join that data to the View at the moment, and no 'easy' way to implement that I see).

I'd have to test it out, but maybe the string translation would "just work" within views in a multilingual context..

Doesn't look like it.. Oh well - that's another issue for another day :-)

Doubtful, because you want to show the translated values in this case. So either the i18n_string table needs to be joined to the views query (unlikely cause it's not a very simple join), or the handler would need to translate the value during rendering (unlikely because of overhead and lack of proper context).

So to do this there might be a couple of ways to go (add a relationship handler to add the translations, add a language field to the entityform_type table and go with that, switch the entityform_type settings to Fields and use i18n_field for the translations). No idea how viable any of these options are, but at the very least they are all a lot more work then the current solution :-)

Upgraded to 7.x-2.x-dev 2015-Mar-28

ran
drush updb
drush cc all

going to
.../eform/submit/XX

gives
Fatal error: Call to undefined function i18n_string() in .../sites/all/modules/entityform/entityform.module on line 1221

Oops, no check if i18n_string module exists!

Add something like this? Patch rolled against current Dev.

Thanks! Patch at #107 fixes the issue at eform/submit/XX

Simply combined patches from #99 and #107.
Both changes look good to me and tests where successful, I'm bold and say RTBC.

Thanks for adding this patch. Should get this committed as soon as possible... 2.x-dev is unusable without it! (if i18n is not enabled...)

Committed, thanks!

Back to fixed.
Of course the patch can't be applied if already committed. Not sure why this is re-tested over and over again :|

does 7.x-2.0-dev really translate the field label? I have installed the dev version, enabled the entityform_i18n module, and follow the steps, But in translation interface I don't see the field label to translate, Any thoughts ?!

@developermitesh this issue is for translating entityform properties. You can translate field properties with i18n or Localize Fields. If using i18n I'd recommend adding Translation fallback to the cocktail.

Answering #80, yes it would be great to be able to translate Form Overrides, really.

Answering myself, Form Overrides translation works now. Awesome! Thanks!!

Installed the current 7.x-2.x-dev version. Translation works fine. So let's go to 7.x-2.0-rc2 ;-).

Please test out 7.x-2.0-rc2 which this commit in it. see #2480587: Test 7.x-2.0-rc2 so that it can be released.

Report any problem or successes there.

Thanks

For me translating of the form titles and the labels (like submit, success, etc.) works fine with RC2.

Everything works perfectly with #88 and #109

Entity Forms: Version: 7.x-2.0-rc1
Drupal 7.50

Very very cool.

@cmseasy, can you confirm that you enabled the entityform_i18n submodule. As noted above rc1 should work.

You should see the text group 'Entityforms' here: admin/config/regional/translate/i18n_string.
Try to refresh that group.