Module talk:etymology languages

Should we change these to "variants"?

@Benwing2 Sorry for the delay on this, as I know I said I'd do this the other day. Essentially, I'd like to take the idea behind etymology-only languages to its logical conclusion, which is to treat them as variants of their parent languages. This has two main advantages:

• From a linguistic/lexicographical perspective, it provides a framework which we can use to ensure that labels and categorisation are standardised, as at the moment we essentially have three different systems in place, for etymologies, accents and definition labels. Plus, as we've already discussed, it would provide a way to vary things like transliteration. There are also difficult cases like Chinese L2s, where languages such as Mandarin occupy a strange middle-ground. While this wouldn't solve that issue, I suspect the process of implementing this might give us some good ideas on how best to handle edge cases.
• From a technical perspective, I think we should make variant objects a subclass of language objects, where object inheritance can do the heavy lifting. The major advantage of this is that modules could treat them both in exactly the same way, which would mean variants could be swapped in and out without issue in all situations (unless we specifically prevent it). This would make make modules simpler, and should mean we can get rid of bodges like ancestral_to_parent etc, too. Theknightwho (talk) 20:19, 19 March 2023 (UTC)
  • @Theknightwho: Thanks for the writeup. Can you give me a little more information on e.g. how the ancestral_to_parent stuff would go away? Are you suggesting e.g. that there's a variant for the "main" language as well as etymology variants, and that we allow the inheritance hierarchy to be specified for these variants? That's the only way I can see how ancestral_to_parent would go away; e.g. 'Italian' per se would be a variant of the 'Italian' language, and so would 'Old Italian', and there would be some indication that the former needs to be a child of the latter. I think this can work although I definitely think for something like this we should write up a more detailed doc outlining how to implement it before diving into the implementation (this is how major software projects are typically implemented at big companies and helps ensure that we don't end up introducing tech debt or going down the wrong path). It doesn't have to specify every last detail; that's akin to the old waterfall model. But it can avoid pitfalls like the current situation we have with multi-value-returning functions in Module:languages. Benwing2 (talk) 20:35, 19 March 2023 (UTC)

    @Benwing2 Logically, I think you're right about needing a variant for the main language, but I think we can fudge it by simply treating the non-variant language object as that variant. While the variants would be linked to the main language object via inheritance, the ancestry tree doesn't have to be aware of anything as low-level as that.

    What I think I'll do is have a go at putting something together in my userspace with comments, as I tend to find it easier to work things out as I go. I'm currently right in the middle of having a go at the parser again, but it's a slow-burn project so I'll get round to this soon. Theknightwho (talk) 21:00, 19 March 2023 (UTC)

    @Theknightwho: OK, still confused how this will work but I'll wait for your userspace code. Benwing2 (talk) 21:08, 19 March 2023 (UTC)