Would we be better off loading the strings already defined for this purpose in https://github.com/joomla/joomla-cms/blob/staging/administrator/language/en-GB/en-GB.com_tags.sys.ini ?

They may not be translated on site-only language packs.
But I think we should try to make this evolve to take also care of 3rd party extensions, i.e. load their sys.ini files where they would add the necessary string.

to that

With this updated PR, we now load any 3rd party extension sys.ini file.
The format of the string should be similar to the one used in the plugin for core extensions.

Alas I have no 3rd party component with a content_type which would display results when searching to test,

Alas I have no 3rd party component with a content_type which would display results when searching to test,

You could try with my SermonSpeaker component. It uses three content types (sermons, series and speakers).

I tried it, Thomas, and added tags to all default elements installed by your extensions, but I could not get these in the search

I had evidently published your search plugin

I tested it with my extension and it would work.
However I think the code could be improved from an design perspective.
First I think the search plugin should contain strings related to other extensions, even if they are core ones. They should instead be in the respective components language files.

I would also change the keys to for example COM_CONTENT_CONTENT_TYPE_ARTICLE instead of PLG_SEARCH_TAGS_CONTENT_TYPE_ARTICLE. There are two reasons:

• It makes the strings reusable if we want to use the translated content types in other places (like history).
• It deals properly with the case where two components would use the same name for the content type (after the dot).

One thing to consider is also where to store the string. Your PR uses language strings from the backend (the .sys ones) for the frontend. I consider that very bad practice and had an issue before where an extension loaded a core language file from the backend which overwrote strings from the frontend. So I'd use that very carefully and only if there is no other way.
Better put the strings in the frontend language files.

By the way: I just found that we already translate the content types for the contenttype formfield. This field is used when you create a menu item for com_tags where you can filter the list by content types.
The key used there is COM_TAGS_CONTENT_TYPE_ARTICLE which again I think was chosen badly but better be consistently wrong than creating yet another key with the same value.

@Bakual That's the file I linked to above :)

@wilsonge You mean I should read the full PR before commenting?

Who has time for that

We indeed have already the strings translated in back-end but in the com_tags.sys.ini,
Strings there are limited to core components.

I modified the PR to load the strings in front-end from the component ini file
strings are all of type
COM_MYCOMPONENT_CONTENT_TYPE_SOMETHING

I modified the PR to use each component sys.ini for the back-end Options in the tags menu items
This would mean that each component using content_types would have one or multiple strings in its sys.ini file of the same type:
COM_MYCOMPONENT_CONTENT_TYPE_SOMETHING

Created all strings.

NOTE: I do not understand how can be used the content_type for users, banners, tags in the menu item, as well as in frontend search
Therefore I have added these in back-end, as they were already loaded as Options. But not in frontend where anyway we do not have any Banner ini file

I have tested tagging a Banner category for example.
Then I create a Tagged Items menu item and choose Banners Category as content_type
The menu displays fine a link to the Banners category with its textarea description.
Then, when clicked on its title, we get:

Fatal error: Uncaught exception 'RuntimeException' with message 'Unknown column 'header' in 'field list' in ROOT/libraries/joomla/database/driver/mysqli.php on line 610

( ! ) RuntimeException: Unknown column 'header' in 'field list' SQL=SELECT `new_url`,`header`,`published` FROM `jos_redirect_links` WHERE `old_url` = 'http://localhost:8888/trunkgitnew/component/banners/15.html?view=category&Itemid=435' LIMIT 0, 1 in ROOT/libraries/joomla/database/driver/mysqli.php on line 610

After correcting the sql error by updating the table
ALTER TABLE #__redirect_links ADD header smallint(3) NOT NULL DEFAULT 301;
ALTER TABLE #__redirect_links MODIFY new_url varchar(255);

I get a 404 for the Banner Category link

Makes sense, because there is no view to show all banners from a category. There is in fact no view at all. Which makes sense if you think about what com_banners does. We just want to show a linked picture basically.
Let's add it as a new bug to the huge list of bugs in com_tags

I guess we have to take it off from the content_types then in all sqls, no?
And what about users and tag content_type?

Can you test the patch?

I don't think so JM. If I recall correctly it was added there so that we could have content history for banner categories. Looks like this was an unintended consequence

We should take these Options out for tags menu items then.
That could be another PR, but maybe better do it here too

Although the contenttype.php field is only used for com_tags for now, what do you think about creating a custom one for tags where the unusable content-types would not be displayed in the Options?

Yep, it's needed for history. It's just one more flaw in the design of com_tags in thinking that every content type is used for com_tags, even if the tables are named "UCM...".

Although the contenttype.php field is only used for com_tags for now, what do you think about creating a custom one for tags where the unusable content-types would not be displayed in the Options?

Each time we hardcode something somewhere, it will fail for 3rd parties. Imagine an extension which uses content types for whatever (history or something own), but has no tags.
You also don't know if the formfield is only used for com_tags. Any 3rd party extension could use it as well.

Added a custom contenttypetag.php field which gets rid of com_banners, com_users and com_tags content_type in the Options for the Tag menu items

Can we leave the formfield out of this PR please?
It's a completely different issue and imho it would be a wrong approach since it doesn't solve it for 3rd party extensions.

@Bakual
The new form field is only used by com_tags menu items. The library one is untouched. Is that wrong?

After talking with Thomas, and as he suggest we have to solve the issue of the Options also for 3 rd party extensions who don't use tags, I reverted that part.
Thank you for testing

NOTE: this will need some info on docs to help 3rd party extensions to place their strings

@test
PR works as intended

This will let type_title alone. Thanks @bembelinen

After bembelimen improvement, the new strings are depending on the type_alias and not anymore on type_title.

2 good tests. Merged. Thanks