IBX-7409: Changed Content Type label to content type

[Gengar-i]

Question	Answer
JIRA issue	IBX-7409
Type	bug
Target Ibexa version	v4.6
BC breaks	no

Changed Content Type label to Content type

Checklist:

• Provided PR description.
• Tested the solution manually.
• Provided automated test coverage.
• Checked that target branch is set correctly (main for features, the oldest supported for bugs).
• Ran PHP CS Fixer for new PHP code (use $ composer fix-cs).
• Asked for a review (ping for example @ibexa/php-dev for back-end changes and/or @ibexa/javascript-dev for front-end changes).

[Steveb-p]

Whenever we refer to Content Type we use this specific notation to clearly indicate that we are talking about a PHP API object. This IMO should not be changed, especially when dealing with tech savvy users.

[konradoboza]

Whenever we refer to Content Type we use this specific notation to clearly indicate that we are talking about a PHP API object. This IMO should not be changed, especially when dealing with tech savvy users.

It isn't. Description is only used to generate GraphQL "Docs" section. This PR doesn't change the way schema properties are accessed if this is something you had in mind.

[Steveb-p]

Whenever we refer to Content Type we use this specific notation to clearly indicate that we are talking about a PHP API object. This IMO should not be changed, especially when dealing with tech savvy users.

It isn't. Description is only used to generate GraphQL "Docs" section. This PR doesn't change the way schema properties are accessed if this is something you had in mind.

Changes include technical documentation (docs you mentioned), PHP comments, exception messages. These are technical and we used Content Type case "variant" specifically. This allows us to differentiate Content Type object (as an PHP API entity) vs. Content type (as a specific type as declared in application).

Personally I am against changes being run as a search & replace across the whole code base. This was not discussed with the backend team, and seems like a frontend change is bleeding over to backend code, where a specific convention was upheld.

[konradoboza]

Isn't naming within the docs adjusted too in general? If so, I wouldn't be blocking this change - I cannot see any scenario where anyone would be confused with such a trivial naming adjustment.

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[alongosz]

A short comment to the above discussion - if this was a change of ContentType into a content type I would've agreed that it was incorrect as referred to an entity. But "Content Type" is not an entity. If it's a part of a description / a end-user message line, it's fine.

For me +1. Again, this is per case basis and subjective opinion.