No get equivalent for language_attributes()

[PeterRKnight]

In core most functions that can output a string call a function that returns a string instead of returning it. The language_attributes() function is an exception to this and always echoes a string. I was expecting there to be an equivalent get_language_attributes() function that returns a string instead.

I ran into this need while coding conditional IE fallback code for the opening HTML tag. Rather than call language_attributes() multiple times, I wanted to store the attributes in a string. The current workaround is either using output buffering or simply calling language_attributes() multiple times, both of which are undesirable because it adds unnecessary operations. It also imposes a limitation in how a developer may choose to output html.

I propose adding get_language_attributes() for consistency and flexibility purposes.

[PeterRKnight]

patch adding get_language_attributes() and modifying language_attributes()

[obenland]

Not sure if I18n would be a more accurate component for this.

[posykrat]

Patch inspired from @PeterRKnight PHP file

• created get_language_attributes function with original language_attributes function code without echo
  
• language_attributes function call now get_language_attributes and echo result

[johnbillion]

This makes sense. Let's do it.

28180.diff​ corrects the language_attributes.28180.diff​ patch, improves the docs, and also adds $doctype as a parameter to the language_attributes filter.

[wonderboymusic]

In 32868:

Add get_language_attributes(), which is then used by (...drum roll...) language_attributes().

Props johnbillion, posykrat, PeterRKnight.
Fixes #28180.

[DrewAPicture]

In 32882:

Add a changelog entry to the DocBlock for language_attributes() noting that it was converted into a wrapper for get_language_attributes() in 4.3.

See [32868]. See #28180.