| Psychoslave updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
Although Wikidata already provide a way to carry some lexicological data through the Lexeme extension, we lake the possibility to import definitional material into a relational database queryable from wiktionaries.
As an example of the limit that it brings, I proposed to create glossaries in Wikitionary. One way to do it would be to use external bots that browse lexical categories, grab matching definitions (if tagged in the article) and generate distinct pages.The asked Wikibase instance would aim at:
As Lua modules doesn't allow to fetch a list of element in a category, it's not possible to do that through this feature, and it would probably be too resource consuming anyway. What would be possible is parsing all articles and put their definition into data modules. That would at least make a scenario where this data would be easily providable for in-wiki consumption in various cases, potentially avoiding data duplication, as well as for external queries as the module could generate various output format. Thus said- allow to import Wiktionaries definitions
- there is no garantee that the current community would like to use this data modules, there might propose to delete the transformed materialallow to link definition to samples of use (including media for audio records, just ignore it and recommand to not use it within the main spacevideo of signed languages and so on, just as well as embrace and migrate massively to such an approachmedia should be associated to a textual transcription)
- a dedicated UX should enable to edit data modules without editing the LSON, maybe OOUI might help here, this would probably be a huge plus in term of new contributor attraction as currently editing Wiktionaries is difficult for newcomers with many implicit structures- allow to translate definitions (and transcriptions where relevant)
- it doesn't allow data sharing across linguistic version
The first point won't change whether the data are stored within a data module or in an external Wikibase instace. The latter point however can't currently be solved with data modules, as crosswiki call sare currently impossible. Of course when it comes to share relational data across linguistic versions, Wikidata comes to our mind.allow to add statements on each definition (for example domain/context where the definition applies, However as this is about sharing definitions which are creative materialsregister, we won't be able existing CC-by-sa materials from Wikitionaries into Wikidata anytime soon.
So this hopefully expose the reasons of this demand and makes obvious how it support the aims of our movement.
So the two important point for the asked Wikibase instance are:and so on)
- it should allow to import Wiktionaries definitions- allow Wikitionary (and other sister projects) to query directly the instance
- it should allow Wikitionary (and other sister projects) to query directly the instance
As an example of the limit that it brings, I proposed to create glossaries in Wikitionary. One way to do it would be to use external bots that browse lexical categories, grab matching definitions (if tagged in the article) and generate distinct pages.The asked Wikibase instance would aim at:
As Lua modules doesn't allow to fetch a list of element in a category, it's not possible to do that through this feature, and it would probably be too resource consuming anyway. What would be possible is parsing all articles and put their definition into data modules. That would at least make a scenario where this data would be easily providable for in-wiki consumption in various cases, potentially avoiding data duplication, as well as for external queries as the module could generate various output format. Thus said- allow to import Wiktionaries definitions
- there is no garantee that the current community would like to use this data modules, there might propose to delete the transformed materialallow to link definition to samples of use (including media for audio records, just ignore it and recommand to not use it within the main spacevideo of signed languages and so on, just as well as embrace and migrate massively to such an approachmedia should be associated to a textual transcription)
- a dedicated UX should enable to edit data modules without editing the LSON, maybe OOUI might help here, this would probably be a huge plus in term of new contributor attraction as currently editing Wiktionaries is difficult for newcomers with many implicit structures- allow to translate definitions (and transcriptions where relevant)
- it doesn't allow data sharing across linguistic version
The first point won't change whether the data are stored within a data module or in an external Wikibase instace. The latter point however can't currently be solved with data modules, as crosswiki call sare currently impossible. Of course when it comes to share relational data across linguistic versions, Wikidata comes to our mind.allow to add statements on each definition (for example domain/context where the definition applies, However as this is about sharing definitions which are creative materialsregister, we won't be able existing CC-by-sa materials from Wikitionaries into Wikidata anytime soon.
So this hopefully expose the reasons of this demand and makes obvious how it support the aims of our movement.
So the two important point for the asked Wikibase instance are:and so on)
- it should allow to import Wiktionaries definitions- allow Wikitionary (and other sister projects) to query directly the instance
- it should allow Wikitionary (and other sister projects) to query directly the instance
TASK DETAIL
EMAIL PREFERENCES
To: Psychoslave
Cc: Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, jberkel, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Krenair
Cc: Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, jberkel, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Krenair
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
