BUG: Every `narrative/@xml:lang` says it *must* be on the Language codelist, when in fact it *should* be
andylolz opened this issue · 10 comments
So for example, here:
http://reference.iatistandard.org/203/activity-standard/iati-activities/iati-activity/title/narrative/#attributes
This value must be on the Language codelist.
There are around 60 such occurrences.
Sensible PR (took me a while before deciding to write this because I had no idea what, in IATI-terms, identifies a codelist as "incomplete" and why such state persists or how it changes over time). Will still do it for each branch at the moment.
Question for also @bill-anderson and @IATI/devs in general: is there any interest around a generic approach to such codelists to keep them up to date automatically / check wether they still are incomplete or not? As far as I gather, it's a manual approach?
Will still do it for each branch at the moment.
Kk – PRs sent for each branch.
All done and merged, thanks @andylolz 👍 ⚡️
Great, thanks!
This was mostly just to illustrate that bugs with the build code need to be fixed in 5 places. But we’re on the same page on that!
I had no idea what, in IATI-terms, identifies a codelist as "incomplete" and why such state persists or how it changes over time).
The previous developers had the same confusion, too, which probably suggests this needs to be better documented!
Country is a good example. The codelist replicates ISO 3166-2. But suppose a publisher has activities in Somewhereland (internal code XY), which isn’t recognised by ISO. If the codelist were “complete”, they’d have no way to refer to Somewhereland without their data being invalid. By marking the codelist as “incomplete”, IATI is saying “you may refer to codes that aren’t on this codelist”. So the publisher can refer to XY (Somewhereland) in the recipient-country/@code attribute, and even though ISO doesn’t recognise it, it’s still valid.
Looks good!
More deployments coming up the next days!
More deployments coming up the next days!
Ah, good point yes – this is currently only fixed for v2.03.
Okay, looks like this fix has now been deployed (and is fixed) for all versions 👍