No way to specify the language to view entities in

@marcvangend:

So this is only the API change, nothing is really done with the $langcode yet, right?

Yes, in core the view API functions don't need to specify the language as they are used only in page contexts. But, for instance, Simplenews would need to specify the language a newsletter is being sent in.

The @param $langcode documentation does not specify what kind of value $langcode should be. I assume this must be equal to $language->language in the language object, but can you make the documentation clearer?

Yes, the parameter is a language code string. Everywhere in core we use a $language parameter to indicate a language object and $langcode to indicate a string holding a language code. I copied the parameter docs from Field API's ones, so if we change these we need to sync the documentation elsewhere (in a followup issue).

@Damien Tournoud, @steinmb:

This is very important, but not critical. Downgrading to major

If we have to do API changes is not this a betablocker an perhaps also critical?

Honestly I was tempted to mark this as a critical beta blocker, because I think after the first beta we won't have API changes (even API additions) at all. If this is not the case I agree this is major, otherwise this is a critical beta blocker issue that if not committed will render many use cases hard, if not impossible, to implement.

Improved PHP docs as per @marcvangend's request.

If we pass $langcode into the $build arrays for consistency we need to pass it along for hook_*_view() invocations. Updated API documentation files accordingly. Moreover we cannot rely on field_attach_view() default but we have to explictly provide one.

Here it is :)

rerolled...

Thanks sun!

I still think this should go in before the beta release. Setting to critical again in the hope to getting a committer feedback.

Just to be sure this gets the needed attention in time, I'm marking it as beta blocker: as its status is RTBC committers just need to get it in or moving it back to the major queue if this can be committed later.

@Damien Tournoud:

Having a partially broken core subsystem that we won't be able to fix after the beta release IS a critical issue. This is not going to block anything, as it's RTBC, so what's the problem?

Preventing committers to evaluate this before it's too late is not helping making Drupal better.

Dries and webchick are following the priority order and are going to care about beta blocker critical issues first. The fact that they'll give a look at this after beta has been released does not mean they are not maintaining the major queue, it just means that they are following priorities.

IMO an issue that has to go in before beta is released meets the definition of beta blocker: committers might judge it not worth to be committed but they must have the chance to evaulate it for the priority it has.

I'd say this is a major beta blocker if this definition makes any sense.

@Dries:

Thanks!

@Damien, @catch:

I apologize for misusing the beta blocker tag and for being somehow harsh, I didn't know about the Needs commiter feedback one. I'll be more careful next time :)

Related issue: #1089174: Prepare view hooks do not receive the language parameter.

Related issues:

#1178480: field_view_field() does not pass language to hook_field_attach_view_alter() implementations (easy one)
#1178500: hook_field_*() prepare/view have no access to the requested language (yched's feedback welcome)