PathfinderWiki talk:Manual of style/Archive 2
Class names used as generic terms
|
Changes Accepted |
As noted by 77stephen on Talk:Precipice Quarter:
“I noted that beldrin is referred to as an "arcanist" small a. as pathfinder expands the class list towards 3 digit numbers and beyond (38 classes, 90+ prestige classes + archetypes) it may be unavoidable, but I wonder if the use could be confused with the Arcanist capital A
”
Many of the generic uses of arcanist on the wiki predate the class, in both the source materials and in our articles, but the point remains relevant: the relatively new ambiguity can be confusing, especially to new readers unfamiliar with the distinction.
We've had a note for a while at the top of arcanist stating that the term can be used both generically to refer to arcane magic users and to members of the arcanist class, but as new classes continue to join the canon, and in light of a few other collisions between class names and generic terms (like Category:Hunters vs. Category:Hunters (profession)), I propose that we suggest in the MoS that editors use specific, unambiguous terms instead of class names when they potentially collide. This should be a suggestion, not a hard-and-fast rule, as collisions are inevitable. However, I don't think we should use terms like arcanist generically going forward, even if they sound or read better that a more specific alternative.
When a collision is unavoidable, I propose that we suggest in the MoS that editors provide sufficient context to disambiguate the term's use. This might result in what might be unnecessary content or less elegant writing (hypothetically, "John is a hunter" could be written as "John hunts animals") in favor of unambiguous meaning, and clarity is closer to the encyclopedic tone and goals of the wiki than style.
I also propose that we suggest in the MoS that editors link to specific pages that disambiguate the subject when sufficient context cannot be added, such as in lists or tables. This might result in pages or redirects for otherwise unremarkable topics, like Hunter (profession), but it also uses tools native to the wiki to relieve some of the confusion by directing readers to a specific meaning.
Specifically, I propose:
- adding an H2-level section after Chronological items for Classes.
- incorporating the first two proposals above into this section.
- adding an item to the Wikilinks section explicitly allowing for using links to clarify ambiguous terms. -Oznogon (talk) 01:15, 26 October 2015 (UTC)
- Bumping this three-year-old proposal. If there's no interest, please feel free to close it out as rejected. -Oznogon (talk) 02:34, 16 January 2019 (UTC)
Four years is probably sufficient to have this agreed, so will formally do so in a week's time - what's another week? Maybe just worth considering 2E, though, in that week in case there are any newly discovered points to make regarding the new edition? 19 December is the deadline now then. --Fleanetha (talk) 16:11, 12 December 2019 (UTC)
Avoid "It is known"/"known to be"
|
|
Changes Accepted |
While following on to edits and new articles, I see phrases like this very often:
- "It is known that dragons lair in caves..."
- "These creatures are known to live in the Mindspin Mountains..."
- "Goblins have been known to carry dogslicers into battle..."
I propose instructing chroniclers to avoid those phrases. Including these phrases introduces doubt into the text—is it known but untrue? how widely known is it?—which is often not reflected in the source and not in line with our point of view (emphasis in the policy):
“While in theory these things are not known to anyone within the Pathfinder universe, PathfinderWiki's POV is all-knowing, just like a Game Master or reader of Pathfinder fiction.
”
In all of the above contrived examples, the phrase can be removed without losing any context—those facts "are known" because an authoritative source definitively stated it. Even if there is an in-universe controversy about a fact, that controversy can be explained in more explicit terms than these. -Oznogon (talk) 02:34, 16 January 2019 (UTC)
- Well, I am probably guilty of this, but it's a good prompt with a rationale and so I agree to its inclusion. --Fleanetha (talk) 15:41, 16 January 2019 (UTC)
- I'm sure i'm another guilty of this, sometimes it is just the simplest way to reword a one sentence fact from a source. I can see it either way, personally its not something that bothers me enough to be a documented rule, but I'll abide to it either way I Abstain to this vote. -- Cpt kirstov (talk) 16:35, 16 January 2019 (UTC)
- I agree. Tighter, more efficient language is always preferred over wheel-spinning. If a sentence can only be included by changing it in this way, then it's probably a simple enough sentence or basic enough fact to not count as plagiarism to include it verbatim.—
Yoda8myhead (talk) 23:33, 16 January 2019 (UTC)
Another change with no dissension we can tidy - setting the clock for a week and we can formally accept this change. Any new comments please? --Fleanetha (talk) 16:05, 12 December 2019 (UTC)
- I don't think we need to set clocks to accept changes that have already attained consensus. These changes have been categorized as open for years; if someone wanted to chime in on them, they've had their chance.— Yoda8myhead (talk) 01:45, 13 December 2019 (UTC)
|
|
Changes Accepted |
The guidance on headings using sentence case should explicitly apply to infobox and navbox sections. For instance, navbox section headings should avoid title case for sections ("Notable Inhabitants (Living and Dead)" as for ex. Template:Kintargo navbox and most city navboxes) and instead use sentence case ("Notable inhabitants (living and dead)").
This would further align our MoS with Wikipedia, which suggests sentence case for both ("The same applies to the titles of articles, table headers and captions, the headers of infoboxes and navigation templates"). -Oznogon (talk) 16:12, 13 October 2023 (UTC)
- Agree, though begrudgingly. CadeHerrig (talk) 05:15, 12 January 2024 (UTC)
- I still have the scars from the last time this subject was argued. So, in for a penny... and Approve for consistency's sake. I already started doing this for the new {{Riddleport navbox}}, but this is a big change regarding the work required to deploy it on existing pages and navboxes; I guess we fix when we find, as my understanding of how bots work suggests they cannot help here??? Again, if agreed, we'll need to update the associated help pages, as well as the MoS, plus add some examples. Finally, PathfinderWiki:Use lower case needs rewriting - incorrect, confusing, rules in the rationale, and has dead links. That page will also need the decision here adding too. I'll make a note. --Fleanetha (talk) 00:59, 16 January 2024 (UTC)
- Incorporated in MoS, updates to PathfinderWiki:Use lower case also needed. -Oznogon (talk) 20:51, 24 February 2024 (UTC)
|
|
Changes Accepted |
Some navboxes include legend text, particularly in section headings, to indicate the meaning of formatted items (ie. bold, italics, colors). This causes two problems:
- On narrow viewports/mobile, if the section header overflows the width of the navbox, the line wraps outside of the bounds of the section heading row. If the section is collapsed, the text is cut off. If the section is expanded, the heading text disruptively overlaps the text below it.
- The legend text is typically relevant only when the section is expanded, making it more of a distraction than benefit when collapsed.
Per boldness, I edited Template:Nirmathas navbox to avoid this by moving the legend text into the list. (before, after) This avoided the rendering issue and allowed the legend text to appear only when relevant in the expanded section.
In retrospect, this style should be part of the MoS and thus enforceable as policy.
I propose adding the following subsection to the "Formatting" subsection of the "Miscellaneous" section of the MoS:
- ==== Meaningful formatting ====
- Provide a legend when using meaningful formatting, such as when italicized or bolded text reflects something specific. For example, several articles related to Earth use italicized text to reflect known facts about Earth that are not in any canon source but are relevant context to canon statements about Earth.
- Reference footnotes and superscript symbols, such as daggers (†), can be more appropriate for grouping or contextualizing full statements or list items. Unlike meaningful formatting, footnotes and symbols can also be linked to a note or legend that describes their meaning.
- Avoid adding legends for meaningful formatting in headlines, table headings, infoboxes, navbox titles or group headings, which can result in poor formatting on variously sized devices even if they do not cause problems for you.
-Oznogon (talk) 16:12, 13 October 2023 (UTC)
- Does this proposal prevent the usage of formatted text in general in navboxes, or only explainer text for said formatting? CadeHerrig (talk) 05:14, 12 January 2024 (UTC)
- This proposal suggests only moving legends (explainer text; text required to describe what formatting in a navbox is meant to represent) out of the title lines of navboxes and navbox groups.
- This proposal does not suggest prohibiting the use of formatted text in navboxes, nor does it suggest prohibiting legends/explainer text.
- Didn't know this was a problem and am likely the clueless cause of many. I do now so this is an obvious amendment we need. As well as updating the MoS, we'll also need to update the help pages for the navboxes and show some good practice examples. Approve. --Fleanetha (talk) 00:38, 16 January 2024 (UTC)
Update image sizing guidance
|
|
Changes Accepted |
We have been modernizing image markup to prefer the use of thumb and upright parameters, which are already suggested in the MoS. However, some related MoS guidance is outdated and should be updated accordingly, or should be added to reflect usage:
- Update the Images section to describe and prefer the use upright over pixel widths when specifying thumbnail size. For example, As currently written, our MoS describes incorrect default widths for upright and suggests accommodating specific pixel-width screens, 800x600 in particular, in a manner that is not relevant with the current, responsive wiki theme.
- Describe and specify the use of wide banner lead images at the top of an article after the badges but before infoboxes, banners, or content, separated from content by a four-dash rule (----). (See Dis as an example.)
- Remove references to {{Wide image}}, which does not exist.
-Oznogon (talk) 20:51, 24 February 2024 (UTC)
- Agree: all sensible and mainly documenting what we do. --Fleanetha (talk) 22:22, 24 February 2024 (UTC)
De-emphasize and remove left-alignment guidance
|
|
Changes Accepted |
In usage, we prefer right-aligned art due to the often disruptive nature of left-aligned images in articles on mobile devices and narrow browser viewports. The MoS should be updated to reflect this.
- Revise "Avoid sandwiching text between two images that face each other" to "Avoid sandwiching text between two images, infoboxes, or other floating elements such as maps".
- Remove guidance suggesting the viability of left-aligned images, which frequently disrupt mobile and other narrow-viewport layouts. For example, add guidance stating this concern, and remove guidance such as "shift left-aligned images down a paragraph or two".
- Remove guidance suggesting that reversing an image is a viable option, since doing so is prohibited on CUP images.
- Remove guidance suggesting that we prefer that the eyes of an image's subject face the text. Since we can't reverse the image's facing, this can suggest the use of left-aligned images, which often disrupt layout.
- Expand the image stacking guidance to suggest linking to relevant image categories instead of adding multiple images to short articles.
-Oznogon (talk) 20:51, 24 February 2024 (UTC)
Provide DisplayMap/mapping project incorporation guidance
|
|
Changes Accepted |
The PathfinderWiki mapping project provides a new visual resource that the MoS predates. Update the MoS with guidance on using the mapping project as a resource.
- Note appropriate usage of the DisplayMap template and city/region/nation infobox latlong params to locate the subject of a text.
- Provide guidance on when and how to use captions to describe a map, such as on Primogen Crown.
- Provide guidance on using taller or shorter maps to help focus the map on a specific feature, such as on Sellen River.
-Oznogon (talk) 20:51, 24 February 2024 (UTC)
Arcanist quote (RESOLVED)
Manual of style contains a quote from the arcanist article: "[. . .] any arcane spellcaster, such as a wizard or sorcerer." I have edited the arcanist article to replace "sorcerer" with "magus", so please replace "sorcerer" with "magus" in the manual of style. (As of PF2e, some sorcerers are divine/occult/primal.) — Descriptivist (talk) 09:47, 7 August 2024 (UTC)