Sort country agency labels case-insensitively

[Sinkleberg]

Fixes #571.

Sort labels without capitalization or language tags changing their position in the list. This updates all 49 country and subcountry queries while keeping their existing type grouping and sort direction. It also replaces nine unused topic sort keys, adds the missing name sort to three queries, and updates both examples in the country guide.

The guide now asks contributors to check their actual country query in Wikidata Query Service. The standalone RDFLib test and its setup instructions have been removed following review; no new test dependency is needed.

Validation: earlier offline checks passed for the revised query clauses and failed on the original ones. A Greenland build generated six pages and its live expected-count check passed 5/5. A local agency-table render using captured New Zealand data confirms the visible ordering change; platform cells were omitted from that example. The queries have not changed since those checks.

No full-site build was run. This is case-insensitive sorting, not locale-specific collation.

[Ainali]

Thanks for your work! A brief look tells me this is in the right direction.
Even if you haven't done a full build, there are some things that can help test parts anyway.

1. If you start a full build, you can see if it fails even before it comes to the queries or if it gets to that part (even if it times out later on)
2. You can temporarily remove countries from the views.yaml file and the countries.rq file to see if it can build with just one country.
3. run scripts/tests/spell-checker.py (which fails in CI now).
4. run scripts/check-expected-results-count.py for all (or even just one country) to see if the queries work.

[Sinkleberg]

Thanks! The Greenland count check passed (5 expected, 5 found), and a one-country Snowman build generated all six pages. I added RDFLib to the spelling dictionary and excluded Python source alongside the other source files. The new CI runs are waiting for maintainer approval.

[Abbe98]

Do we have some examples of the impact on the actual rendering?

[Sinkleberg]

Yes — here's New Zealand's Non-Public Service departments group from a local render:

Before (captured result)	With this change
New Zealand Defence Force	New Zealand Defence Force
Office of the Clerk of the House of Representatives	New Zealand Parliamentary Services
Parliamentary Counsel Office	New Zealand Police
New Zealand Police	Office of the Clerk of the House of Representatives
New Zealand Parliamentary Services	Parliamentary Counsel Office

The same five agencies remain. The old query sorted only by type, so it didn't guarantee name order within the group. This adds that ordering; the layout stays the same.

I rendered the existing agency-table template using captured Wikidata rows, with platform cells omitted. This wasn't a full-site build, and the sorting still isn't locale-aware.

[Ainali]

The New Zealand example is a great case for this change, thanks for finding it!

[Ainali]

I looked a bit closer now, and turning the labels into strings is redundant since they are already strings. So instead of:
LCASE(STR(?typeLabel)) LCASE(STR(?orgLabel)) (and all the variants we have with one or the other)
I would suggest simplifying it to
LCASE(?typeLabel) LCASE(?orgLabel)

[Sinkleberg]

I checked this on WDQS and found one catch: LCASE keeps the language tag, while STR removes it. That matters when labels come from different fallback languages.

For example:

SELECT ?label WHERE {
  VALUES ?label { "charlie" "Bravo"@de "delta"@en "alpha"@en }
} ORDER BY LCASE(?label)

This returns charlie, Bravo, alpha, delta. With LCASE(STR(?label)), it returns alpha, Bravo, charlie, delta. The existing offline test gives the same result.

I'd keep STR here so fallback labels still sort by name. The SPARQL examples show that LCASE retains the tag.

[Ainali]

Ah, that's a good point! While removing the STR would give a way to spot missing labels in a language, arguably we should do that earlier and not in the published data.

[Ainali]

I don't understand this paragraph. What is the point of testing with synthetic data? Wouldn't it be better to test our actual queries?

I am also weary of adding a test with an external dependency. Can this not be done without calling an external library? (If not, we should also add explicit instructions on how to install something in a Python virtual environment, or we are really narrowing down who will be able to add a country.)

[Sinkleberg]

The synthetic cases checked mixed-case and fallback-language labels, but that setup should not be part of adding a country. I removed the RDFLib test and its setup instructions. The guide now asks contributors to run their actual country query in WDQS and check the name and group order, with nothing to install.

[Ainali]

Suggested change

	Run your country query in the [Wikidata Query Service](https://query.wikidata.org/) and check that agency names appear in alphabetical order within each type group, ignoring capitalization. Check that the type groups still follow the intended order for the country. This uses the actual query results and requires no local installation.
	Run your country query in the [Wikidata Query Service](https://query.wikidata.org/) and check that agency names appear in alphabetical order within each type group, ignoring capitalization. Check that the type groups still follow the intended order for the country.

I don't think that part is necessary any longer.

[Sinkleberg]

Removed that sentence, thanks.

[Ainali]

Great work, thanks!