Add a langcode parameter to EntityInterface::label()

Related issue: #1629924: Default return value from EntityInterface::label(), Entity::label(), entity_label() does not match

Should i add the $langcode parameter to 'user_label' too?

I just RTBC'd #1616952: Add a langcode parameter to EntityInterface::label(), which removes/renames the entity_label() function, not sure if entity_page_label() needs the langcode as well. If not, we could simply remove it from this function and then they wouldn't conflict.

+++ b/core/modules/entity/lib/Drupal/entity/Entity.phpundefined
@@ -89,13 +89,14 @@ class Entity implements EntityInterface {
     if (isset($entity_info['label callback']) && function_exists($entity_info['label callback'])) {
-      $label = $entity_info['label callback']($this->entityType, $this);
+      $label = $entity_info['label callback']($this->entityType, $this, $langcode);

I guess this needs to be documented somewhere and the existing label callbacks, if we have any (?) should be updated.

Wrong reference, I of course meant #1615240: Remove entity_label() in favor of EntityInterface::label()

I think $langcode on entity_page_label() is still useful. Rerolled against 8.x HEAD after #1615240: Remove entity_label() in favor of EntityInterface::label() was committed.

We should document the additional argument to the label callback documentation in hook_entity_info() and update the user_label() and field_test_entity_label_callback().

Is there already an issue to remove entity type from the callback? If not then we should remove it. Or, can we somehow integrate a defaultLabel() method to the entity class, similar to 7.x contrib entity class. (Separate issue, of course).

Adding a $langcode to user_label() makes no sense because the username is not a multilingual property. Updated field_test_entity_label_callback() and documentation.

Hm, yes, but user_label() is a callback that receives a pre-defined list of arguments. IMHO the function definition should match to what it is called with. However, I don't want to decide that, who can we ask who can? :)

+++ b/core/modules/entity/entity.api.phpundefined
@@ -42,15 +42,17 @@
+ *   - label callback: (optional) A function taking an entity and langcode as
+ *     argument and returning the label of the entity. The langcode is
+ *     optional. If langcode is omitted, the entity's default
+ *     language is used. The entity label is the main string associated with
+ *     an entity; for example, the title of a node or the subject of a
+ *     comment. If there is an entity object property that defines the label,
+ *     use the 'label' element of the 'entity keys' return value component to
+ *     provide this information (see below). If more complex logic is needed
+ *     to determine the label of an entity, you can instead specify a
+ *     callback function here, which will be called to determine the entity

It looks like there is a lot of empty space on various lines. Should be able to group that differently, as we need to change it anyway, as it seems. E.g. "The langcode is optional" should fit on that line without going over 80 chars.

We discussed the usage of user_label() at drupaldevdays. We (xjm, webchick, heyrocker, me) reached consensus that the username is not a multilingual property. The username is the visual identifier for a user and needs to be consistent in all languages. Therefor $langcode is not required.

Ok, looks good to go then. Not exactly sure what the "security reasons" comment exactly means.

I fully agree that the user name is not translatable. That wasn't my point. My point was only that this is a callback function, which receives a fixed set of arguments, and the function definition should reflect that. The implementation within is free to ignore the language of course. Doesn't matter much.

Sorry, by "security" I meant more "identity." Your username is the only way (in core anyway) to canonically identify YOUR comments/posts on the site to YOU. It's fully conceivable that Drupal.org has both a "sun" and a "sol" user. sun's comments should not get misattributed to sol when the user chooses Spanish as their language.

#11: add-langcode-to-EntityInterface-label-1616952-11.patch queued for re-testing.

Test is green. Back to rtbc.

Looks good! I just made a quick tweak to the docs to consolidate them a bit:

from...

+ *   - label callback: (optional) A function taking an entity and langcode as
+ *     argument and returning the label of the entity. The langcode is
+ *     optional. If langcode is omitted, the entity's default language is used.
+ *     The entity label is the main string associated with an entity; for

to...

 *   - label callback: (optional) A function taking an entity and optional langcode 
 *     argument, and returning the label of the entity. If langcode is omitted, the *     entity's default language is used.
 *
 *     The entity label is the main string associated with an entity; for

Committed and pushed to 8.x. Thanks!

This needs a change notice.

Improved and extended http://drupal.org/node/1642962 so that it also covers this change.

Great!

We discussed the usage of user_label() at drupaldevdays. We (xjm, webchick, heyrocker, me) reached consensus that the username is not a multilingual property. The username is the visual identifier for a user and needs to be consistent in all languages. Therefor $langcode is not required.

HOWEVER, user_label() eventually invokes drupal_alter('user_format_name') which is typically used by Realname module. When performing token replacement, we would want to know which langcode the username is being used as since we could provide the langcode for tokens. There *is* an actual valid use case for this.

Hm, there is actually even a much more obvious use case here: t('Anonymous').

Yep, that's the more obvious one too.

Done, moving off sprint.

This change has caused XSS by default in D7 templates being ported to D8. See #1811684: XSS: Bartik's node.tpl.php prone to XSS (prints $title).

So now let's remove this :D #2142979: Entity label langcode argument is a lie, incompatible with current API.