codeforiati / codelists Goto Github PK

Vuepress is cool but it already seems like we’re running into limitations. Might be good to give nuxtjs a try.

Some codelist descriptions contain RST (e.g. this one: https://codelists.codeforiati.org/OrganisationRegistrationAgency/).

They look weird presented as text, so it would be good to render them accordingly.

API structure on the root URL is:
languages/[language]/formats/[format]/…

But URL structure is:
/api/[format]/[language/[codelist_name].[format]

E.g. 230xx:

Once fixed, this should be sent as a PR upstream.

Need to set that up again!

Once we have the scrapers outputting to a repo, we can have a job/tool that calls csvdiff, xmldiff etc to monitor when the scraped and the IATI version differ - and alert us.

Bonus points if this was output to a file that we could suck into a one page traffic light dashboard.

Even more bonus points if it was automatically tweeted ala IATI canary but for codelists.

/via @matmaxgeds.

Waiting for a resolution on #31 but would mean that could get all codelists needed to work with IATI data from one single API :)

E.g. https://github.com/codeforIATI/IATI-Codelists-NonEmbedded/commits/master/xml/Sector.xml

Currently it says "Url".

Suggested by @markbrough.

Endeavour to make codelists available at least in EN and FR, preferably with some way of gradually expanding to cover other languages over time.

/via @markbrough.

Personally I think this is the main blocker to going live. I.e. once this is done, I’d be happy for this project to be listed on https://codeforiati.org and to share it more widely.

WDYT, @markbrough?

Space is missing between the codelist name and arrow here:

I have no idea where to fix this! But maybe this whole bottom nav should be removed, since it doesn’t really work here.

In order to add embedded codelists it would be useful/essential to have some form of versioning. Vuepress doesn't seem to have this as of Nov 2019 but there is an open issue on it with active discussion which links here and here as two options. I also wonder if we couldn't 'cheat' by using subfolders in /docs, and then using hierarchical/collapsible sub menus.....would mean much duplication, but only visible in the UI if you expanded multiple IATI version menus at the same time so probably acceptable?

Also, my instinct would be to version everything, even if we just give some of them the version 'current' for now, as I think it would help a lot of people if some of the currently non-versioned codelists were versioned by date e.g. you could pick a version of a non-embedded codelist that matched the published date of the IATI data you were using it with as I suspect this might increasingly be a problem with using older IATI data.

On codelist pages, I’d like a typeahead search, so that I can quickly find the name of a given code and vice versa.

I suspect there are various withdrawn DAC sector codes that are not included on IATI replicated codelists. It would be good to try and track these down and add them.

The header and values.

For other services (e.g. https://dashboard.codeforiati.org) it would be useful to also provide v1.0x codelists.

Include other helpful information e.g.

• whether a code has been withdrawn
• whether a code is recommended to be used (e.g. along lines of budget identifier guidance)
• mapping files to equivalent / recommended new codes when a code is withdrawn

/via @markbrough.

The search bar is v. cool, but I didn't realise when initially trying that it only searches the titles (although the autocomplete is cool and really helped me to realise this, I started by searching for a word where there was no autocomplete so I thought search was just broken).

My prefered option would be to also have the search include the codelist entries.....because often I know the entry I want, and I am searching for the codelist that it is on (otherwise I would just use the menu on the LHS if I know the codelist name already).

Quick fix....rename to 'codelist name search' from 'search'

It would be good to be able to link to an individual code, rather than just a codelist.

This could mean generating a page per code, or it could be done in javascript, or using page anchors.

Add the ability to subscribe to notifications when codelists have changed - I guess a summary when there are substantial changes?

For missing codelist names and descriptions, consider falling back to English.

E.g. https://codelists.codeforiati.org/GLIDENumber/

Include (access to?) other useful codelists, e.g. organisation identifiers; exchange rates.

/via @markbrough.

Make it possible to see on the website when a particular codelist was last updated.

Also: show when the site as a whole was last generated?

These are caused by the self-closing narratives elements e.g.

Although it might be reasonable to call this a bug with the XML, I think it would be sensible to fix the build scripts to deal with this (because I suspect fixing this in XML would cause our XML to diverge quite a long way from upstream).

Looks like this is the way to do it in Vuepress:
https://gist.github.com/MartinMuzatko/cc86b3f168630c05978d65c36169b129

I think we need something like this:

body {
  overflow-wrap: break-word;
}

This bit here:

For example, the AidType codelist description links to:
https://codelists.codeforiati.org/AidType/AidType-category

Some translations are in place, but it would be good to translate all the app-specific stuff (I guess we probably shouldn’t do codelist translations?)

I don’t like this:

It would be better to use the codelist metadata. Relevant codelists have category/narrative equal to "Replicated".

Should add a link to this for all language versions:
https://codelists.codeforiati.org/api/

I guess it’s like this for FR.

Might be good to default to filename, but use codelist name when it’s available.