Support translations [#2241429]

I think #2044415: Proper language/translation support is probably also something we should implement before we move this to the proper Search API project. Basically, it's just about making the functionality of Search API ET the normal behavior of the content entity datasources integrated into this module – i.e., instead of providing one "search item" per entity, we provide one per each translation of an entity. Item IDs would then therefore change to a tupel of entity IDand language – e.g., "1:en", "1:de", "2:en", …

I was previously unsure whether to do this in this module, or just provide a sounder basis for Search API ET, but talking about it in Szeged nearly everyone agreed that the Search API has to support translations by default. In Drupal 8, everything else would be a bug, not just a missing feature.

One thing we could add then, too, is a config option for datasources stating which languages should be indexed. But this can of course also be added later (even post-release, in theory), more important is the basic functionality.

What we will also have to add again is the search_api_language field – this time as a processor, though, which we'd hard-code as always enabled for now (until we have a flexible system for doing that – see #2090341: Add a way for marking fields/processors as "locked" or "hidden").

Comment	File	Size	Author
#8	2241429-followup.patch	991 bytes	amateescu
#5	2241429-test.patch	9.81 KB	amateescu

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

drunken monkey

he/him

German

Vienna, Austria

CreditAttribution: drunken monkey commented 28 April 2014 at 14:56

Issue summary:

View changes

Comment #2

drunken monkey

he/him

German

Vienna, Austria

CreditAttribution: drunken monkey commented 30 April 2014 at 10:14

Assigned:

Unassigned

» drunken monkey

I'm going to work on this today. First going to start with the processor, I think.
We also want to add setLanguages() and getLanguages() methods for the query.

Comment #3

drunken monkey

he/him

German

Vienna, Austria

CreditAttribution: drunken monkey commented 30 April 2014 at 19:33

Assigned:

drunken monkey

» Unassigned

OK, I finished the "Item language" processor, along with its hard-code "required" hack and tests, as well as having one search item per translation of an entity.

Missing still are tests for the latter, and a "languages" setting for the content entity datasource (as well as tests for that).

Comment #4

amateescu CreditAttribution: amateescu commented 1 May 2014 at 10:08

Assigned:

Unassigned

» amateescu

Working on those tests.

Comment #5

amateescu CreditAttribution: amateescu commented 1 May 2014 at 13:02

File	Size
2241429-test.patch	9.81 KB

Committed the test attached for the "one item per entity language functionality", which already found a bug :)

Comment #6

amateescu CreditAttribution: amateescu commented 1 May 2014 at 13:14

Assigned:	amateescu	» Unassigned
Status:	Active	» Fixed

Since the issue summary says that the 'languages' setting for the content entity datasource can be added later, I guess the main scope of this issue is done so I'm going to mark it fixed and open a non-"move to home repository" blocking followup for it.

Comment #7

drunken monkey

he/him

German

Vienna, Austria

CreditAttribution: drunken monkey commented 1 May 2014 at 14:16

Thanks a lot, great work, and good thinking on the new issue!
Just one question:

+++ b/search_api.module
@@ -94,12 +94,12 @@ function search_api_entity_update(EntityInterface $entity) {
     foreach ($updated_item_ids as $i => $langcode) {
-      if (!isset($old_translations[$langcode])) {
+      if (!in_array($langcode, array_keys($old_translations))) {

Can these translation objects ever be NULL? Or what is the difference here?
In any case, I guess array_key_exists() would then be the better option.

Comment #8

amateescu CreditAttribution: amateescu commented 1 May 2014 at 15:04

Component:

Backend

» Framework

File	Size
2241429-followup.patch	991 bytes

Nope, those objects can never be null :)

The problem there was that we should've been checking the values of those array, not it's keys. (the keys are numeric, the values are langcodes). Committed this small patch to try and make things a bit more clear.