I’m wandering why there’s a name field in language. Is it to comply with systems nota being able to provide the ISO code?
To me the code is enough and more precise. Moreover the name has to be in a language, for exemple for the French, the ISO code is fr but the name may be français or French depending on the language.
So sorry for the delayed response.
@mrshll who is best placed to answer is now back from paternity leave.
He is, of course, busy catching up but will be in touch with a response when he can.
Thanks,
Dan
Sorry again for the late response; as Dan noted I’ve been away on parental leave for a few months.
The reason that there is a name field in language is simply to balance the needs of humans with those of digital systems. HSDS data can be flattened into spreadsheets and it’s much nicer for a lot of humans to be able to see e.g “English” or “Swahili” in a column if they are unfamiliar with the ISO 639 standard. I will concede that langauge codes are widespread enough that most people know the most common ones used internationally, however for a standard such as HSDS we will have people trying to support people accessing services who speak a minority language and may not be familiar with the codes for that. I myself work a lot with Slovak speakers through a charity I work with, but I would need to look up the code for this. The same is true of the JSON format when I’m doing some analysis; it’s balancing technical purity with pragmatism and quality-of-life for the human analyst
I agree that a lot of systems will be able to do some matching for this automatically and generate a display name for the language. In some cases, though, we may have a language which isn’t yet covered by the ISO 639 codelists. Admittedly this is probably very rare, but in these cases it’s good to provide the name field so that they’re not excluded simply because the language doesn’t yet have a code.
Systems preferring to localise the names of languages for display can of course ignore the contents of the name field, to address the français / french issue you note. Although I think that there may be scope to add a local_name field to create a field which would explicitly expect content such as français, español, etc.
We use this pattern elsewhere in the standard as well. For example when we identify organisations, there exists fields for both the organisation’s name, alternate name, and an array of identifiers. For taxonomies and taxonomy codes there exists taxonomy_term.code to provide the unambiguous code, as well as taxonomy_term.name to provide an accessible human-readable version.
I hope that helps somewhat!
Tahnk you very much @mrshll for the answer, it’s much clearer. I didn’t had in mind that the data may be used as-is by non-developers.