hash for the fragment identifier

Note that since T316257 was resolved, fragment identifiers are ignored as part of URL normalization.

Because fragment identifiers should be used to refer to specific parts on a webpage and not change the webpage that is returned by the web server (as opposed to query string parameters) I understand that it is OK that they are ignored.

Then, it would make no sense to have this hash option in the URL selection step.

This selection step may be useful in cases where we can't get the webpage because we have been blocked. As suggested in T305168, we could use such a URL selection step to guess a title.

we could use such a URL selection step to guess a title.

Another example where this could be useful: https://web2cit.toolforge.org/https://www.thepress.co.nz/a/nz-news/350060204/series-inexplicable-coincidences-murder-case-against-david-benbow

Then, it would make no sense to have this hash option in the URL selection step.

To be reconsidered: T430885

Noting that an alternative to the proposed URL selection step may be using Citoid selection with url config value. However, this would not be useful in cases where we have been blocked, which has been mentioned above as one of the benefits of having this URL selection step.

The configuration value may mimic the browsers' URL object. For example, href for the full URL, hash for the fragment identifier, etc.

• hash: alternatively, fragment. yes; maybe we could drop the leading #? Consider decoding.
• hostname: alternatively, domain. yes; e.g., www.example.com.
• href: yes; the whole URL.
• pathname: alternatively, path. yes; including leading /.
• protocol: alternatively, scheme. yes; e.g., https:, but won't be useful until T322601 is addressed. Consider dropping the trailing :.
• port: yes; e.g., 8080, but won't be useful until T315020 is addressed.
• host: no; it's just hostname + port.
• origin: no; it's just protocol + hostname + port.
• search: alternatively, query. yes; e.g., ?a=b&c=d&e=f.
  • Consider dropping leading ? or even returning an array of parameters: `[ "a=b", "c=d", "e=f" ].
  • Evaluate how the output chosen could be processed by a later transformation step (e.g, Match transformation) to get value or presence of a given parameter, considering parameter order can vary.
  • Can be decode considering we have = as delimiter between parameter name and value?
  • Consider some edge cases. For example ?a=b=c&d=f would be valid, with a parameter having b=c as value.
• username: no?
• ~~password: no?~

Web2Cit/Docs/Templates documentation updated on meta-wiki.

This selection step may be useful in cases where we can't get the webpage because we have been blocked. As suggested in T305168, we could use such a URL selection step to guess a title.

Shown example use case for www.leparisien.fr, for title and date fields, with a combination of URL selection step (config=path) and split, range and join transformation steps: https://meta.wikimedia.org/w/index.php?title=User:Diegodlh/Web2Cit/data/fr/leparisien/www/templates.json&oldid=30791428.

Another example where this could be useful: https://web2cit.toolforge.org/https://www.thepress.co.nz/a/nz-news/350060204/series-inexplicable-coincidences-murder-case-against-david-benbow

Used URL selection step to guess an approximate title: https://meta.wikimedia.org/w/index.php?title=User:Diegodlh/Web2Cit/data/nz/co/thepress/www/templates.json&oldid=30791432

Implemented in Web2Cit-Core with e8b91273.

Pending Web2Cit-Server update and deploy.

Also pending moving example templates configurations above to main namespace, and removing "coming soon" message in Web2Cit/Docs/Templates.

Once deployed, use for www.telegraph.co.uk as well.