Template talk:PH wikidata

Observations

This is great, but some observations:

Property:P150 contains administrative territorial entity should contain a list. It contains a type (e.g.Purok) only by my mistake.
I think the inclusion of property 481 – Palissy identifier = identifier in the Palissy database of moveable objects of French cultural heritage within area_code is not right – this is a Philippine template, nothing to do with French.
Some other likely-properties, e.g. Income classification, are waiting on wikidata action.

--Unbuttered parsnip (talk) mytime= Fri 09:50, wikitime= 01:50, 3 April 2015 (UTC)[reply]

will add tracking to find incorrect uses of P150 and P481. note that we should be careful that we don't use wikidata in cases where it would be awkward or problematic. for example, getting the name of the current mayor from wikidata, but setting the party affiliation here. when the name changes, the affiliation won't change as well. another is pulling the date of foundation from wikidata, but setting the labels here. if the dates are changed on wikidata (e.g., inserting another founding date or removing one), then the labels will be out of sync. also, 'br' delimited lists for the data with 'br' delimited lists for the labels is bad for wp:accessibility. Frietjes (talk) 15:23, 3 April 2015 (UTC)[reply]

fixed all P150 and P481, note that we need to have a default for the leader titles. otherwise, if the property doesn't exist on wikidata, the values set for leader_name won't show in the infobox. Frietjes (talk) 16:34, 3 April 2015 (UTC)[reply]

@Frietjes: Thanks for a brilliant piece of work. Sorry you got lumbered like this – Sistine Chapel V ceiling painting! I suppose it's better sooner than later, and had to be done anyway.
I must admit, I could never work out what {{safesubst:}} is supposed to do. If it permanently transcludes the outcome, doesn't that rather lose the whole point of wikidata, for instance with population?
To be honest, I don't think it at all right to hold leader_name in wikidata, not unless the entire council is also held. It makes no point to me to obtain the mayor's name from one source, but all the others are hard-coded into the invocation. I've never actually come across any use of the wikidata property.
I agree about lists such as establishment_date(s), but that is a wikidata problem that is not at the moment surmountable (or doesn't appear so). Basically there is a single property "inception" which can have multiple instantiations. Nor is it currently possible to extract from the list one by one. I could envisage a module to do that, but don't have the knowledge to write it.
Similarly, I would like to be able to take the csv list and form it into something like a {{collapsible list}} á la {{PH Town Council}}. All I've done so far is work out a way to find out how many elements are in the list – I don't know (is there a way?) how to pass the elements as pipe-separated variables to another template. There seem to be a couple of FOR...LOOP templates, but they don't seem entirely appropriate. The use of the second parameter would be to modify the output style (csv, ubl, etc.), rather than modify the content.
One more thing – I have requested a few new properties, such as electorate and income classification. I am currently working on a template which takes the spreadsheet provided by Comelec and returns the voter numbers for a PSGC (municipality level or greater). The figures also contain a lot, but not 100%, of figures for male and female, which makes an interesting demographic. My point is that I thought I could incorporate that into this template, even though it's not actually wikidata (yet). That would save a blanket update later when it is.
Unbuttered parsnip (talk) mytime= Sat 08:49, wikitime= 00:49, 4 April 2015 (UTC)[reply]

PH wikidata used in Template:Commons category (and similar templates)

Hello

using the template PH Wikidata like this {{Commons category|{{PH wikidata|commons}}}} leads to the fact that the corresponding page is listed in Category:Commons category template with no category set. --Robby (talk) 11:13, 31 January 2016 (UTC)[reply]

Robby, which page? I would imagine that's only the case if the property is not set at wikidata. we could make the template default to the article name when the property isn't set at wikidata. Frietjes (talk) 15:51, 22 February 2016 (UTC)[reply]

Hello Frietjes, there is for instance the page Alicia, Bohol. --Robby (talk) 18:26, 22 February 2016 (UTC)[reply]

Robby, I just added the commons category link to the wikidata page and now it's not in the category. I don't really see being in Category:Commons category template with no category set as necessarily a bad thing, since by default {{Commons category}} uses the wikidata or the pagename, whichever is not blank. but, it is good to make sure that the commons category is in the wikidata, so perhaps we could make a way to track when this template is being invoked to get the commons category and returns nothing? Frietjes (talk) 18:40, 22 February 2016 (UTC)[reply]

Frietjes, the aim of my post here was to make aware of this behaviour. Indeed the category Category:Commons category template with no category set should (according to my understanding) help to find out pages where {{Commons category}} is used without parameters and where the author has not verifed wheter the according category is existing on Commons. According to my conviction we should avoid to have links on wikipedia whose target does not exist. --Robby (talk) 18:57, 22 February 2016 (UTC)[reply]

Robby, you can now find the offending pages with this search. Frietjes (talk) 00:51, 24 February 2016 (UTC)[reply]

Use of this template

(pinging @Frietjes:, as I see you've made many edits to the template): Hello all watchers! I see the {{PH wikidata|seat}} template used in the Philippine province articles, and each use where the capital is not at the base name (for example, the capital of Catanduanes is Virac, which is at Virac, Catanduanes) is causing a link to the incorrect page in the article (Virac is a disambiguation page, not the article for the city). Can anyone take a look at this? Thanks in advance! -Niceguyedc ^{Go Huskies!} 08:08, 1 May 2016 (UTC)[reply]

Niceguyedc, fixed, thank you for noticing. Frietjes (talk) 13:09, 1 May 2016 (UTC)[reply]

Population_as_of

Hi @Frietjes: When adding the 2015 census data to Wikidata, the field {{PH wikidata|population_as_of}} returns the word "census" twice, see Anda, Bohol. I can't see where this error creeps in. Can you look into this? Thanks. -- P 1 9 9 ✉ 14:52, 20 May 2016 (UTC)[reply]

User:P199, fixed, there was an inconsistency in how data items with multiple entries were being parsed. Frietjes (talk) 15:13, 20 May 2016 (UTC)[reply]

Thanks for the quick fix. -- P 1 9 9 ✉ 15:15, 20 May 2016 (UTC)[reply]

Image_skyline

How to use image_skyline when it returns two values and we need only one, for example for Manila infobox if one wanted to use it there as |image_skyline={{PH wikidata|image_skyline}}?

What if one wanted to use second image for wide image template, in same example I've mentioned above?

Btw, could someone tell me how to add translation for "Metro Manila" on Wikidata in order for it to get translated in map caption generated by {{PH wikidata|map_caption}}? /I ask this for other Wikipedia I'm writing this article on./ --Obsuser (talk) 13:19, 19 September 2016 (UTC)[reply]

Obsuser, the multiple image problem should be fixed now. you can set the "priority" for the images in wikidata. as far as the caption translation goes, I am pretty sure you have different values for the caption depending on the language. it's just up to the code which grabs the caption to grab the correct language. usually it uses the site default language unless told otherwise (see module:wikidata for examples). Frietjes (talk) 14:07, 19 September 2016 (UTC)[reply]

Obsuser, I just checked and if you click on 'edit' for the image, then there should be a button for 'add qualifier'. if you click on that, you can select 'legend' and enter a legend with the corresponding two or three letter language code. I just did this for Manila, and set the priority for the montage. Frietjes (talk) 14:18, 19 September 2016 (UTC)[reply]

@Frietjes: OK, image is now good. Or not: Caption in Cyrillic script is cut off just after a few words – maybe due to the "weight" of the script...

Still don't know how to add translation for Metro Manila in "located next to body of water" where it says ^English for me when I change language on Wikidata (for Serbian it reads verbatim ^{енглески} right to the "Metro Manila" in "се налази у" property for "српски / srpski" chosen language). Or, maybe, article needs to exist on sr.wiki in order to get this translated (after Serbian article for Metro Manila is linked on Wikidata to Q13580)?

Thank you for fast response, however. --Obsuser (talk) 14:44, 19 September 2016 (UTC)[reply]

I've tried to make caption working but no success. Don't know why it cannot display values for P2096 comma separated (although, even if it would work that way, it would be ugly solution). For English caption, it is not possible to link Manila Bay because then ]] are chopped off from Tondo Church...--Obsuser (talk) 15:24, 19 September 2016 (UTC)[reply]

Obsuser, there probably is a limit on the total length of the caption. if there are multiple entries for one property (for example more than one image), then the query returns all of them. modules like Module:Wikidata then turn that list into comma separated entries, but in wikidata they are separate entries. if you are having problems with something getting cut off, you may have better luck asking at WikiData site, or at Module talk:Wikidata, or at WP:VPT. Frietjes (talk) 15:39, 19 September 2016 (UTC)[reply]

Parser function error

At Pamilacan, the two uses of {{PH wikidata|population_total}} are returning a figure of 1,422±0. Presumably because of the non-digit character ±, the occurrence in {{Infobox islands}} is causing an error message to appear in the "Pop. density" field. I'm too ignorant in template-fu to figure out what the problem is. Can anyone help? Deor (talk) 22:37, 17 November 2016 (UTC)[reply]

I removed ±0 on Wikidata so that {{convert}} template get parsable number. --Obsuser (talk) 22:48, 17 November 2016 (UTC)[reply]

I've just encoutered this error in Manila article too. It is wierd because upper and lower bounds (± values) seem to be added on Wikidata by themselves, thus causing conversion errors in articles. Someone changed something somewhere and it causes errors...--Obsuser (talk) 23:27, 17 November 2016 (UTC)[reply]

There are over 20 articles in Category:Convert errors and looking at a couple of them suggests they are due to this issue. In any of the articles, search for "convert:" (with colon), then hold the mouse over the "invalid number" message. That shows a popup mentioning ±. In principle, convert could ignore ±0 or possibly even ±12.3, but it might be better if Wikidata templates omitted it? @Frietjes: you have been working on this template; what do you think? Johnuniq (talk) 01:44, 19 November 2016 (UTC)[reply]

I had forgotten that convert can handle some Wikidata properties. For example, Cavite is Cavite (Q13785) and its area can be found from area (P2046) using:

{{convert|input=P2046|qid=Q13785}} → 1,574.17 square kilometres (607.79 sq mi)

If editing Cavite, the qid would be omitted (just {{convert|input=P2046}}).

I do not understand {{PH wikidata}}. For example, the population_total item includes the following (split into separate lines, and with safesubst omitted):

{{#invoke:string|replace
|{{#invoke:Wikidata|getValue|P1082|FETCH_WIKIDATA}}
|([%d]), .*
|%1
|plain=false
}}

What is the regex (([%d]), .*) doing? If P1082 returned "1,234, junk", the result of the replace would be "4". What is that used for?

The regex for cleaning area (P2046) is " %D+" and omitting the space would remove the ±0. Perhaps Wikidata used to output a space there? Johnuniq (talk) 05:40, 19 November 2016 (UTC)[reply]

There are now 230 articles in Category:Convert errors. One option would be to replace the following in affected articles:

{{convert|{{PH wikidata|area}}|km2}}

with

{{convert|input=P2046}}

I think that will do the same job and it appears to work, and it would remove some of the errors. Or some tweaking of this template could remove "±0" but that would be pretty ugly as a lot of items potentially need that treatment. There should be some more robust way of extracting wikidata using a module, and perhaps some of convert's code would be helpful. Johnuniq (talk) 09:16, 19 November 2016 (UTC)[reply]

I think ([%d]), .* regex mentioned above is for fixing comma separated not needed imports of properties with multiple defined values on Wikidata of which none has been marked as with preferred rank (although we need only one). If P1082 returned "1,234, junk", the result of the replace I guess would not be "4" but "1". --Obsuser (talk) 11:09, 19 November 2016 (UTC)[reply]

Johnuniq, Obsuser, Deor, I fixed it by filtering out the ±0 with string replacement. the regexp for cleaning the area removes the " square kilometres" after the number. The %D means anything that is not a digit (see this section of the LUA manual). the regexp for cleaning the population is when there are multiple population figures for multiple years, but none with a preferred rank. I had added some tracking to check when this was necessary so that we could go into wikidata and add a preferred rank. I have now augmented these string replacements to include removal of the ±0. in my opinion, the best option would be to be able to tell Module:Wikidata to return the bare number, without the uncertainty and without the units. or, in the case that there are units, ask it to return the bare number in the requested units. then, Module:Wikidata could call convert if the units requested don't match the units returned from wikidata. Frietjes (talk) 14:32, 19 November 2016 (UTC)[reply]

Thanks for the fix. I only vaguely recall Module:Convert/wikidata but I think I looked at Module:Wikidata at the time and found it was determining the text representation of the value (intended for display). As I recall, I made Module:Convert/wikidata use a different procedure to get the bare value, I hope with the highest rank. I did that because the human-readable value is not what is wanted, and its format is certain to change as people fiddle with Wikidata. If my recollection is correct, Module:Wikidata might benefit from some tweaks. Johnuniq (talk) 07:12, 20 November 2016 (UTC)[reply]

CA wikidata

Hi @Frietjes:. Thanks for all your work on this template. Can you make a template like this one, but tailored for Canadian infoboxes? Maybe call it {{CA wikidata}}. Thanks in advance. -- P 1 9 9 ✉ 20:32, 26 April 2017 (UTC)[reply]

P199, sure. we just need a list of commonly used property numbers to get started. I am assuming that we could probably start with the list used here and remove/add as needed. Frietjes (talk) 21:13, 26 April 2017 (UTC)[reply]

@Frietjes and P199: - I think would better to move into two groups: one is those PH-only; and the others are common. Then obvious only the PH-only ones who need to be CA-only. 112.198.71.216 (talk) 07:58, 14 May 2017 (UTC)[reply]

@Frietjes and P199: - it also needs to work on {{VN wikidata}} and {{TH wikidata}} (etc.) – 82.203.24.241 (talk) 09:52, 1 June 2017 (UTC)[reply]

Timezone

@Frietjes: The new timezone function is causing Module:String errors. Not sure what's wrong with it. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:40, 10 July 2017 (UTC)[reply]

Jc86035, probably fixed now. you can't gsub an empty string. Frietjes (talk) 13:01, 10 July 2017 (UTC)[reply]

@Frietjes: Thanks. Upon closer inspection it seems to be using |qualifier= of Module:Wikidata incorrectly, and it's supposed to call data for another item ~~when the module doesn't actually support doing that~~. In any case it could just be replaced with hard-coded values since the entire country has the same time zone. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:42, 10 July 2017 (UTC)[reply]

Jc86035, go ahead and change it, or change it back to just using 'property:P2907'. I don't have an article for debugging it at hand at the moment. Frietjes (talk) 13:45, 10 July 2017 (UTC)[reply]

@Frietjes: Try Cebu City. The module doc says calling data from another item (§ Arbitrary Access) is expensive, so I'm not sure if it should be added here. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:48, 10 July 2017 (UTC)[reply]

Jc86035, okay, done. Frietjes (talk) 13:52, 10 July 2017 (UTC)[reply]

template:PH wikidata (again)

There are several things wrong about {{PH wikidata}} but I can't change it myself:

1 |settlement-type= has been changed for some cities. Their type has been changed to highly urbanized city (Q29946056) (by seav (talk · contribs) around 15 aug 2017). So the template needs changing to add this type. It may be a useful time to add further settlement-type purok (Q7261368) though hopefully there wouldn't be any use (ever!). Similarly, there may be a new type "independent city" to consider, although is hasn't been made yet.

<includeonly>{{safesubst:#switch:{{safesubst:lc:{{{1|}}}}}
| settlement_type = {{safesubst:#switch:{{safesubst:lc:{{safesubst:#property:P31}}}}
 |=
 |barangay = [[Barangay]]
 |island group = Islands
 |municipality of the philippines = [[Municipalities of the Philippines|Municipality]]
 |city of the philippines = [[Cities of the Philippines|{{safesubst:#switch:{{{prefix}}}| cc = Component| icc = Independent Component}}City]]
→|highly urbanized city = [[Cities of the Philippines#Highly Urbanized City|Highly Urbanized City]]        ← ← ←
 |province of the philippines = [[Provinces of the Philippines|Province]]
→|purok = [[Purok]]                                                                                        ← ← ←
 |#default = {{safesubst:#invoke:Wikidata|getValue|P31|FETCH_WIKIDATA}}
 }}
:
| council_title = {{safesubst:#switch:{{safesubst:lc:{{safesubst:#property:P31}}}}
→|purok                                                                                                   ← ← ←
 |barangay = [[Sangguniang Barangay|Brgy Council]]
 |municipality of the philippines = [[Sangguniang Bayan|Town Council]]
→|highly urbanized city                                                                                   ← ← ←
 |city of the philippines = [[Sangguniang Panlungsod|City Council]]
 |province of the philippines = [[Sangguniang Panlalawigan|Provincial Board]]
 |#default = Council
 }}
:
| settlement_text = {{safesubst:#switch:{{safesubst:lc:{{safesubst:#property:P31}}}}
→|purok = purok                                                                                          ← ← ←
 |barangay = barangay
 |island group = island group
 |municipality of the philippines = municipality
 |city of the philippines = {{safesubst:#switch:{{{prefix}}}| cc = component| icc = independent component}} city
→|highly urbanized city = highly urbanized city                                                          ← ← ←
 |province of the philippines = {{safesubst:#switch:{{{prefix}}}| is = island}} province
 |#default = {{safesubst:#invoke:Wikidata|getValue|P31|FETCH_WIKIDATA}}
 }}
| government_type = {{safesubst:#switch:{{safesubst:lc:{{safesubst:#property:P31}}}}
→|purok                                                                                                  ← ← ←
 |barangay = {{safesubst:nowrap|[[Sangguniang Barangay]]}}
 |municipality of the philippines = {{safesubst:nowrap|[[Sangguniang Bayan]]}}
→|highly urbanized city                                                                                  ← ← ←
 |city of the philippines = {{safesubst:nowrap|[[Sangguniang Panlungsod]]}}
 |province of the philippines = [[Sangguniang Panlalawigan]]
 }}

2 several parameters have had the underlying wikidata changed, without any document:

|language= have changed of use from languages spoken, written or signed (P1412) to language used (P2936) (by Exec8 (talk · contribs) around 23 jul 2017)
|name= get the wrong value (by Exec8 (talk · contribs) around 8 sep 2017)
|diocese= changed from part of (P361) to diocese (P708)
|climate_type= has changed from {{abbr|{{safesubst:#invoke:Wikidata|claim|P2564|qualifier=P1813}}|{{safesubst:#property:P2564}}}} to {{{{safesubst:#invoke:Wikidata|getValue|P2564|FETCH_WIKIDATA}} (by Exec8 (talk · contribs) around 23 jul 2017), and changed value of |climate_title=. In addition, most places municpalities or cities (in Cebu at least) have been given two values, e.g. tropical rainforest climate (Q209531) as well as tropical climate (Q135712).
In Philippines at least, there is another climate measure, Coronas Climate Types, whose values are 1 to 4, usually in roman numerals.

There has been no documentation at all, neither at Template talk:PH wikidata nor at any Edit summary.

3 the use of legislative body (P194) doesn't seem right. Not many places have got one, but those who do have been a given unique values, e.g. Alcantara, Cebu has Sangguniang Bayan of Alcantara (Q22443277). I think these are completely wrong. I think instance of (P31) should have a value of e.g. municipal council of a Philippines municipality (Q7417956) (for municipalities), city council of a Philippines city (Q7417960) for cities, etc. I don't think unique values like this should be put in wikidata. Currently, |government_type= is taken as text via instance of (P31). Maybe this should be change to basic form of government (P122) and municipal council of a Philippines municipality (Q7417956) etc.

(Too many editors go for OR rather than SECONDARY.
Also of course, live templates (or anything live) should not be used as a sandbox.)

4 I think should be used for other infoboxes as well as {{Infobox settlement}}. I would like better used of:

{{Infobox airport}} including some new items needed for Philippines airstrips
(see Doc 8400, Procedures for Air Navigation Services - ICAO Abbreviations and Codes (Eighth ed.). ICAO. 2010. ISBN 978-9292316266.)

for e.g. Hours code HJ / HN / HO etc.

Services FSS Flight service station etc.

Lighting PCL Pilot-controlled lighting etc. (Small airstrips, e.g. Siquijor Airport, have no lights at all.)

{{Infobox lighthouse}}

add {{PH wikidata}} items

|focalheight= focal height (P2923)

|range= lighthouse range (P2929)

|characteristic= light characteristic (P1030)

|height= height (P2048)

|NGA= NGA lighthouse ID (P3563)

|ARLHS= ARLHS lighthouse ID (P2980) etc.

adds new parameter |light sector= light sector (P3922) to add to {{Infobox lighthouse}}

5 {{DILG detail}} has to change similarly to {{PH wikidata}} (but less)

{{#if:{{{1|}}}| {{thinsp}} &lt;ref&gt; {{#switch:{{PH wikidata|settlement_text}}
 | municipality = {{cite web
  | url         = http://web.archive.org/web/20130531043557/http://dilg.gov.ph/municipalities.php
  | title       = Municipality
  | publisher   = Department of the Interior and Local Government
  | location    = Quezon City, Philippines
  | accessdate  = 31 May 2013
  }}
→| highly urbanized city                                                                                         ← ← ←
→| huc                                                                                                           ← ← ←
→| independent city                                                                                              ← ← ←
 | city         = {{cite web
  | url         = http://web.archive.org/web/20130530144453/http://dilg.gov.ph/cities.php
  | title       = City
  | publisher   = Department of the Interior and Local Government
  | location    = Quezon City, Philippines
  | accessdate  = 30 May 2013
  }}
 | province     = {{cite web
  | url         = http://web.archive.org/web/20130530173153/http://dilg.gov.ph/provinces.php
  | title       = Province
  | publisher   = Department of the Interior and Local Government
  | location    = Quezon City, Philippines
  | accessdate  = 30 May 2013
  }}
 }}&lt;/ref&gt;}}

Sorry this message is so long. 49.145.128.113 (talk) 02:26, 21 January 2018 (UTC)[reply]

Sorry there was another problem I forgot before.

6 the problem with |coordinates= is that it makes an error if there is more than one use. I think it should be corrected:

| coord | coordinates = {{safesubst:#if:{{safesubst:#property:P625}}|{{coord|region:{{safesubst:PH wikidata/iso}}{{safesubst:#ifeq:{{safesubst:lc:{{safesubst:#property:P31}}}}|province of the philippines|_type:adm1st}}{{safesubst:#if:{{{dim|}}}|_dim:{{{dim}}}}}|format=dms|display=inline,title}} }}

should be changed to

| coord | coordinates = {{safesubst:#if:{{safesubst:#property:P625}}|{{coord|region:{{safesubst:PH wikidata/iso}}{{safesubst:#ifeq:{{safesubst:lc:{{safesubst:#property:P31}}}}|province of the philippines|_type:adm1st}}{{safesubst:#if:{{{dim|}}}|_dim:{{{dim}}}}}|format=dms|display={{safesubst:{{{display|it}}}}}}} }}

so that sub-para should be |display=i

49.145.128.113 (talk) 10:14, 21 January 2018 (UTC)[reply]

Problems

In Flora, Apayao |image map = {{PH wikidata|image map}} links to File:Ph locator apayao flora.png, Ph locator apayao flora.png instead of File:Ph locator apayao flora.png.
In Silvino Lobos, Northern Samar |image map = {{PH wikidata|image map}} links to File:Ph locator northern samar silvino lobos.png, Ph locator northern samar silvino lobos.png instead of File:Ph locator northern samar silvino lobos.png

Could someone please look into those? Thanks. -- Radiphus 11:34, 19 February 2018 (UTC)[reply]

Someone has fixed it. Thanks again. -- Radiphus 11:42, 19 February 2018 (UTC)[reply]

Hi Radiphus it's because there was duplicate entries added on wikidata, you can clear these errors by deleting the duplicate like this and doing an edit/save on the article. Cheers KylieTastic (talk) 11:44, 19 February 2018 (UTC)[reply]

Elevation metre/meter

Some articles using this template have been broken by a change in Wikidata. For example, Capitancillo Island has:

elevation m = {{PH wikidata|elevation_m}}

and {{#property:P2044}} in the article gives "4.5 meter". The unit metre (Q11573) was recently changed from "metre" (which this template expects) to "meter". I raised the issue here but whatever the outcome of that, the template is too fragile. The template tries to remove any uncertainty and any unit text but it only looks for "metre". There probably should be a module that cleans value/units from Wikidata because adding yet another #invoke:String|replace is most unappealing. Hmm, there probably is a module which would just get the plain value without any dependency on decorations that may be returned by #property, but would that be much more inefficient than #property? Thoughts? @RexxS: Do you want to offer an opinion? Johnuniq (talk) 03:07, 28 October 2018 (UTC)[reply]

Johnuniq, I fixed it for now, but I agree there must be a better way to do this. looking at Template:Infobox telescope, it looks like we can use {{convert|input=P2044|m|m|disp=number}}? if this is safe, then we can use

| elevation_m = {{convert|input=P2044|m|m|disp=number}}
| elevation_ft = {{convert|input=P2044|ft|ft|disp=number}}

we want only one of elevation_m and elevation_ft to be non-blank since the infobox should do the rest. so, if the wikidata elevation is in ft, we want m to be blank and ft to have the elevation in ft. if the wikidata elevation is in m, we want ft to be blank and m to have the elevation in m. Frietjes (talk) 17:10, 28 October 2018 (UTC)[reply]

@Johnuniq: There is a stipulation in Wikidata that the quantity stored should be in feet, metres or kilometres. But it actually might be found in miles or even inches because there's nothing stopping anyone from using whatever units they want to. See d:Wikidata:Database reports/Constraint violations/P2044#Units for the statistics. So how robust do you want the template to be? Do you want to cope with any possible length unit or simply fix the errors on Wikidata when we spot them?

Using WikidataIB we have some choice on what is displayed. We could get:

for elevation above sea level (P2044), Capitancillo (Q18208369):

{{wdib |qid=Q18208369 |P2044 |ps=1}} → 4.5 metre
{{wdib |qid=Q18208369 |P2044 |ps=1 |lang=en-gb}} → 4.5 metre
{{wdib |qid=Q18208369 |P2044 |ps=1 |uabbr=y}} → 4.5 m

for elevation above sea level (P2044), 1970 Mount Everest disaster (Q4574072):

{{wdib |qid=Q4574072 |P2044 |ps=1} → 8,848 metre
{{wdib |qid=Q4574072 |P2044 |ps=1 |lang=en-gb}} → 8,848 metre
{{wdib |qid=Q4574072 |P2044 |ps=1 |uabbr=y}} → 8,848 m

for elevation above sea level (P2044), International Space Station (Q25271):

{{wdib |qid=Q25271 |P2044 |ps=1}} →
{{wdib |qid=Q25271 |P2044 |ps=1 |lang=en-gb}} →
{{wdib |qid=Q25271 |P2044 |ps=1 |uabbr=y}} →

We could use {{wd}} or {{#invoke:Wikidata |getUnits}} to fetch just the units and switch on that:

{{wd |properties|unit|Q18208369|P2044}} → metre
{{wd |properties|unit|Q4574072|P2044}} → metre
{{wd |properties|unit|Q25271|P2044}} →

But that still suffers from vulnerability to changes in labels on Wikidata.

The only other option I can think of is that I could add a feature into Module:WikidataIB to pass the retrieved quantity and its units through the {{convert}} template internally and rely on the default conversions? Then we'd only have one field for elevation. Would that be a usable solution? --RexxS (talk) 21:10, 28 October 2018 (UTC)[reply]

Thanks very much Frietjes and RexxS for this info. I will need some time to slowly digest it. I had a vague recollection that convert could do something clever but had forgotten the details. I see that input=P2044 causes convert to get the value and the unit (based on its Qid code, not label), then convert that. Taking the default output unit is easiest but may not always be satisfactory. Convert uses getEntity which I believe is a lot of overhead compared with getting a few properties. OTOH getEntity would be for the current page and so is probably cached. Wikidata is complex! Johnuniq (talk) 07:03, 29 October 2018 (UTC)[reply]

@Johnuniq: I've implemented a |conv=true/false for getValue in Module:WikidataIB. It relies on using the default conversion, so we get these results:

{{wdib |qid=Q18208369 |P2044 |ps=1 |uabbr=y |conv=y}} → 4.5 m (15 ft)
{{wdib |qid=Q4574072 |P2044 |ps=1 |uabbr=y |conv=y}} → 8,848 m (29,029 ft)
{{wdib |qid=Q25271 |P2044 |ps=1 |uabbr=y |conv=y}} →

For the area (P2046) of Birmingham (Q2256) we would get:

{{wdib |qid=Q2256 |P2046 |ps=1 |uabbr=y |conv=y}} → 267.76 to 267.78 km² (103.38 to 103.39 sq mi)

Using getEntity will always take more resources than getBestStatements, although as you say it's not an expensive call if it's the current page. A lot of the older modules need to be re-written to use getBestStatements or getAllStatements to reduce overhead and to allow en-wiki watchlists to track only those Wikidata changes that affect the properties used in the en-wiki article. If you check the "Parser profiling data" by previewing this section, you'll see Expensive parser function count 3/500, which are the three {{wd}} calls I used earlier. --RexxS (talk) 14:25, 29 October 2018 (UTC)[reply]

RexxS, thank you. how do I get the elevation as a plain number in meters? Frietjes (talk) 14:40, 29 October 2018 (UTC)[reply]

@Frietjes: If you break down the task into steps, you first recognise that the quantity stored in Wikidata can be in any units:

{{wdib |qid=Q18208369 |P2044 |ps=1 |uabbr=y}} → 4.5 m
{{wdib |qid=Q4574072 |P2044 |ps=1 |uabbr=y}} → 8,848 m
{{wdib |qid=Q25271 |P2044 |ps=1 |uabbr=y}} →

So you need to convert that into metres by separating amount and units, then passing them to {{cvt}} and finally extracting the plain number of metres. I've written a little routine to do that:

{{cvt2m | {{wdib |qid=Q18208369 |P2044 |ps=1 |uabbr=y}} }} → 4.5
{{cvt2m | {{wdib |qid=Q4574072 |P2044 |ps=1 |uabbr=y}} }} → 8,848
{{cvt2m | {{wdib |qid=Q25271 |P2044 |ps=1 |uabbr=y}} }} → 0

I haven't tested it thoroughly, but it might be adequate for what you want. --RexxS (talk) 17:10, 29 October 2018 (UTC)[reply]

RexxS, seems complicated. I would think that it could all be done by convert, if I use {{convert|input=P2044|{{convert|input=P2044|disp=unit|abbr=on}}|m|disp=number}} I get what I want, but it requires two calls to convert. Frietjes (talk) 18:01, 29 October 2018 (UTC)[reply]

@Frietjes:. Sure, if you don't mind making two calls to Wikidata to fetch the same thing twice, just using the number from one call and the units from the other. I thought you were perhaps trying to avoid that. --RexxS (talk) 18:15, 29 October 2018 (UTC)[reply]

RexxS, yes, but I see no reason why this can't be done with one call to convert. Frietjes (talk) 18:17, 29 October 2018 (UTC)[reply]

@Frietjes: You can program any module to do whatever you want, but I'm not sure what the use would be for the bare number of metres (just one unit out of so many). Most modules tend to be general-purpose and you sometimes have to bring two general-purpose modules together in a template to get a specific behaviour for a single case. --RexxS (talk) 18:31, 29 October 2018 (UTC)[reply]

RexxS, the need for the bare number in metres is the entire basis for this thread. we already have {{convert|29,029|ft|m|disp=number}} → 8,848 and {{convert|qid=Q4574072|input=P2044}} → 8,848 metres (29,029 ft). if we could combine these two features, into {{convert|qid=Q4574072|input=P2044|3=m|disp=number}} we would have something. ~~but, right now this only works if the wikidata entry is in ft, ignoring the |3=.~~ Frietjes (talk) 18:47, 29 October 2018 (UTC)[reply]

okay, it looks like this works, not sure what I was doing wrong before:

4.5 metres (15 ft) or in metres: 4.5 or in ft: 15

8,848 metres (29,029 ft) or in metres: 8,848 or in ft: 29,029

or in metres: or in ft:

Frietjes (talk) 18:52, 29 October 2018 (UTC)[reply]

Are plain numbers needed? Convert (Module:Convert/wikidata) fully analyses the Wikidata property and works on the Qid codes for each unit—any labels are ignored so metre/meter/whatever is not relevant. Convert also uses its own cache of unit codes (Module:Convert/wikidata/data) so it immediately knows that Q11573 is metre/meter. An interesting test of the cache is here—that shows that since 6 July 2017 there have been 31 changes to unit labels but no other problems. Those label changes are not relevant for convert. Surely a solution based on calling convert once can be found, even if convert has to be tweaked. Johnuniq (talk) 02:35, 30 October 2018 (UTC)[reply]

Johnuniq, see this change which appears to be working and is an improvement over the prior code. you are correct that we are still calling convert twice: once here and once through the infobox. the only ways that I know to fix that problem is to deprecated/remove the |elevation_m= and |elevation_ft= parameters and have |elevation= instead with the infobox calling something like {{infobox person/height}}. optionally, the {{infobox person/height}} and {{infobox person/weight}} could be absorbed into a more generic module ({{convert with units|4.5 m}}) or as part of convert ({{convert|4.5 m}}). Frietjes (talk) 13:49, 30 October 2018 (UTC)[reply]

Thanks, I'm still contemplating the theory while you have fixed the problem. I was thinking that |elevation= would be needed but don't know what would be involved in implementing that. Not that it matters but a plain |m would be fine instead of |3=m because convert will either return an empty string (if something went wrong) or will replace |input=P2044 with two parameters, a number and a unit code, before doing the conversion. You probably know that. Johnuniq (talk) 02:57, 31 October 2018 (UTC)[reply]

Johnuniq, if you want to improve the syntax, here is a working table

Using |3=
QID	Default	metres	ft
Q18208369	4.5 metres (15 ft)	4.5	15
Q4574072	8,848 metres (29,029 ft)	8,848	29,029
Q25271

if I remove the 3= it doesn't work, but changing the 3= to 2= does work. 3= makes sense to me because that's where the output units go. not an issue for me so long as something works. Frietjes (talk) 12:29, 31 October 2018 (UTC)[reply]

I've worked out what's going on. The problem is illustrated with:

{{convert|qid=Q4574072|input=P2044}} → 8,848 metres (29,029 ft)
{{convert|qid=Q4574072|input=P2044|ft|disp=number}} → 29,029
{{convert|qid=Q4574072|input=P2044|3=ft|disp=number}} → 29,029

1970 Mount Everest disaster (Q4574072) uses foot (Q3710) as the unit for elevation above sea level (P2044)

The second of the above converts is essentially {{convert|29029|ft|ft}} with |disp=number added. Because the unit used for a property cannot be predicted, convert provides what was considered a feature, namely it removes the output unit if it is the same as that used for the property. That means the convert is essentially {{convert|29029|ft}} which uses the default output (m) giving the broken result shown above. Convert does that before the following inserts.

The reason that |3=ft gives the desired result is due to the way Lua performs table.insert(t, 'ft'). If t = {3='ft'} which is {nil, nil, 'ft'}, the insert gives {'ft', nil, 'ft'}.

Then, executing table.insert(t, '29029') gives {'29029', 'ft', 'ft'}. That does what is wanted with |disp=number.

I don't think convert needs to be changed but it is a quirk to bear in mind. Johnuniq (talk) 06:46, 1 November 2018 (UTC)[reply]

"Language" property vandalism

Someone vandalized the "language" property in the PH Wikidata template and added "Swardspeak" on it. For those who are not familiar, this is not a language of the Philippines. I can't access the template so there's no way to remove it. Raku Hachijo (talk) 08:53, 19 December 2018 (UTC)[reply]

@Raku Hachijo: What page shows the problem? Apparently Swardspeak is real although the term may be misused somewhere, but where? Johnuniq (talk) 09:36, 19 December 2018 (UTC)[reply]

Hmm, searching shows "Swardspeak" in the infobox, for example, at Marikina. That is due to the fact that the template shows information from Wikidata. Clicking "Wikidata item" in the tools box on the left of that article leads to Marikina (Q17175) where the history shows that Exec8 added Swardspeak in October. That seems a bit dubious to me but a discussion somewhere needs to establish what "Native languages" means and whether mentioning Swardspeak is WP:DUE. Johnuniq (talk) 09:49, 19 December 2018 (UTC)[reply]

Dasmariñas, Taguig and Parañaque too. It's almost on any city article other than Malabon, Manila or Cebu City has the word "Swardspeak" on it. — Preceding unsigned comment added by Raku Hachijo (talk • contribs) 10:37, 19 December 2018 (UTC)[reply]

Those articles have Swardspeak for the same reason mentioned above: in October Exec8 added Swardspeak to the "language used" property at Wikidata. You can edit Wikidata: click "Wikidata item" in the tools box on the left of the article, find the "language used" property where Swardspeak appears, click edit then remove. It would be better if there were some discussion at a suitable wikiproject first. Even if no one responds, a proposal to remove Swardspeak from multiple articles (with a brief reason) would give others an opportunity to offer an opinion. Johnuniq (talk) 00:12, 20 December 2018 (UTC)[reply]

Help troubleshooting missing URL/extra access-date in Alaminos, Pangasinan

Have no idea how this template works or how to go about fixing the result in Alaminos, Pangasinan with the error "Missing or empty |url= (help); |access-date= requires |url= (help)". — Chris Capoccia 💬 13:31, 14 September 2019 (UTC)[reply]

The problem is how template {{NCC detail}} is used in this template. On 23 July 2017, Exec8 changed {{NCC detail}} to use the property described at URL (P973) instead of reference URL (P854). Unfortunately, this template was left still checking for reference URL (P854). So in Alaminos, Pangasinan, it tried to fetch a value that doesn't exist – the Wikidata entry for Alaminos (Q43162) has no described at URL (P973). That produces the error that {{NCC detail}} generates when the url doesn't exist on Wikidata:

{{NCC detail}} → ": Cities and Municipalities Competitiveness Index". Makati, Philippines: National Competitiveness Council (Philippines). {{cite web}}: |access-date= requires |url= (help); Missing or empty |url= (help)

I've updated this template to look for described at URL (P973), so it won't show a reference when the url is present in the related Wikidata entry. The infoboxes should be working as expected now. --RexxS (talk) 23:56, 14 September 2019 (UTC)[reply]

well it's still giving the same error. still no idea how a normal editor is supposed to understand what you're talking about above. — Chris Capoccia 💬 16:26, 12 October 2019 (UTC)[reply]

@Chris Capoccia: Well it's working now, because I just restored the fix I made on 14 September that was removed by Exec8 yesterday. I suppose you didn't check Alaminos, Pangasinan in the intervening month when it was working properly? The explanation above was written to explain the problem to an editor who could understand the issue. In other words, I was hoping Exec8 would notice the fix and not remove it as they did yesterday. Next time the error shows up, all you have to do is restore Template:PH wikidata to the last working version. --RexxS (talk) 02:00, 13 October 2019 (UTC)[reply]

Empty footnote

Please see this VPT discussion. It looks like the template should test for Wikidata item content before displaying <ref>...</ref> tags. – Jonesey95 (talk) 00:08, 16 September 2020 (UTC)[reply]

I've added a test and its removed the empty reference at Sariaya and Manila. It should work, but I can't find an example where Wikidata has a value to make sure. — Jts1882 | talk 08:18, 16 September 2020 (UTC)[reply]

Date formats

Is there a way to change the date format from DMY to MDY? —hueman1 (talk • contributions) 12:38, 28 October 2020 (UTC)[reply]

Date format is not defined in the Philippines. Some places (and wikipedia articles) are dmy and some are mdy. It is not up to you changed things to your ways. Not Samuel Pepys (talk) 08:18, 29 October 2020 (UTC)[reply]

DILG detail

I have corrected this template so that it now used the current values rather than 2013 ones. The template now doesn't use any parameter – it takes region / province / municipality/city direct from Philippine Standard Geographic Code (P988).

Incidentally, the use is wrong in most of the infoboxes - {{DILG detail}} should not itself have surrounded with <ref></ref>. Instead a reference can be added with {{refn|...}} in {{PH wikidata}} when ready. Not Samuel Pepys (talk) 16:31, 29 October 2020 (UTC)[reply]

Changing of titles and contents

There are several sections for "user" use.
Demographics-1 and Demographics-2. Demographic is to do with people and their geography. And is not about economics. So we can write about Poverty incidence. We can include HDI. We can add other tables such as 'mortality table', 'age at death' etc. And more tables for poverty – quite a useful topic in Phils. Also 17 October, United Nations International Day for the Eradication of Poverty. I think the individual topic should be more to be similar. Demographics-2 could be used to do with language. -1 and -2 can each hold 10 items.

There two 'free' topics lists – each have room for 7 items. Here we could take one column of economic topics, and maybe the other to do with religion.

What we don't want to do is overload the topics. Cf. https://en.wikipedia.org/w/index.php?title=Cebu_City&oldid=983508994, where we have a title called Crime index with the contains Sister Cities!

Whatever, we need to do it as a project, not just one person do it. Not Samuel Pepys (talk) 19:04, 29 October 2020 (UTC)[reply]

revenue_point_in_time parameter apparently generates error

In the "Infobox settlement" of Naga, Camarines Sur, the call to {{PH wikidata|revenue_point_in_time}} causes

"http://www.cmcindex.org.ph/pages/profile/?lgu=Naga%20(CS) : Cities and Municipalities Competitiveness Index". Makati, Philippines: National Competitiveness Council (Philippines). Retrieved 6 April 2017. External link in |title= (help)

to appear in the References section. Note the "External link in |title= (help)", which appears in red. Dhtwiki (talk) 21:10, 23 September 2019 (UTC)[reply]

First think I see is that described at URL (P973) is be used as a QUAL, not as a main property. So I changed to be QUAL of fiscal/tax revenue (P3087). I don't why it's connected to Revenue, as it has not much to do with each other. It should be read as a separate item.

Second problem is the url given is probably wrong. Instead try https://cmci.dti.gov.ph/pages/rankings/ – much more likely. The problem is that the index is actually several different indexes – one for provinces, one for HUCs, one for CC, one 1st and 2nd class municipalities, one for 3rd to 6th class municipalities.
"Provincial rankings are based on population and income weighted average of the Overall scores of cities and municipalities under a province."

In fact years 2013 to 2018 inclusive, there is also a list of all municipalities together, but not for 2019.

Using {{WikidataIB}} will be much easier to extract from Revenue (if that's where it should be attached).
Not Samuel Pepys (talk) 22:11, 29 October 2020 (UTC)[reply]

`{{WikidataCoord}}`

I have {{wikidata|coord}} corrected, but still testing. I have liaised with Trappist the monk who corrected {{WikidataCoord}}. But that doesn't help much with the coords etc. made out of {{Infobox settlement}}. No matter what coordinate parameters put into {{Infobox settlement}}, all in are ignored, and it just sends coordinate parameters of region:PH… and dim:city(pop)
region: is supposed to be allowed for adm1st and adm2nd only
dim: is best used with a circle – city(pop) is more likely wrong than right, so useless. See Central Visayas. @Frietjes: Get a look!

type: should have fourth order – adm4th – added, for barangay. Not Samuel Pepys (talk) 09:32, 9 November 2020 (UTC)[reply]

Not Samuel Pepys, if you want to discuss changes to {{WikidataCoord}} you should ask at Template talk:WikidataCoord. if there is an article using this template and this template is generating the wrong type, let me know, but Central Visayas is not using this template for generating the coordinates. Frietjes (talk) 15:20, 9 November 2020 (UTC)[reply]

@Frietjes: – {{WikidataCoord}} has been corrected ten days ago. I can see that using {{GeoHack}} gets the correct sequence parameters. But using {{PH wikidata|coords}} which passes into infobox, but the GeoHack parameters out of infobox do not have the right coordinate parameters. I left the workings in {{#invoke:WikidataCoord|function}} which Trappist the monk used, and before that {{WikidataCoord}}. OK, try another one – Tagbilaran, check what parameters are passed. https://geohack.toolforge.org/geohack.php?pagename=Tagbilaran&params=9.65_N_123.85_E_region:PH_type:city(105051) – region: is incomplete (because not allowed at third order); and type:city(106051) which is useless – dim: is best. Maybe OK (maybe!) when wikidata was young, but now it is mature, better choices should be used. Not Samuel Pepys (talk) 17:04, 9 November 2020 (UTC)[reply]

Central Visayas had wrong GeoHack –
https://geohack.toolforge.org/geohack.php?pagename=Central_Visayas&params=10_N_123.5_E_region:PH_type:city(7396898)
until I corrected it 28 Oct, to -
https://geohack.toolforge.org/geohack.php?pagename=Central_Visayas&params=10_0_N_123_30_E_region:PH-07_type:adm1st
– see how much better the map looks. Not Samuel Pepys (talk) 08:48, 10 November 2020 (UTC)[reply]

Something is not working properly

It seems like settlement_text and settlement_type are broken. —hueman1 (talk • contributions) 15:33, 20 March 2021 (UTC)[reply]

@Exec8, Sanglahi86, Frietjes, and Seav: Pinging. —hueman1 (talk • contributions) 15:37, 20 March 2021 (UTC)[reply]

I'm not sure if all cities/municipalities are affected by this but I've seen a couple showing "[[of the Philippines|]]". —hueman1 (talk • contributions) 15:40, 20 March 2021 (UTC)[reply]

hueman1, an example is needed (checking Passi, Iloilo looks fine). Frietjes (talk) 15:17, 22 March 2021 (UTC)[reply]

@Frietjes: It's fine now. For what I have observed, seav made some changes on Wikidata that didn't match up with this template's code—this consequently affected the output of the template for quite some time. —hueman1 (talk • contributions) 15:40, 22 March 2021 (UTC)[reply]

Text-decoration should be inside PH_wikidata, not each infobox

I see that poverty_incidence, [a] poverty_incidence_point_in_time [b] and poverty_incidence_footnotes [c] are written as a% (B) C.
However the text-decoration ["%" and parentheticals "( )"] should be supplied within PH_wikidata NOT by the infobox. There could be others.

We need add the text-decoration to the PH_wikidata - only once, but every infobox has to change to remove the text-decorations there. I'm sure there is an easy way of do it. I don't know what it is. Who can do it? Auntie Kathleen (talk) 02:21, 24 January 2023 (UTC)[reply]

Trouble with wikidata

This is not entirely with PH_wikidata but I don't know where to ask.

a within barangays, they haven't had the population for 2020. I have looked at a few (Cebu and Bohol) and none have 2020 (apart from a few I added). All current qualifiers P585 to be changed to be 'normal rank' and the new qualifier 2020 to be 'preferred rank'. I don't know about the rest but I guess the same. The data is easy to find, for instance: Census+of+Population+(2020).+"Region+VII+(Central+Visayas)".+Total+Population+by+Province%2C+City%2C+Municipality+and+Barangay

b in municipalities and cities, property P8843 poverty_incidence, with qualifier of P585 point_in_time should contain reference: P123 publisher, P577 publication_date, P854 reference_URL, P1476 title. The set of references is the same for each P8843, except for 2012 P854 has to corrected from a literal. The reference should remove any P813.

Auntie Kathleen (talk) 03:11, 24 January 2023 (UTC)[reply]

User:Migfab008

This user has decided to change ever page containing Philippine connection. S/he is changing any dmy to become mdy, and adding to
| Use Philippine English from January 2023 | All Wikipedia articles written in Philippine English | Use mdy dates from January 2023
Change everything back, and ANI the user - s/he had been warned about vandalism last week
Auntie Kathleen (talk) 06:13, 24 January 2023 (UTC)[reply]

Bad parameters or code

Naga, Cebu has a stripped </div> in the infobox that traces to {{PH wikidata|poverty_incidence}}, so I wondered what else is messed up.

I don't know the syntax of |infobox lighthouse= and its bulleted items, so I didn't test those.

The only parameter generating a lint error is |poverty_incidence=.

The only parameter generating unsupported input error is |number of divisions=.

Will someone please fix these parameters or code, and also the Usage section should better explain how to use |infobox lighthouse= and its bulleted items. —Anomalocaris (talk) 03:38, 28 March 2023 (UTC)[reply]

This Linter problem appears to have been fixed. The stripped tag still shows up in LintHint in Preview, but that looks like a limitation of LintHint. – Jonesey95 (talk) 14:02, 17 September 2023 (UTC)[reply]

Confusing map caption

I noted in the map caption reading Map of Romblon with Romblon highlighted in the Romblon, Romblon article. I understand that this comes about as a consequence the unfortunate re-use of Romblon as both the name of the province and the name of the island, but still ...

It seems to me that this can be corrected by editing in this template

| map_caption = {{safesubst:#if:{{safesubst:#property:P131}}|Map of {{safesubst:#invoke:string|replace|{{safesubst:#property:P131}}|%s+%([^%(]-%)$||plain=false}} with {{safesubst:#invoke:string|replace|{{safesubst:PAGENAME}}|, .*||plain=false}} highlighted}}

to read

| map_caption = {{safesubst:#if:{{safesubst:#property:P131}}|Map of {{safesubst:#invoke:string|replace|{{safesubst:#property:P131}}|%s+%([^%(]-%)$||plain=false}} province with {{safesubst:#invoke:string|replace|{{safesubst:PAGENAME}}|, .*||plain=false}} island highlighted}}

However, fearing side-effects, I'm reluctant to make a WP:BOLD edit to that effect, so I'll just mention that as a suggestion here. It would probably flout scoping intentions, but perhaps it would be a better solution for that article to use a specific locally selected image and a literal locally defined caption. Comments? Wtmitchell (talk) (earlier Boracay Bill) 14:14, 18 July 2023 (UTC)[reply]