Closed Grub4K closed 3 years ago
Alang looks great, but what is the use case for slang being a table? The slangs that appear earlier in the table will have preference, but preference is already handled by the main json array. I'm just worried about confusing things.
slang being a table just allows you to write shorter json config files as you dont have to write multiple main entries for same language. for example "slang": [ "deu?", "ger", "eng?" ]
is a shortcut for creating 3 entries in the main json array
I'm not fully convinced it's the best way to do it, but giving people more choice is not a bad thing.
I tried to adapt the existing structure. There are probably better ways to implement this. Also the documentation has yet to be updated. I will look into it once I get time
I made some modifications on the master branch to fix some things that this broke and to update the documentation. Should all be good now.
Check if alang is a string and if it is wrap into table, then iterate over it. For slang we do the same except we pass the used slang to
is_valid_sub
to keep precedence (["eng?", "no"]
will favoreng?
,["no", "eng?"]
no
) This way should not break compatibility.