Hidden in some T223792 replies was a short discussion about creating a new MediaInfo-specific Lua library (rather than using Wikibase default)
Judging by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/544204 and related activity, Lexeme is already doing so.
I'm not sure we need anything different or in addition to what Wikibase already provides at this point, so... let's start with the just the default wikibase methods, and figure out if and what else we might need later on?
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| mediawiki/extensions/WikibaseMediaInfo | master | +249 -1 | MediaInfo specific Lua modules |
Change 553128 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] MediaInfo specific Lua modules
Change 553128 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] MediaInfo specific Lua modules
I do not like idea of different libraries. Some of the information to be stored, like dates or copyright info, might be exactly the same format I would like to have one code for parsing it and not have to create separate lua modules because we need different libraries for accessing the came data from 2 different repositories. We already had painful code break when documented function was removed from MediaInfo-specific library and somehow broke parsing of wikidata entities. Lets keep those interfaces as similar as possible instead of forking them.
We already had painful code break when ... somehow broke parsing of wikidata entities
The breaking of getSitelink for Wikidata entities was a bug - the new library should not have affected those!
However, I tend to agree (T223792#5593785) that having to maintain multiple libraries for data that is mostly the same is annoying.
But it does seem like Wikibase & Lexeme are already moving in this direction, and I can also understand the reasons behind having different libraries, and even though things are mostly compatible now, that might not always be the case for all types of data.
We'd probably need another ticket & a lot more people/opinions (Lexeme etc.) to reconsider the approach of separate libraries per type.
(Though if really needed, I could be convinced to restore getSitelink for MediaInfo entities (even though they don't make sense in that context) for compatibility)
Matthias will soon release another patch to follow-up on the items in his last comment.
The getSitelink break was handled in T240563. The fix has been deployed, and my initial tests seem to indicate it works.
This also completes this ticket.