Closed HedvigS closed 5 years ago
Thanks!
I'm updating my glottolog table make script so that it no longer renders this variable on its own but just takes it from the CLDF dataset. I'm however definitely renaming it from "Language_ID" to "Language_level_ID". If not too many other people have started using this parameter, I would definitely encourage you to use a different name in the CLDF dataset since "Language"_ID" is used in other capacities.
I'm still of course very happy it's a parameter at all :)
The confusion with the name of this column, "Language_ID" is causing trouble yet again in code collaboration in a Grambank project.
Do we have any idea if anyone but me and people around me uses this col? If it's only that small mob, can I please once again petition you for a variable name change?
I'm getting deja vu with having discussions again.
There's documentation of this column now: https://github.com/glottolog/glottolog-cldf/tree/master/cldf#columns-3
Also - from my point of view the Language_ID
columns in the dataset do mean the same thing: A foreign key into LanguageTable
. To figure out the semantics of the foreign-key relation, you have to consult the documentation - just as with all other foreign keys.
glottolog-cldf has been released a couple of times since 2019, so I think the window for backwards incompatible changes has passed.
Okay. Yes I know about the foreign key specification, but trust me it still causes trouble.
Okay, too late. I get it.
Loving the CLDF-structure of the Glottolog dataset, I've sat down and had a poke around now.
Just one thing. Unless I've misunderstood something, the term "Language_ID" is being used to mean two different things in languages.csv and values.csv. Is it possible to differentiate them or keep it as is and include a line in the readme explaining how it's set up? My preference would be for the column in language.csv to be named "Language_level_ID", but please do whatever is appropriate.