DX / efficiency for accessing the "default langcode" of an entity [#2142603]

Spin-off from #2076445: Make sure language codes for original field values always match entity language regardless of field translatability

EntityInterface explicitly doesn't have a defaultLanguage() method, only a language() method

As @plach explains #2076445-75: Make sure language codes for original field values always match entity language regardless of field translatability (last section of the comment) that is in order not to confuse developpers with "ok, so which one should I use ?".
For the vast majority of use cases, the answer is "just use language(), you shouldn't bother with defaultLanguage() or your code will likely wok in monolingual setups but badly break in multilingual envs"

Yet there *are* some specific cases in core that need to access the default language of an entity, and the only way currently is:
$entity->getUntranslated()->language()->id
- really unfriendly (but according to the above that's more a feature)
- efficiency seems problematic ?

Comment	File	Size	Author
#2	getUntranslated-2142603-2.patch	648 bytes	yched
#2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Berdir

German

Switzerland

CreditAttribution: Berdir commented 24 November 2013 at 09:05

Performance depends on how often you call it, but in any way, we already have an object, so getUntranslated() checks if it's the default language and just returns itself if yes, otherwise falls back to the existing default language object. So unless we call it *a lot*, I don't think we need to worry too much about it.

Comment #2

yched CreditAttribution: yched commented 24 November 2013 at 09:58

File	Size
getUntranslated-2142603-2.patch	648 bytes

Hm - makes sense I guess...

Looking at the actual methods code then, I don't think getUntranslated() should have $this->translations[$langcode]['entity'] logic, this should stay internal to getTranslation().

Patch attached.