aude added a comment.
I think we need generic interfaces, such as FieldDefinitions and Field, and then maybe it's okay to have more specific implementations for specific search engines (e.g. ElasticSearch) for multilingual, ElasticSearch supports nested fields (as done with coordinates) but those can be problematic, especially with large nestings. sub 'fields' tends to be for indexing the same content with multiple analyzers (e.g. asciifolding, etc. and also with not analyzed or different analyzer). For Wikibase, I am experimenting with unnested fields for multilingual content, though then we have hundreds of unnested fields and not sure there is some point where it's too many? ElasticSearch also supports dynamic templates (though disabled for Cirrus). I think multilingual content might be a good use case for dynamic templates, so have 'label_*' and then a generic mapping for labels that applies to fields that match that pattern. If we want to use some of the language analyzers, then we could specifically define mapping for some of the languages and then use dynamic template for the rest. agree about dropping getWeight TASK DETAIL https://phabricator.wikimedia.org/T89733 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel, aude Cc: DannyH, hoo, Deskana, RobLa-WMF, Tgr, Yurik, dcausse, JanZerebecki, Smalyshev, matthiasmullie, aude, Ricordisamoa, Krenair, MZMcBride, bd808, brion, Manybubbles, Aklapper, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, GWicke, jayvdb, fbstj, Jackmcbarn, Mbch331, Jay8g, Ltrlg, Legoktm _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
