We should assist exportable entities with supporting localization via i18n. We can generate quite some i18n-info automatically, although probably not all. Let's add a helper which at least cares about adding in all the translatable properties...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

Status: Needs work » Needs review
FileSize
4.83 KB
1.87 KB

ok, here some WIP.

Attached patch basically works to expose properties to i18n. I'm also attaching my test-profile2 integration module to show how it can be used. Making using translated values is still an open issue though.

important fix: #1406778: impossible to expose entities to i18n string translation

fago’s picture

*dup*

Status: Active » Needs work

The last submitted patch, entity_improve_rebuilding.patch, failed testing.

fago’s picture

Status: Needs review » Needs work
FileSize
5.98 KB

that's the right patch...

fago’s picture

Status: Needs work » Needs review
Issue tags: +Needs tests
FileSize
6.21 KB
10.37 KB

ok, I've further improved it - so far profile2 integration seems to work fine.
Changes:

  • Added helper functions entity_i18n_string() and $entity->getTranslation($property).
  • Added support for getting translated values via the wrappers. (left out write support for now)
  • Properly added in the "translation" tab of i18n.
  • Lots of random improvements and fixes.
  • Added some docs to the controller class. entity.api.php docs are todo.
  • Completed profile2 integration to incorporate translated values in a backward compatible way.
  • Tests are todo.
fago’s picture

Ok, I've completed this. Thus,
* added i18n integration to the entity-test-type and tests
* integrated a "translation" link in the UI
* completed docs
* some random fixes
* also I've implemented rules-link i18n integration based on that, example patch attached.

Status: Needs review » Needs work

The last submitted patch, entity_api_i18n.patch, failed testing.

klausi’s picture

Looks good from a purely visual code review.

fago’s picture

ouch, looks like the test-bot dies due to not caring about the i18n dependency of the test-case. I've modified the test case to not extend the i18n class, hope this helps.

Also, I've update the rules-link patch to correctly document method overrides (we are not overriding self::).

fago’s picture

Status: Needs work » Needs review
fago’s picture

Component: Entity CRUD controller » Documentation
Status: Needs review » Active
Issue tags: -Needs tests +Needs documentation

As the i18n translation set fix got committed and this works well for quite a while now, I've committed the patch from #9.

Setting to active, as it requires documentation.

fago’s picture

I've also committed the profile2 patch and opened #1446604: Add i18n support for rules_link.

fago’s picture

Status: Active » Fixed
Issue tags: -Needs documentation

ok, added docs - see http://drupal.org/node/1021538

Status: Fixed » Closed (fixed)

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

Patrick R.’s picture

Component: Documentation » Code - misc
Status: Closed (fixed) » Needs work

Profile2 integration seems to be incomplete. In profile2_user_view (profile2.module) there is this line...

'#title' => $profile->label,

I think this should be

'#title' => $profile->defaultLabel(),

at least it's only working for me this way. Also on /user/#UID/edit/* the secondary tabs representing the Profile2 types next to ´Account´ aren't translated as well. In profile2_user_categories we have

'title' => $info->getTranslation('label'),

for this but I think this is rather useless since user_menu specifies check_plain as title callback for these items, so there is no l10n support. It is probably necessary to implement hook_menu_alter for Profile2 to override the secondary tabs items and replace title callback and title arguments.

mitchell’s picture

Status: Needs work » Closed (fixed)

@#15

Issues that have reached [closed (fixed)] should typically not be reopened, but instead a new issue should be opened, providing a link to the closed issue.

-- Status settings for an issue

fraweg’s picture

Hello,

for me zhis issue is not fixed. How to I translate "/user/#UID/edit/*" ? I can not do that.

Thanks for any Help!
Best regards
Frank

andrea.brogi’s picture

FileSize
40.29 KB

Hi Guys,
I don't know if this is the correct discussion to put my questio.
I have a problem with translated version of e-commerce site.
The problem occurs when I update the Enty API from RC1 to RC2 and looking inside Release Note I've seen that this post and this one http://drupal.org/node/1376126 have worked to translation. So I have put this messagge also inside the other Isuue.

One yers ago I have developd an e-commerce site using Commerce Drupal.
The products have some "Term Reference" fields connected with a "Localized Vocabulary" (Not Translated).
All the products are translated and they show the correct terms when we shitch Language.
A group of Products is connected to a "View Node" using "Product Reference" field so we can have "Variation of products" showed inside the "Node View" with some "Select List".
Using the entity API version RC1 evrything was working correctly. When switch the lanuage the terms inside the select list was correctly translated.

If I update to RC2 instead the terms inside the "Select Field" are not translated. I have checked the product and the terms inside translation page but nothing is changed, the terms are correctly translated. Also in the Node View If I show the referenced terms like link the terms are translated. Only Inside "Select Field" the terms are wrong.

Someone of the guy have make this isuue can understand was it happen and help me to solve this problem?

You can test live this sistuation here
http://www.m2r2-comunicazione.it/en/node/26

This is a clear installation with the latest version of Drupal-Commerce-EntityApi.
If I come back to the RC1 of entityApi the system work correcly.