Template talk:Sold by

Quantity column

I think that quantity might look better if it was in a column on its own (between the vendor and cost columns), rather than wedged in front of the cost value. -Chieftain Alex 01:19, 2 February 2014 (UTC)

I agree with that. I don't like the way it looks as is. You could almost interpret it as having to pay that amount multiple times to receive the item in question. Psycho Robot (talk) 01:51, 2 February 2014 (UTC)

There are very few items that have a quantity greater than 1, so it's own column is definitely not happening.--Relyk ~ talk < 10:28, 2 February 2014 (UTC)

Move the quantity after the cost:

250  / 5

That's how we do it in infoboxes, don't we? —Dr Ishmael 16:07, 2 February 2014 (UTC)

What if it was hidden unless a quantity was defined? In either case, it should definitely be moved from the price column. After the item name "Grumpy Relyk (x2)" would probably be better. Psycho Robot (talk) 18:19, 2 February 2014 (UTC)

Sure in the infoboxes of gem store items we do quantity after cost, and in {{recipe list}} we put the quantity after the name.

Either are fine by me, although I prefer the recipe list way (come to think of it I'm biased because I suggested it in the first place... ) -Chieftain Alex 20:13, 2 February 2014 (UTC)

Except the item name is not produced in this template, so lets do it the infobox way. -Chieftain Alex 20:14, 2 February 2014 (UTC)

{{vendor list|Buttermilk in Bulk}}

Hmm. Looks a bit funny when the cost is formed from multiple currencies. -Chieftain Alex 20:21, 2 February 2014 (UTC)

My placement of the quantity was a placeholder, I didn't want to put it on the right side so that the currencies would line up though. And it looks funny with multiple currencies.--Relyk ~ talk < 20:33, 2 February 2014 (UTC)

Switch columns.

Something did not quite look right to me on this template. So I switched the cost and location column. this is the results. Should we switch it in the live version. Anzenketh (talk) 15:27, 6 June 2014 (UTC)

I agree that it looks different to the {{vendor query table header}} tables. Go for it. -Chieftain Alex 15:35, 6 June 2014 (UTC)

whilst I agreed with reordering the columns, the formatting that you'd added looked mighty queer. moved to row template + reconfigured. -Chieftain Alex 17:07, 6 June 2014 (UTC)

It looked worse before I made that change. It looks good now. Anzenketh (talk) 17:29, 6 June 2014 (UTC)

I'm not sure about the text-align:right bit. It looks odd in the table above for example when you consider the row with the quantities on it. -Chieftain Alex 17:45, 6 June 2014 (UTC)

I think I agree and like left align better. Anzenketh (talk) 17:55, 6 June 2014 (UTC)

What do you think about align center align center Anzenketh (talk) 17:58, 6 June 2014 (UTC)

its mostly numbers so it should be right aligned. The quantity formatting is the only odd thing. Center isn't really suited to amounts imo. -Chieftain Alex 19:11, 6 June 2014 (UTC)

Using this template to display one vendor.

Recently saw this edit I think it is important to have all acquisition tables be queried by SMW as vendors come and go and items being provided may be added at any time. However I also agree that having a table for only one vendor looks rather silly. Could we modify this template to use something like {{Location result}} to return the result if the number of vendors is less then 2. Anzenketh (talk) 16:58, 6 June 2014 (UTC)

comments on revision

Regarding this edit. You will actually want to search for has availability current unless you change your availability code. As you do not want to get discontinued, unimplemented,historical,future content. If a item is discontinued it is not available from any vendor.Anzenketh (talk) 13:12, 13 June 2014 (UTC)

historically sold items get removed from VTR. -Chieftain Alex 14:56, 13 June 2014 (UTC)

What about discontinued. Discontinued items do not get flagged as historical. Anzenketh (talk) 14:56, 13 June 2014 (UTC)

The Is historical property will be phased out for Has availability. Vendors haven't been updated and we need to keep backwards compatibility until we have the formatting and articles updated.--Relyk ~ talk < 15:34, 13 June 2014 (UTC)

I know this. I have been watching the development of the changes. The point is this template does not filter out discontinued items. Anzenketh (talk) 15:36, 13 June 2014 (UTC)

We will get there, alex reverted more to keep compatibility.--Relyk ~ talk < 15:59, 13 June 2014 (UTC)

oh fucksake. I meant discontinued, not historical. just keep vendor pages upto date, and vendor list will sort itself out. -Chieftain Alex 16:14, 13 June 2014 (UTC)

We shall see if that actually happens. I will bring this up again if I find a instance to where it is a problem. Anzenketh (talk) 16:28, 13 June 2014 (UTC)

Merchant's icon

I was thinking that it'll come in handy having th merchant's icon (Coins, Renown heart, Karma, Helmet, Swords, etc) next to the vendor name. For example, someone may want to pick a quick vendor they can use without completing a heart, so even with the cost being karma, it could be a karma vendor instead a renown heart. With the icon they'll known right away. MithTalk 01:06, 24 October 2014 (UTC)

Historical vendors

Can include historical vendors be changed to include all vendors by default, but just function to remove historical vendors when necessary (removed currencies or excessive results)? —Mora 02:19, 27 September 2015 (UTC)

Or we can remove the parameter. Vendor list is suppose to list current vendors that sell the item. People should use {{vendor query table}} for looking at historical vendors.--Relyk ~ talk < 02:28, 27 September 2015 (UTC)

Switched default to include historical vendors. Parameter can be set to "n" to hide historical entries. The template also checks the vendors for their status, and if they are unavailable (historical = true), then the currency is grayed out. -Chieftain Alex 12:16, 27 September 2015 (UTC)

Alphabetical over historical

It would be nice if the vendor list template could list non-historical vendors (in alphabetical order) first, and then the redundant historical ones. Usually not an issue but it can be misleading on pages with more than a few vendors listed, as seen here. —Ventriloquist 10:29, 17 April 2016 (UTC)

The problem is that the "vendor is historical" information is stored at a different level to where the query goes. The first query searches for "a specific item sold by any vendor", and then we pick up the information on which vendor sells it with a second query. The sorting is done with the first query, which only has item information. It could probably be done with a widget (we'd sneak in the historical status.

In this precise case i think we'd be okay with removing the {{inventory}} template from the removed NPCs, as these items are unimportant and vendors are plentiful. -Chieftain Alex 11:15, 17 April 2016 (UTC)

I have two ideas:

• A) we could do two queries, one for the current and one for the historical, using [[Has vendor.Is historical::N]] and [[Has vendor.Is historical::Y]]
• B) I investigate why items sold by NPCs marked as historical don't inherit the NPC's status.

Persuing option B. -Chieftain Alex 11:27, 17 April 2016 (UTC)

I'll leave you to it, then. —Ventriloquist 11:38, 17 April 2016 (UTC)

Once the changes trickle through the job queue everything should sort as you asked it to. -Chieftain Alex 13:16, 17 April 2016 (UTC)

My example page has already been updated, neat! So, did you manage to figure out option B or did you go for option A instead? —Ventriloquist 13:52, 17 April 2016 (UTC)

Yeah I cheated on that one and purged the two historical vendor pages to push it to the top of the list :)

I went with option B. I had forgotten that each item subobject (example) created by {{vendor table row}} stores the "Is historical" property. It just didn't have any code to make it inherit the historical status from the NPC, so I made some changes to vtr + the header template. -Chieftain Alex 16:50, 17 April 2016 (UTC)

Shared icons and vendor templates

The new infusions and INFUZ-5959 put the vendor templates to the test; namely, what happens when an item in the vendor list has an icon = SomeOtherItem'sIcon.png . What happens is the template can't find the icon. The vendor template offers "cost icon = " to fix it for that row, but the vendor list template doesn't see that icon either. Also. "cost icon = " fails when there is more than one type of item specified in cost, changing both cost item icons. Redirects solve these problems, but someone more code-savvy might want to update the lookup logic; I'm sure something this complex wasn't considered when it was designed. SarielV 20:14, 28 July 2016 (UTC)

RFE: Limit or Filter by Location

For example, Shadows Agent Kito is located in three locations, but only in one location is he a vendor. See Slightly Smelly Slab of Steak where he is listed as the vendor for the item and the three locations are lists. --Choco-muffin (talk) 19:31, 31 October 2018 (UTC)

Either we split the NPC page by location, or we edit the infobox on the NPC page to remove the non-vendor locations. Filtering using this template isn't really an option. -Chieftain Alex 20:16, 31 October 2018 (UTC)

Template rename

"Vendor list" is very abstract, it doesn't exactly specify if a vendor is selling or buying this item. I propose we rename this template to {{sold by}} to match the header in item articles (eg Boneskinner Tonic#Sold by). --BuffsEverywhere (talk) 21:37, 17 June 2021 (UTC)

"Generates a list of vendors selling the item." Tedious task for almost no gains, editing the item acquisition is always a simple copy paste task. --Tolkyria (talk) 22:28, 17 June 2021 (UTC)

Could redirect it. Most of our other acquisition templates are named straight after the section I think. -Chieftain Alex 22:43, 17 June 2021 (UTC)

Tolkyria, you only know that by reading the documentation. It's not intuitive at all. Yes, renaming is tedious, but most of it can be botted. The name "vendor list" doesn't even make sense because it generates a table, not a list. I always get it mixed up with {{tl|Vendor table}} (which I think also has a bad name — even the result format template doesn't even have the same name, and also {{tl|Vendor table row}} is a completely different template!). But I digress. Template names should describe what it does, and be distinctive from other templates. You can't expect every editor to know and remember the which one to use from all of these similarly named vendor templates. --BuffsEverywhere (talk) 23:37, 17 June 2021 (UTC)

Sorry, I wasn't precise. No objections against a rename, just noting that it's tedious task (9500 pages) for something that's copy paste. Wiki editors go to a similar page (they are probably not even using the formatting guide), copy-paste the code, slightly modify it if necessary.

If you find one that runs the bot, checks everything, tells Darqam to change GW2 Easy Mode which currently lists "[...] if it's in a vendor please use {{vendor list}} [...]", sure go for it! Of course, once everything is done, it will most likely fit perfectly. But still I have seen so many things going wrong when renaming, so many rename remnants, that I'm careful which such tasks. Also, the original template creator had something in mind when choosing the template name (hopefully), so I won't simply neglect this historical component. --Tolkyria (talk) 00:05, 18 June 2021 (UTC)

Edit: Offtopic, the table/table row naming scheme is quite consistent on the wiki:

• table row templates - these templates are created by hand, individual rows that are used to define/store information.
• table template - these templates are created (semi-)automatically, they can be used in mainspace without to much work (the work is done elsewhere, e.g. in the table row templates) and display the whole table at once.

--Tolkyria (talk) 00:16, 18 June 2021 (UTC)

"Template:Vendor item table row" breaks your definition by not storing information. --BuffsEverywhere (talk) 00:23, 18 June 2021 (UTC)

Again sorry, maybe I just failed to word it precisely. By "define/store information" I mean any kind of information, not necessarily smw properties. The defined/stored information can also be a wanted order, that for example can't be obtained by a smw query which might be the underlying procedure of related the table template. E.g. collection table using in-game order and collection table row allowing any order; but doesn't store any smw property. Still it defines information, namely the wanted order.

The template Vendor item table row had exactly five usages, where three could be replaced with a simple {{vendor table|item=<item>}}; one didn't match the related page format and one excluded a vendor which could be done with {{vendor table|item=<item>|vendor=!<vendor>}}. Should be cleaned up now. --Tolkyria (talk) 07:02, 18 June 2021 (UTC)

(Reset indent) I tried to clean up the vendor templates a bit and performed the following moves/category relabels:

Old template name	New template name	Notes
Vendor table header Vendor table row Vendor table row result format Vendor table notes	Vendor table header Vendor table row Vendor table row result format Vendor table notes	No changes. Defines vendor subobjects.
Vendor list Vendor list header Vendor list header notes Vendor list result format Vendor table notes	Sold by Sold by header Sold by header notes checker Sold by result format Vendor table notes	Upcoming rename. Item acquisition template.
Weapon set vendor list Weapon set vendor list result format	Weapon set sold by Weapon set sold by result format	Upcoming rename. Item acquisition template for collection pages.
Vendor table Vendor table header (query) Vendor table result format	Vendor query table Vendor query table header Vendor query table result format	Upcoming rename. Vendor queries.
Currency for Currency for header Currency for result format	Currency for Currency for header Currency for result format	No changes. Also vendor queries.
Vendor item table row Vendor item table header Vendor item table result format	Deprecated.	Unused template. Use {{Vendor table}} instead.
Service table Service table header Service table result format	Deprecated.	Unused template.
Vendor table row (simple subobjects) Vendor table row (simple)	Deprecated.	Unused template.

--Tolkyria (talk) 07:53, 18 June 2021 (UTC), Edited: --BuffsEverywhere (talk) 08:48, 23 June 2021 (UTC)

Thank you for cleaning up & deprecating the unused templates! We had way too many floating around. I still think "Vendor table" and "Vendor table row" are named too similarly, especially their headers. Perhaps rename "Vendor table" to "Vendor query"? --BuffsEverywhere (talk) 08:28, 18 June 2021 (UTC)

What about Vendor query table with Vendor query table header and Vendor query table result format to include the output format? But with ~500 pages using this template, this would be again a bot task. --Tolkyria (talk) 08:47, 18 June 2021 (UTC)

Okay, I agree with that suggestion. --BuffsEverywhere (talk) 09:11, 18 June 2021 (UTC)

Just stick a request on the bots page and we'll cover you. -Chieftain Alex 15:41, 18 June 2021 (UTC)

What about the template name Vendor table notes? Also the currently named template Vendor list header notes could be something more related like Vendor table notes checker.

Furthermore, I'm not sure what's the best way to determine if the column is needed or not. Note that the current template also triggers when the default limit of 50 is reached and thus the search label appears; haven't found an example yet, but try some basic equipment, e.g. {{vendor list|Apprentice Band}}.

In the vendor table row template the daily/total purchase limit it placed next to the item. What about placing it next to the vendor in this template?

--Tolkyria (talk) 22:27, 20 June 2021 (UTC)

Vendor table notes: I think should be renamed Vendor table row notes to reflect its usage in Vendor table row.

Vendor list header notes: I was planning to move it to Sold by header notes, however Sold by header notes checker is okay with me. I disagree with naming it Vendor table notes checker because it is solely used by the Vendor list / Sold by template so it should start with that name. Placing the purchase limits next to the vendor is an interesting idea but I am undecided if I like it (see my sandbox).

--BuffsEverywhere (talk) 15:56, 21 June 2021 (UTC)

Okay, the notes template is only called by templates, so it can actually be moved without further actions. I somehow want to connect the notes template name and its column checker as it could also be interesting to reuse it for the general vendor query template (currently named Vendor table).

Hmm, I'm not really convinced by my suggestion to put it next to the vendor. Brainstorming: we already list e.g. 10 for 1 <currency>, could we put it there? Otherwise, well, the notes column is the best place I guess. --Tolkyria (talk) 17:17, 21 June 2021 (UTC)

(Reset indent) As you say, the notes template and column checker can be easily moved later when required.
I don't agree with putting the purchase limit into the cost column. It wouldn't save much space.
What do you think about eventually merging Vendor list into Vendor table? They are almost the same with the exception of the item column. Vendor list could just call {{vendor table|item=x|showItem=false}}.
--BuffsEverywhere (talk)

I wouldn't do that, I think that would cripple us more than we would benefit from it.

• The facts first: Vendor list is used ~9500 times while Vendor table is used only ~500.
• Thus, I would keep the item acquisition template Vendor list as a lightweight template, exactly tailored to the needs of the section Sold by. Hence, no template overlaps or unnecessary code, just a standalone template with its own result format. So we can also easily adjust this template if necessary, since we know that it is only used in this context.
• The general template Vendor table covers a wide range of different queries and put them into one consistent format. So, the template and its result format might be a little bit heavier to cover all the cases, but it has only a comparable small size of usages that should compensate this.
  • If we want to reduce templates then we could merge the template Currency for (with ~50 usages) into the template Vendor table by adding a vendor outline parameter (1. sort by vendor, 2. hide location column, 3. add #ifeq vendor check).

--Tolkyria (talk) 08:43, 22 June 2021 (UTC)

You're right, it would be a bad idea to merge Vendor list.

Regarding merging Currency for, I created that template to be able to clearly see what each merchant has for sale because Vendor table does an awful job if the item is used to buy lots of things (for example Festival Token). It's really a mess to dump so many items & vendors into a single table. I disagree with merging it.

I've edited the table above to reflect the discussion so far. --BuffsEverywhere (talk) 08:48, 23 June 2021 (UTC)

You would see no visual difference between {{currency for|<currency>}} and my proposed template merge with a new parameter "outline": {{vendor table|currency=<currency>|outline=vendor}}. As described above, we would only need the following changes: "1. sort by vendor, 2. hide location column, 3. add #ifeq vendor check" and 4. disable intro template as it is called in #ifeq in the result format. --Tolkyria (talk) 11:12, 23 June 2021 (UTC)

Okay, if it looks the same, I would not be opposed to merging it.

I will submit a bot request for the renames if we are happy with the new names in the table above. --BuffsEverywhere (talk) 23:11, 25 June 2021 (UTC)

Added "Weapon set vendor list" to the table. Side note Guild Wars 2 Wiki talk:Community portal/Archive 20#Rename "Vendors" section on item pages was somewhat left open. Some sections are named "Currency for" some are "Vendors". What is the current stance on that? Please update Guild Wars 2 Wiki:Item formatting accordingly. —Kvothe (talk) 15:11, 28 June 2021 (UTC)

Okay, bot request raised.

I guess the difference between using "currency for" and "vendors" is depending on which template looks better on that page, lol. We didn't come to a definitive conclusion on that discussion. --BuffsEverywhere (talk) 23:34, 8 July 2021 (UTC)

I would remove anything related to "currency for", i.e. 1. merge the template currency for into the template vendor query table with the parameter "currency" and the new parameter "outline=vendor" (the table query template supports it now, see here) 2. replace the template transclusions (probably by hand, they are only 50 and might need individual treatment anyways) and 3. rename the headings to "Vendors" or "Related vendors". --Tolkyria (talk) 09:34, 9 July 2021 (UTC)

Edit: So I checked the pages using the template currency for, and this should be definitely done by hand.

For example

• Amalgamated Draconic Lodestone has exactly one result, there's really no need to outline it.
• However, at Ascended Shard of Glory with lots of related vendor items it makes sense to outline the vendor and thus introduce an additional level of grouping.

Hence, in my opinion it should be decided from page to page where the new outline parameter from the template vendor query table is needed.

Furthermore, there are pages with the heading "Vendors" and the template Currency for (e.g. Crystalline Ore) and pages with the heading "Currency for" and the template Vendor (query) table. Seriously, that's pretty much what the whole discussion is about, easy, straight-forward and matching section and template names. How should an (especially new) editor be able to understand this?

This may sound harsh, but if we really want to provide consistent and straight forward vendor templates (names), then the currency for template has to go (and to be honest should have never been added or bot-edit-added). Also, the fixation of the format from currency for template which is always outlined - another example: Confiscated Food or Skritt Support Mark - is restricting us heavily, not allowing us to present it properly. Thus the new parameter "outline" for vendor query table, add it manually where it is needed.

Once again, please also reintroduce consistent headings, having sometimes "Currency for" and sometimes "Vendors" without any obvious reason is just awful; I vote for "Vendors". --Tolkyria (talk) 16:12, 9 July 2021 (UTC)

(Reset indent) I don't object to removing "Template:currency for" now that {{vendor query table}} can do the same thing. I agree that we should make the headings consistent but I still don't really like "Vendors". --BuffsEverywhere (talk) 22:46, 9 July 2021 (UTC)

Waypoint chat links

I feel like we need to talk about the insane amount of 40,000 (Edit: wrong assumption, see new approach below) waypoint chat links that have been created by this recent edit, adding a waypoint chat link if the "located in" location type is an area.

This means 40,000 (Edit: wrong assumption) template map link → template game link → widget game link transclusions. On the one hand we are currently trying to get rid of uncessary code and speed up things a little bit and on the other hand we add this. For comparsion, before this edit we were using 4,000 waypoint chat links it total, this single edit literally introduced ten times more. Furthermore, the waypoint is selected by pure guessing, it neither takes the nearest waypoint into account (for example if there are two waypoints in one zone) nor displays a waypoint if there isn't one in the zone but directly next to it.

Thus, my question: Is this edit really necessary and can it be justified reasonably?

I assumed the numbers based on the following:

Facts

• For comparison, before this edit we were displaying ~4,000 waypoint links:
  • The template waypoint is used on ~1,000 pages with ~3,100 occurences in total.
  • The template map objective is used on ~700 pages for ~850 waypoints.
• The template sold by is called on ~9,700 pages.
• We currently store ~57,800 vendor subobjects, each of them storing a sold item that - assuming the simplest case - is also presented in an table row in the query template sold by.
• Taking however only the vendor subobjects into account that have a location set of the location type area (related to this template edit), then the amount of subobjects is limited to ~40,900.

Assumptions

• The actual number of how many map links this edit introduced is hard to determine.
• For example I only counted how many subobjects have at least one location of type area, they could have more areas, each of them displaying a waypoint map link in sold by table. Conservatively I'll assume one map link for each of the ~40,900 subobjects.
• Furthermore, I don't know how many items do not use the template sold by although they are stored in a vendor subobject, e.g using a plain text acquisition description instead of sold by. Optimistically, I will assume that all item acquisitions are pretty much complete; alternatively it may outweight with the previous consercative assumption. (Edit: wrong, there are standard items that are sold by over 100 vendors, e.g. gathering tools sold by ~400 vendors, while these item pages simply list them in plain text)
• Combining these two assumptions, I came up with ~40,000 (Edit: wrong assumption) new waypoint links.

Still missing

• It would be interesting to know how often the parent template game link is used to get a total sum of game links on the wiki. So far I know that it is used 58681 pages but not the amount of their occurences on these pages. We currently store 90166 game ids, the question is how often are this used in a game link template? Twice, three times or even five times, the ~40000 new waypoint chat links will always remain an incredible high number compared to it.

Sources

• Vendor subobjects: {{#ask: [[Has vendor::+]]|format=count}}
• Vendor subobjects with location type area: {{#ask: [[Has vendor::+]][[Located in.Has location type::Area]]|format=count}}
• Waypoints: {{#ask: [[Has location type::Waypoint]]|format=count}}
• Pages storing waypoints: {{#ask: [[Has subobject.Has location type::Waypoint]]|format=count}}
• Form:Parameter check with parameter template = waypoint and template = sold by.

--Tolkyria (talk) 10:42, 1 October 2021 (UTC)

Sorry, my bad, I made a wrong assumption by forgetting the standard merchant items (e.g. salvage or gathering tools sold by ~400 merchants) which in general do not use the sold by query and thus drastically reduce the assumed amount.

Different approach

• Check for the query string: {{#ask: [[-Has subobject::@@@]][[Has location type::Waypoint]]| ...}} used in the template with {{#ask: [[:+]][[Query string::~*-Has subobject::*Has location type::Waypoint*]]|?Query string|format=count}} (smw:Help:Querying for queries). Note that this search shows that no other query has the asked for query string format.
• This count query returns 18,609 as the number of queries performed to obtain a waypoint game id. To be precise this does not mean that all of these queries actually return a waypoint id (as the area doesn't have a waypoint) and thus provide a waypoint chat link, but it's a much more accurate number than my previous assumption. Thus, I would still like to ask how reasonable displaying the waypoint chat link is and if we really need it.

--Tolkyria (talk) 16:01, 1 October 2021 (UTC)

I'm biased because I added it, but I think it's worthwhile. Even though not all areas have a waypoint, showing the ones that do is still an improvement in usability. It will display a waypoint for most npcs and even if not it's not worse than before. --BuffsEverywhere (talk) 17:22, 1 October 2021 (UTC)

How would I represent content in a table?

1. Make sure that it's correct and consistent. This is not the case here due to the random selection, as mentioned before, there's no way to select the nearest waypoint, sometime a waypoint is linked next to an area, sometimes not. It's simply inconsistent for no obvious reason from a wiki user's perspective, causing more confusion than helping actually.
2. Make sure that it's readable by aligning it properly, especially by aligning the icons. This is not the case here, the waypoint icons are floating all across the table wildly.
3. Make sure that it's understandable. Simply putting a waypoint link without the waypoint name feels wierd, the users have to associate a term (here the waypoint name) with the in-game chat link (serving as an internal check: I copied the waypoint link with this name and in-game the link gives me the waypoint with the same name).

So basically this edit fails at all three points. Have you actually checked it how it looks like on items that are sold by differnt vendors? Two vendors have no waypoint chat link, then the next vendor has one chat link, then one vendor again without, then one vendor with ten locations, the first six have a waypoint link, the following three don't, the last has a waypoint link. I mean how should a wiki user deal with this? This is clearly not an improvement in my eyes. It's okay to say sorry we can't achieve it rather than presenting a half baked solution that's incomplete and inconsistent. Furthermore, adding this half baked solution to nearly 10,000 pages with around 18,000 table rows using it. --Tolkyria (talk) 20:13, 1 October 2021 (UTC)

I agree that this solution isn't ideal. I did test it but I was okay with some inconsistency if it reduced the need to visit another page (which is a common wiki complaint). But after having it for a few weeks, I also don't know if this addition has actually been useful. I'm inclined on removing it because of the widget bug that makes them not load some of the time. The waypoint links get stuck on loading until the page is refreshed which makes it useless. --BuffsEverywhere (talk) 10:47, 13 October 2021 (UTC)

To be precise: It has nothing to do with widgets, that's the Common.js loading bug that also appears on collapsed tables/navigation templates, which are sometimes expanded on page load, or not displayed trading post prices. The widgets themself are loading absolutely fine, it's the code design of certain widgets (most likely combined with the new search engine) that triggers a case where the crucial widget code parts are not executed. I.e. a global variable is incremented each time the widget is called, if it's equal to "1" then the code part is executed exactly once (to avoid duplicate calls); however, the widget loading bug is that presumably the global variable is even more global than intended - probably due to the new search engine it takes several pages into account - and does not start at "1" (e.g. instead it starts at 233 or 1548). Hence the required widget code part that does the essential computation isn't executed at all. Speaking of it, the site note has been up for almost 3 weeks stating that widgets are technical difficulties, but not a single widget nor the bug report page have been edited since.

Okay, this got quite lengthy, regarding the topic itself: In the end this is still a wiki and not some random guide:

1. So it's totally legit to spread information on different pages and not have all information available on one page.
2. We are bound to a certain degree to general formatting guidelines, some random guide can throw the previously used format overboard anytime, we can't.
3. The wiki uses a large amount of automatization, but not every aspect can be done automatically. In my opinion it's better to accept it instead of trying to make it possible at all cost and end up an unsatisfying solution.

Regarding 3: I think the current properties are not suited for the nearest waypoint approach, we would need that each waypoint has coordinates, each vendor has coordinates (currently only ~50% of the service NPCs have coordinates set), a template that computes the nearest waypoint based on the vendor coordinates and then in my opinion it's still better to only set this on the vendor page. Futhermore, no wiki editor will apply this procedure to the current pages and especially noone will be here to maintain this for all upcoming NPCs in the future; to be honest we failed at much easier NPCs tasks. --Tolkyria (talk) 12:03, 13 October 2021 (UTC)

Remove non existing vendors from templates for item acquisition

Link to discussion: Guild Wars 2 Wiki talk:Community portal/Archive 23#Remove non existing vendors from templates for item acquisition

Just adding this link here for future reference. —Kvothe (talk) 14:04, 15 August 2022 (UTC)