Add i18n support

The property 'mail.notify.results' gets correctly exposed as translatable text, but the translation isn't applied in emails (as far as I can see there is some token replacement magic)

rerolled fago's patch that fixes the token replacement for results/result and added support for the new description setting.

Great patches, thanks! And sorry it took me so long to get back to you …

The code looks very good to me, and I also trust that it'll work. However, I don't like directories as well as module files to be too cluttered, so I moved the files into a subfolder and the two new classes both into its own file. I hope that's OK.

+++ b/search_api_saved_searches.settings_entity.inc
@@ -69,4 +69,38 @@ class SearchApiSavedSearchesSettings extends Entity {
+      $name = $this->entityInfo['module'] . ':' . $this->entityType . ':' . $this->identifier() . ':' . $property;

This seems to me to be a bit risky. I guess you only use this as a shortcut to the module name and entity type instead of typing it out?
Even though it's unlikely, another module might change the entity type info, and later on you explicitly use "search_api_saved_searches:search_api_saved_searches_settings:", which might then stop working.

Not very likely, I admit, but I still corrected that. Unless it was on purpose, in which case please explain the benefit you see!

Please quickly re-test the patch, then I can commit it. Thanks again for your work, both of you!

Quickly retested your patch, everything still seems to work.
Directly using the module name and entity type as identifier is ok for me, although I like the original one more, as it is easier to read and I don't expect someone to change that part of the entity info.

Found one bug by accident: reverting the settings will delete the translations (caused by search_api_saved_searches_i18n_search_api_saved_searches_settings_delete()). This is something that we definitely don't want.

One more problem: configurations like the email activation body allow HTML, but when translating it, the text gets escaped.
The problem goes back to entity_i18n_string(), as it does not allow to pass the sanitization options that i18n_string() allows. Of course we could directly invoke i18n_string with custom parameters in SearchApiSavedSearchesSettings::getTranslatedOption(), but IMO fixing entity_i18n_string() would be better.

Found one bug by accident: reverting the settings will delete the translations (caused by search_api_saved_searches_i18n_search_api_saved_searches_settings_delete()). This is something that we definitely don't want.

Ah, yes, thanks for spotting that!
The CRUD hooks for exportables are a bit of a nightmare … But maybe some day #1643184: Invoke insert hook on existing entities on revert will get in.

As for now, it should be fixed in the attached patch.

One more problem: configurations like the email activation body allow HTML, but when translating it, the text gets escaped.
The problem goes back to entity_i18n_string(), as it does not allow to pass the sanitization options that i18n_string() allows. Of course we could directly invoke i18n_string with custom parameters in SearchApiSavedSearchesSettings::getTranslatedOption(), but IMO fixing entity_i18n_string() would be better.

OK, so would you say we should just commit this regardless, or wait for that fix in the Entity API?

Concerning the text formats: is HTML allowed for all translatable properties, or only for some specific? If only for some specific, we would need some kind of declaration of the text format for each property.

As we are already implementing SearchApiSavedSearchesSettings::getTranslatedOption() we could directly invoke i18n_string() instead of entity_i18n_string() and pass the according filter options. We can also discuss it in the Entity API issue queue, I'm not sure if there are any other hurdles in the Entity API i18n classes.

Out of the box, I guess none of the translatable properties are HTML. However, I check_plain() the description manually, and for the mails HTML-escaping the text doesn't make any sense either. So I guess we should tell I18n not to sanitize any of them.

for me that's RTBC :-)

Although, there is one thing missing:
The property mail.notify.results_capped is not registered in SearchApiSavedSearchesSettingsI18nController::translatableProperties()

OK, fixed that and committed.
Thanks for testing and your work, also to fago!

Thomas, I'm not sure if you committed the right patch ;-)
According to the git diff (http://drupalcode.org/project/search_api_saved_searches.git/commitdiff/a...), we have:

+/**
+ * Implements hook_search_api_saved_searches_delete().
+ */
+function search_api_saved_searches_i18n_search_api_saved_searches_settings_delete($settings) {
+  i18n_string_object_remove('search_api_saved_searches_settings', $settings);
+}

According to #9, it should be:

+
+/**
+ * Implements hook_search_api_saved_searches_delete().
+ */
+function search_api_saved_searches_i18n_search_api_saved_searches_settings_delete(SearchApiSavedSearchesSettings $settings) {
+  if ($settings->hasStatus(ENTITY_IN_CODE)) {
+    i18n_string_object_update('search_api_saved_searches_settings', $settings);
+  }
+  else {
+    i18n_string_object_remove('search_api_saved_searches_settings', $settings);
+  }
+}

Oops, you're right. Should be fixed now.
Thanks a lot for noticing!

Sorry to reopen this shortly for a question: I can't find a way to translate the email texts (variables). i18n, variable translation etc. (realms) is enabled but the variables do not appear. Is this a mistake on my side or are the notification email texts not yet translatable?