What is Sitecore.ContentSearch.SearchTypes.Content Property which maps solr _content field?

Question

What is _content in SOLR. While mapping through Sitecore, what are the fields will it map?

Is it good practice to use Content property in search query builder? In that case, How will it work in solr stopword functionality language wise? Or We need to use specific property to search.

If not, how to achieve language wise _content mapping?

namespace Sitecore.ContentSearch.SearchTypes
{
    public class SearchResultItem : ISearchResult, IObjectIndexers
    {
        [IndexField("_content")]
        public virtual string Content { get; set; }
    }

}

Answer 1

When your Sitecore application is configured to use Solr, default configuration contains _content field which is a computed field using MediaItemContentExtractor to populate its value.

It uses mediaIndexing configuration to determine which mime types and extensions should be indexed and indexes their content.

From what I know, when you upload new media item to media library, Sitecore creates unversioned media item with a version in every language version there is defined in Sitecore.

That said, I don't think it's a good idea to use _content computed field. If you upload EN document to media library, it will create a version of that document for every single language defined in Sitecore and while indexing it won't care about EN stopwords when other language version document will be created in Solr.

There is a setting in Sitecore which allows to upload items as versionable by default:

<setting name="Media.UploadAsVersionableByDefault" value="false"/>

but it's disabled in vanilla Sitecore apps.

---

EDIT:

You're right. There is hardcoded functionality in LuceneDocumentBuilder (I there is similar in Solr but I cannot confirm it now) which adds value of all text fields ("Single-Line Text", "Rich Text", "Multi-Line Text", "text", "rich text", "html", "memo", "Word Document") to the _content field.

I might be wrong here but from what I remember all the fields starting with _ in their names are considered as "internal" fields and there are no language specific. If I'm right here, there would be no option to use language specific stopwords for _content.