Closed Linguista closed 7 years ago
@PaulHeggarty This issue is related to the fact that the database tables are study-based. Which has advantages but also disadvantages. The missing Mapudungun transcriptions inside of the Andean study are only stored within the Mapudungun study, not within the Andean study. This leads also to another problem: please compare e.g.
http://www.soundcomparisons.com/#/en/Mapudungun/language/Lago%20Rosario
and
http://www.soundcomparisons.com/#/en/Andean/language/Lago%20Rosario
What should we do? 1) We can merge all study-based tables into big tables. This would have the advantage that one can create studies with let's say Slavic and Malakula languages and all language data will be stored once. But this would be a deep code intrusion. 2) I can try to query all tables for languages which are given for the desired study. This should be easy but won't solve the problem that language data will be stored more than once in the database (redundancy).
If the database is the authoritative storage of the data, I think it should be fully normalised, i.e. not store any data redundantly. This would become even more important if the data in the database becomes editable through-the-web.
But I also agree with @Bibiko that we shouldn't invest any more in PHP code bases - just because this will prevent any synergies between projects when it comes to coding, but also deployment and server config.
I also can't help but think this is exactly an instance of the problems that made me turn away from the "database-wrapped-in-an-app" as solution to data curation needs.
When viewing Mapudungun varieties by means of the
Mapudungun
button in the top left corner, the phonetic transcriptions are shown properly, as can be seen here:However, if you view the same Mapudungun varieties using the
Andean
option, no transcriptions whatsoever are shown.Needless to say, this isn't the expected behavior.