A Wikibase client can use lowercase labels for properties. This is for example the case for Wikidata.
The UI would be more clean if these properties could be capitalized.
A Wikibase client can use lowercase labels for properties. This is for example the case for Wikidata.
The UI would be more clean if these properties could be capitalized.
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Capitalize properties' labels | mediawiki/extensions/ArticlePlaceholder | master | +1 -1 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | thiemowmde | T142940 Create client functionality for getting human readable wikitext from Wikibase statements | |||
Declined | None | T99897 {{#property}} parser function should output EntityIdValues as local wiki links, once we have article placeholders | |||
Resolved | Lydia_Pintscher | T135624 Second round of the ArticlePlaceholder rollout (tracking) | |||
Resolved | hoo | T130997 [Task] Configure ArticlePlaceholder for nnwiki | |||
Invalid | Lydia_Pintscher | T99896 Use Lua for custom rendering of entity data on Special:ShowEntity | |||
Resolved | Lucie | T99895 [Epic] Article placeholder based on data from Wikidata | |||
Resolved | Addshore | T123087 [Task] Track use of Create Article and Translate Article buttons | |||
Resolved | Lucie | T117965 Review and deploy of the ArticlePlaceholder extension | |||
Resolved | Lucie | T117683 [Tracking] Finish minimal loveable product as beta feature | |||
Declined | Dereckson | T125913 Capitalize property headings in the Special:AboutTopic view |
Change 268615 had a related patch set uploaded (by Dereckson):
Capitalize properties' labels
Different wikis may have different preferences. The headings should be customizable per-wiki.
A preference has a cost, we need to maintain it on the long term, and as such, should be justified by a use case, not a "may".
@Ricordisamoa would you know a language where headings are not capitalized AND the ucfirst method still capitalizes them (because the lua ucfirst method from our language library has exception to bypass such languages)?
It seems we already have a similar discussion for the languages column capitalization when the CLDR switched to lowercase.
@SPQRobin, could you give us some summary of the final decision on the matter?
I didn't mean a user setting of course. I expect the ArticlePlaceholder to be fully extendible and customizable through Lua.
Some property names start with an intentional lowercase letter, e.g. https://www.wikidata.org/wiki/Property:P1117 and https://www.wikidata.org/wiki/Property:P2281 (in English)
I have no idea how the ucfirst method works, but I think for some African languages, it's not always the first letter that's capitalised (e.g. some of the headings on https://ss.wikipedia.org/wiki/Likhasi_Lelikhulu start with "iWikipedia")
For African languages, that could be fine, our ucfirst message method comply with localization rules and is language specific.
For pKa, this is more annoying. Labels don't have properties, so, we can't mark them intentionally lowercase.
message.
What about a Property: prefix?
A better approach could be to use a prefix, but current design don't let really any place for that, so we should also decrease the heading font size.
"manner of death" would become "Property: manner of death", with the "Property: " a customizable localized message.
If no satisfactory approach could be found
If that couldn't work by lack of place, a PKa or an ITunes is probably more acceptable than "manner of death" or "languages spoken or written" always in lowercase.
Indeed, virtually all the labels are currently wrongly displayed, as Wikipedia conventions require headings to be capitalized. Not to fix it because there would be SOME labels wrongly capitalized is a fallacious argument, as we would choose to display wrongly every > 93% labels to display correctly < 7% of them.
So, at the worst, we could also apply the ucfirst transformation to solve the issue for the majority of labels provide a setting ArticlePlaceholderPropertiesInLowercase array properties to mark the rare properties intended to be in lowercase, but that won't be optimal either, as they could be in lowercase in some, uppercase in other languages e.g. "iTunes identifier" vs. « identifiant iTunes ».
I don't think we should do capitalization by default based on what others said already. Depending on local convention each project can adjust this as they wish locally.
Change 268615 abandoned by Thiemo Mättig (WMDE):
Capitalize properties' labels
Reason:
T125913 got declined.