Help talk:Templates

Additional template request

Unless I'm mistaken, there are currently no templates or article spawners available for places more specific than a city. I would like to request a district template and a building template, as well as their article spawners, to ease and standardize the creation process of new pages for districts and individual buildings within cities. --Rexert (talk) 12:13, 1 January 2025 (UTC)

Hello Rexert. It's great you're finding the templates and article spawners useful and want even more. For city districts, there is help here Template:City to tweak the city template to accommodate a district, essentially adding the ibtype parameter; there are several examples located here: Category:Absalom/Districts. So, you could use the City article spawner and quickly adapt it for a district. Take a look please to see if that's sufficient, or whether a separate spawner would help.

As for buildings, there are currently no infoboxes nor article spawners for them. A list of building type categories may be found here: Category:Buildings. What sort of info would you consider for inclusion in a building ib? I could see us include the usual: name, type of building, location (city, nation), associated organization or deity, imagesof, source info. As additional ones, it might be nice to add architectural style, though we will only have that info rarely. Also, we could add any traits it's been given. I can try to knock up a spawner later using the normal parameters for building articles. --Fleanetha (talk) 09:23, 2 January 2025 (UTC)

There are some Template:City elements like capital, level, size, and natives which don't generally apply to city districts. One thing districts typically have in common is a specialization or distinct purpose which could have its own ib element or article section, or both. Because districts are normally only found in large cities and almost act as a city themselves, article sections like "district security/guard" and "places of interest" could also be a part of the template. I'm not sure if that's enough distinction to warrant its own separate template, although for editing purposes, additional templates certainly help.

Similarly to districts, buildings tend to have a distinct purpose that could have an ib element or article section, or both, but I suppose the categories of a building might handle that part. A "description" or "structure" article section for explaining the appearance of the building and its layout would probably be the most important building template element. I like the idea of architectural style, if that information is available, and it would make sense to include a list of notable individuals who can be found in that building. For example, the notable individuals article section under Sandpoint Cathedral. --Rexert (talk) 12:45, 2 January 2025 (UTC)

Regarding this point in particular:

Because districts are normally only found in large cities and almost act as a city themselves, article sections like "district security/guard" and "places of interest" could also be a part of the template.

While some articles, especially older ones, retain similar lists, we should work to avoid them in favor of navigational templates.

Places of interest, notable individuals, and organizations (including organized guards or security forces) should be listed in a district group within a city navbox like they are in {{Korvosa navbox|CD}}. Absalom, being exceptionally large, dense, and extensively detailed in multiple published works, might be the only place where I'd prefer district-specific navboxes.

This practice is already in use and should be documented in Help:Writing an article about a place. That it isn't already documented there is solvable without requiring consensus. -Oznogon (talk) 22:28, 2 January 2025 (UTC)

While navboxes are far more comprehensive, I would argue that their position at the bottom of articles and their usage requiring users to click each section separately results in little to no use in practice. For example, if I need information about Korvosa for a campaign, I will most likely find it within the bulk of the article or in the information box at the very top, and close the page before ever scrolling low enough to see the navbox. --Rexert (talk) 22:46, 2 January 2025 (UTC)

I understand. However, nothing prevents the body of the article from providing comprehensive descriptions of notable locations/orgs/inhabitants in prose, with context and references as necessary, rather than as a list. This is indeed the general preference as documented in the manual of style, and I've just reinforced it in Help:Writing an article about a place.

Navboxes also remain preferable as a single source of truth for list maintenance, and also for navigation between related articles beyond this specific context.

We also aren't obligated to use navboxes exclusively at the bottom of articles if they're better presented elsewhere within them, and they contain no technical limitations requiring them to be used exclusively at the bottom of articles.

Navboxes with collapsible sections can also be configured to be presented as fully expanded through the collapse parameter, such as on Galt.

I'm therefore unfortunately unmoved in my preference for navboxes over bare lists for the purposes of listing subjects related to an article. I appreciate that their usage could be improved and have worked in the past toward improving them. -Oznogon (talk) 00:03, 3 January 2025 (UTC)

I agree that navboxes are better suited for a list of places of interest or notable individuals, I just also think it's reasonable to have dedicated article sections within the template that further expand the available information on some or all of the elements in the navbox list. As you mentioned, nothing prevents it, however, nothing currently facilitates or standardizes it to be described that way either. For example, the Sandpoint Cathedral notable individuals section definitely shouldn't read like a list—that should be left for the navbox. But the section itself still has merit if rephrased to read as a regular paragraph, and, in my opinion, should be included in a structure template. --Rexert (talk) 00:42, 3 January 2025 (UTC)

Most, though not all, infobox templates here correspond to things that can have mechanical statblocks. {{Nation}}s, {{region}}s, and {{city}} entities (and {{vehicle}}s, {{magic item}}s, {{alchemical item}}s, {{person}}s, {{creature}}s, {{arcane school}}s, {{class}}es, {{cosmos}} and {{deity}} entities, etc.) have at various times had standardized Pathfinder Roleplaying Game statblocks, while structures have not.

All of those types of entities thus can have corresponding structured data, such as traits, levels, alignments, etc. (Many on the wiki do not have mechanical definitions but have the infobox anyway; such entities sometimes are later mechanically detailed in a published work, filling out the existing infobox.)

Infoboxes also serve as a neutral ground for inclusion of mechanical content outside of the main article text, where it's generally inappropriate. Details like population, demographics, and governments are in published city statblocks and have had mechanical ramifications. As Fleanetha notes, the ibtype parameter allows for making exceptions in describing things that aren't cities but have the details or mechanics of a city, including districts of large cities.

As far as I'm aware, outside of the very narrowly scoped kingdom-building rules, the vast majority of structures do not have common game mechanics, statblocks, or structured data suitable for traditional use of an infobox. That doesn't mean it would be inappropriate to have infoboxes for structures, but a structure's properties would need to be very specifically defined, arbitrarily by us as wiki editors and not by Paizo, in order for an infobox to work in a manner similar to the other infoboxes. Should Paizo later create mechanical statblocks for buildings, our definitions would likely conflict and require all such infoboxes to be updated.

In the past, new infoboxes created for narrow purposes have failed to see sufficient adoption to warrant their continued maintenance. This in turn creates a maintenance burden on administrators when those infoboxes are removed or replaced. ({{iconic}} is one example.)

There's additionally a renewed push for the Semantic Data Initiative to include in-universe infobox content. Any new navbox might be redundant with implementing Facts-namespace content for that subject, which would be more powerful than infoboxes and could include automatically generated and maintained infoboxes from the semantic data. That again would require strictly and consistently defining properties and a structure for that data.

If this proposal for an infobox does move forward, I would strongly suggest naming it more generally {{structure}} rather than building, since particularly in the Pathfinder campaign setting, several notable structures are not built.

As far as the article spawners, having created most of them, they are simply preload templates for populating common features of articles. No proposal should be required to add to them, and no corresponding infobox is inherently required for them. If we were to so specifically define how we write about structures, I would prefer that we first have a Help:Writing an article about a structure guide from which the article spawner, infobox, and/or structured data could be derived. No proposal is required to begin that work, either. -Oznogon (talk) 20:46, 2 January 2025 (UTC)

Some progress then. Oz has updated Help:Writing an article about a place - thank you - and I just set up a new spawner for a structure / building here: Template:ArticleSpawner/Structure. I included (I hope) all the elements mentioned above but it could do with a review, as I have never made one before. With all the discussion above, I am reluctant to create a building infobox. Re the raw list discussion above, another main reason for us moving away from them was that any raw list quickly got out of date and out of sync with the navbox or other pages with a similar list. Having one place to update means the wiki is up to date and consistent - this is important. Of course, I have no problem with a elements being discussed in paragraphs as suggested. --Fleanetha (talk) 19:26, 4 January 2025 (UTC)

I'd like to mention that while most structures indeed do not have a statblock, there are some examples that do, which may be worth taking into consideration. For example, the Otari gazetteer provides a statblock for every major town structure. These statblocks consistently include the structure's level, inhabitants and traits, as well as an address, wares, and the spellcasting provided by the inhabitants when these options are available. --Rexert (talk) 23:44, 4 January 2025 (UTC)

That provides for 16 structures in Abomination Vaults. Another 50 locations (not limited to structures) in Sandpoint from Seven Dooms for Sandpoint share a similar statblock structure (address, wares, spellcasting, and NPCs) and reuse some traits from Abomination Vaults (employer, garrison, parlor, housing, library, lodge, parlor, workshop; church and discount are unique to Abomination Vaults, temple is defined slightly differently from church in Seven Dooms, and hazard, merchant, municipal, residence, restaurant, and venue are "unique" to Seven Dooms insofar as they're traits as opposed to a structure type listed in the level indicator). Several of the shared traits are defined differently, and these mechanics are not on AoN, so there's no place to link them for context.

Absalom, City of Lost Omens doesn't list levels, addresses, or wares for its 234 city locations or a few dozen more undercity and outskirts locations (not all of which are structures), and its NPC lists are not limited to inhabitants. Some of the traits are shared with Seven Dooms and Abomination Vaults; academy, archive, attraction, bank, criminal, dungeon, market, monument, neighborhood, precinct, shrine, and tavern are unique to ACoLo, and several shared traits are defined differently. Wares for 32 shops, restaurants, and taverns are listed separately in a table on 88–89, combining services in several locations. A separate index of location types not necessarily tied to traits is listed on 83–85.

Season of Ghosts Player's Guide gazetteer of Willowshore has wares lists for several of 30 locations (not all of which are structures) but the rest is prose; no levels or traits. The Summer That Never Was expands them into similar statblocks as Abomination Vaults, plus services and work sections unique to that adventure. The nature of the AP makes it difficult to discuss further, and unless the location type is extracted from the level indicator, their only traits are AP-specific.

Because of the arbitrary and AP-specific nature of some of the structure traits, I imagine this would create many one-article trait categories that are unlikely to see expansion. That's nothing new, but a consideration to be aware of.

Spellcasting services are IMO inappropriate and better handled written in-universe within the article; {{Deity}} feels like a relevant warning about how long lists of edition-specific mechanics in infoboxes are brittle, ugly, and difficult to read.

In 1E, Sandpoint, Light of the Lost Coast has statblocks for 52 locations (not limited to structures) and includes a wares section, but it also includes rumor and quest sections of questionable value for standardization, and its NPC lists are not limited to inhabitants. Magical Marketplace has a "shop stat block" listing an owner, location, mundane wares, and magical specialties.

Maybe {{Location}} would be more appropriate, with broader utility? It could include traits, level, type, wares, city/region/nation/plane, address, affiliation, and proprietor or resident. The latlong and displaymap parameters could be borrowed from {{City}} to provide PoI creation and region maps the same way that {{City}} does for settlements, replacing the bare {{DisplayMap}}s on articles. -Oznogon (talk) 17:47, 6 January 2025 (UTC)

Proofs of concept for a location infobox: User:Oznogon/Template:Location. -Oznogon (talk) 18:11, 6 January 2025 (UTC)

Great proof of concept, my only concern is the length of the ib growing out of control, especially if an image of the location is included on top of all other elements. --Rexert (talk) 23:54, 6 January 2025 (UTC)

FWIW, I added a proposed infobox for Starstone Cathedral to the proof of concept so I could measure the difference ot the article's lead image and map. It's 120px taller than the existing loose map and image, but also includes its 2E traits, location, affiliation, and relevant 1E and 2E sources. Certainly worth some concern about size, but I think it's generally better for articles that have both art and maps than no infobox since the borders and space between images and maps is effectively wasted. -Oznogon (talk) 22:21, 8 January 2025 (UTC)

Listing 'spellcasting' under the 'wares' parameter also doesn't seem accurate, perhaps 'services' might be a more appropriate parameter. It would then make sense to simply say 'vendor' and 'spellcasting' under 'services' without detailing each item type available at the location—that could be explained further within the page itself, saving some ib space along the way. --Rexert (talk) 23:54, 6 January 2025 (UTC)

Wares can include marketable intangible assets, including services, so I'm not concerned about services being in that list. The ib list, especially for the Magical Marketplace example, is still a summary of items that are detailed in the corresponding source. Also, "Wares" is maybe the most consistently included section in location statblocks, both within and across game editions; I'd be against deviating from the term if we're implementing statblock info in these infoboxes, as we typically do. -Oznogon (talk) 22:21, 8 January 2025 (UTC)

Another potential ib reduction could be the consolidation of the 'city', 'region' and 'nation' parameters into one, or the removal of the 'region' parameter entirely considering there is limited regional information. --Rexert (talk) 23:54, 6 January 2025 (UTC)

This case could also be made for other infoboxes, and consolidating them now might make a future transition to structured semantic data more difficult. I've consolidated them (and address) in the infobox into a locale parameter (to avoid "position" or repeating "location"; suggestions welcome), but to preserve semantics while consolidating the presentation I'd strongly consider splitting those parameters back up and then conditionally composing them into the locale parameter's value if we implement the infobox. -Oznogon (talk) 22:21, 8 January 2025 (UTC)

I agree that {{Location}} would offer broader utility and could include non-standard structures like tunnel systems, or clusters of several adjacent structures with the same purpose. I also agree that detailing each spellcasting service within an ib might be excessive and an optional article section could be included within the template for this purpose instead. The addition of the {{DisplayMap}} as a part of the ib for location pages is an excellent idea. --Rexert (talk) 18:21, 6 January 2025 (UTC)