Community Wishlist Survey 2020/Wiktionary
Multiple collations per site
- Problem: It is extremely common, on Wiktionary projects, to display entries of multiple languages on the same page. But, only one collation can be used on a particular Wikimedia project. That means: if a website uses a language-compliant collation, e.g. uca-default which is a English- and Portuguese-friendly collation, all categories concerning e.g. Swedish words, will sort words starting with Å under A, because Å is considered in English to be the same letter than A with a diacritic, while it is a whole new letter in Swedish (where it is sorted at the near end of the alphabet). Categories' headers are therefore incorrect for many languages with the current solution used on Wiktionary projects.
Currently a way to circumvent the problem is to use the default Mediawiki collation (namely uppercase), but this implies that sort keys are added in all English/French/etc. entries with a diacritic in the title, as Å, É, etc., as all diacritic letters are considered as first-entry headers in categories, and this implies a huge amount of sort keys in pages to bypass this behavior (and thus sort Å under A for e.g. English), and makes Wiktionary projects less readable and editable for newcomers. - Who would benefit: users of Wiktionary categories, and new editors to all Wiktionary projects
- Proposed solution: allow multiple collations per site, and therefore collation to be specified per category: uca-sv should be used for Swedish-related categories, uca-es for Spanish cats, uca-default for English (and similar), etc.
- More comments: Liangent and Bawolff have been working on this in the past, but feasability seems also to depend on sysadmins (for increased system load).
- Phabricator tickets: phab:T30397
- Proposer: Automatik (talk) 21:58, 23 October 2019 (UTC)
Discussion
- This proposal is a rerun of the 2019 proposal, always topical. — Automatik (talk) 21:58, 23 October 2019 (UTC)
- It's not up to me to decide (so this is not official in any way shape or form) but, in my opinion, I dont think there are scalability concerns with allowing collations to be set on a per category basis, provided any individual category only has one collation (e.g. there is a magic word to say that this category is french or german or whatever. You can only specify one, you dont for example have a drop down where you can view a category with different collations on the fly (like is wanted in zh)). Bawolff (talk) 04:24, 24 October 2019 (UTC)
- This should be merged with Community Wishlist Survey 2020/Wiktionary/Context-dependent sort key. Urhixidur (talk) 14:13, 25 October 2019 (UTC)
- This feature is sorely needed. Currently in the English Wiktionary we use a
sort_key
value for each language in our language data modules that describes how to generate sortkeys from page titles, and is used by themakeSortKey
method of our Language objects. The sortkeys are generated inside many different templates, and are used in category links, and to sort lists of links to entries (for instance in Template:col3). The generated sortkeys are not always able to make categories sort correctly, as described in the proposal.An extension of this proposal would be allowing definition of custom collations. Some languages probably do not have a collation system (not sure of the correct terminology) available, such as Egyptian (which in Wiktionary mostly uses a transliteration system rather than hieroglyphs). The desired sort order for the Egyptian transliterations (
ꜣ j y ꜥ w b p f m n r h ḥ ḫ ẖ z s š q k g t ṯ d ḏ
) is so different from the order of code point values (b d f g h j k m n p q r s t w y z š ḏ ḥ ḫ ṯ ẖ ꜣ ꜥ
), which is presumably used in Category:Egyptian lemmas, that a custom sortkey cannot work. We can sort lists of links by generating a sortkey for each link with a module (Module:egy-utilities), but the Egyptian module cannot be used in categories because the sortkeys would put nonsensical code points in the category headers. (The sortkey-generating function works by replacing the characters in the transliteration with arbitrary code points that have the correct sort order.) So getting Egyptian categories to sort correctly requires a custom collation system.Another idea would be to make collation available in a Lua library for Scribunto. At minimum what would be required is a function to compare two strings using a collation and yield values indicating "greater than", "less than", or "equal" (like
strcmp
in C), which could be adapted for use bytable.sort
(which requires a function returning a truthy value that indicates whether argument 1 is less than argument 2). Then we could sort lists of links using the same collations used in categories whenever possible, rather than using module-generated sortkeys. This might not depend on the implementation of the "multiple collations" proposal, but if custom collations were implemented, ideally they would be available in the Lua library.I haven't submitted the first idea as a separate proposal because it depends on the "multiple collations" proposal, but perhaps I should submit the second one. — Erutuon (talk) 20:53, 7 November 2019 (UTC)
Voting
- Support JAn Dudík (talk) 07:20, 21 November 2019 (UTC)
- Support KevinUp (talk) 08:54, 21 November 2019 (UTC)
- Support Lmaltier (talk) 20:56, 21 November 2019 (UTC)
- Support Pamputt (talk) 21:34, 21 November 2019 (UTC)
- Support Yes, this would be so useful for a lot of reasons. Amir E. Aharoni (talk) 08:21, 22 November 2019 (UTC)
- Support Libcub (talk) 08:58, 22 November 2019 (UTC)
- Support Timmylegend (talk) 11:28, 22 November 2019 (UTC)
- Support Noé (talk) 23:16, 23 November 2019 (UTC)
- Support JogiAsad (talk) 13:10, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:44, 25 November 2019 (UTC)
- Support A garbage person (talk) 16:10, 25 November 2019 (UTC)
- Support Romuald 2 (talk) 16:21, 25 November 2019 (UTC)
- Support 游魂 17:06, 25 November 2019 (UTC)
- Support This is fantastic. —Justin (koavf)❤T☮C☺M☯ 20:59, 25 November 2019 (UTC)
- Support Vorziblix (talk) 05:13, 26 November 2019 (UTC)
- Support Erutuon (talk) 21:18, 26 November 2019 (UTC)
- Support Unsui (talk) 12:08, 27 November 2019 (UTC)
- Support Curious (talk) 22:32, 29 November 2019 (UTC)
- Support Allahverdi Verdizade (talk) 19:17, 1 December 2019 (UTC)
- Support Metaknowledge (talk) 19:34, 1 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:45, 2 December 2019 (UTC)
What's in the newspaper today?
- Problem: Wiktionarians can't detect every new used word in real time to include them as soon as they appear, although they are examples of use accessible online.
- Who would benefit: Contributors and readers
- Proposed solution: Development of a tool that harvests online newspapers to record words that are missing in Wiktionaries database.
- More comments: This tool have to be adapted for each language and/or resource. Darkdadaah created a similar tool and had made it run from 2010 to 2013 for French.
- Phabricator tickets:
- Proposer: DaraDaraDara (talk) 14:54, 8 November 2019 (UTC)
Discussion
- Harvesting newspapers is a great way to detect new words, and it helps to have selected sentences to add as examples, after some manual selection as some sentence are correct but too long or too much in need of the context. Also, a thematic labelling may help Wikinewsies and Wikipedians to find more sources. Noé (talk) 11:27, 15 November 2019 (UTC)
- What about licenses of those newspapers? -Theklan (talk) 10:30, 22 November 2019 (UTC)
- @Theklan: it does not matter. The same rule applies for the book. Here the idea is just to crawl all the newspaper everyday and to extract only the sentence with the new word. In that case, this is short citation and it is allowed to use it. See this page with French words for example. Pamputt (talk) 13:40, 23 November 2019 (UTC)
- We already have "Wiktionary:Frequency lists" which is based on tv subs and have thousands of missing words in all languages including English. Newspapers will give you a lot of typos and game plays. Not needed as long as we have big lists of missing words. We can also use aspell lists to locate some more missing words. In Wikipedia there is a project named moss (under typo team) that offers thousands of missing words that are used in Wikipedia.Uziel302 (talk) 21:18, 25 November 2019 (UTC)
- @Uziel302: indeed we will have typo but they should be limited because here we parse newspaper (not blog and forum). And yes, there are alrealdy a lot of missing words but parsing newspaper will help to identify neologisms and then to create the missing entry. It is interesting because people can look for neologism more than rarer words. Pamputt (talk) 06:45, 26 November 2019 (UTC)
Voting
- Oppose Uziel302 (talk) 06:29, 26 November 2019 (UTC)
- Support Noé (talk) 21:44, 20 November 2019 (UTC)
- Support Great idea ! Lyokoï (talk) 12:32, 21 November 2019 (UTC)
- Support--Pom445 (talk) 16:10, 21 November 2019 (UTC)
- Support Otourly (talk) 16:12, 21 November 2019 (UTC)
- Support Hildepont (talk) 16:45, 21 November 2019 (UTC)
- Support Exilexi (talk) 20:11, 21 November 2019 (UTC)
- Support Pamputt (talk) 21:31, 21 November 2019 (UTC)
- Support Libcub (talk) 08:55, 22 November 2019 (UTC)
- Support but Theklan makes a point. BEANS X2 (talk) 12:09, 23 November 2019 (UTC)
- Support Shizhao (talk) 03:05, 25 November 2019 (UTC)
- Support Skirienko (talk) 13:12, 25 November 2019 (UTC)
- Support DemonDays64 (talk) 14:43, 25 November 2019 (UTC)
- Support--Yoavd (talk) 15:15, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:45, 25 November 2019 (UTC)
- Support A garbage person (talk) 16:13, 25 November 2019 (UTC)
- Support 游魂 17:06, 25 November 2019 (UTC)
- Support Waddie96 (talk) 18:43, 25 November 2019 (UTC)
- Support Eunostos (talk) 20:51, 25 November 2019 (UTC)
- Support Harshil169 (talk) 13:13, 26 November 2019 (UTC)
- Support --Thibaut120094 (talk) 16:42, 26 November 2019 (UTC)
- Support Cinemantique (talk) 22:59, 26 November 2019 (UTC)
- Support The Editor's Apprentice (talk) 18:22, 29 November 2019 (UTC)
- Support Romainbehar (talk) 12:52, 30 November 2019 (UTC)
- Support Novak Watchmen (talk) 17:45, 2 December 2019 (UTC)
Wikicode variables usable in and between templates
- Problem: Wiktionaries organize their pages using a section for each language. However, in each template of each language section, we must add the language code, which leads to errors and a lot of repetitions
- Who would benefit: All projects needing to define a value and to use it several times. Also it would make contribution for beginners much easier.
- Proposed solution: Be able to define variables, to assign and reassign values and to use them in templates.
- More comments:
- As an example, here's what I thought for French Wiktionary:
- Define and assign the language code to the variable
lang
at the beginning of the section. - For each template which needs the language code, use the variable
lang
in the template's source code.
- Define and assign the language code to the variable
- The templates of the French Wiktionary which would benefit from this proposition are:
- the pronunciation templates
pron
,phon
andphono
- the stub templates such as
ébauche
,ébauche-étym
,ébauche-exe
, etc... - the domain and lexicon templates such as
poissons
,apiculture
,mathématiques
, etc...
- the pronunciation templates
- As an example, here's what I thought for French Wiktionary:
- Phabricator tickets:
- Proposer: Lepticed7 (talk) 15:15, 10 November 2019 (UTC)
Discussion
- Having this kind of variable or being able to identify a section of a page as describing a specific language could help a lot to deal with multilinguism. The challenge here is to not include the whole in a template as it will make it more difficult to edit, but to tag a segment where a language code is valid. It could clarify the wikicode a lot. Noé (talk) 15:39, 10 November 2019 (UTC)
Voting
- Support Noé (talk) 21:45, 20 November 2019 (UTC)
- Support Lepticed7 (talk) 12:32, 21 November 2019 (UTC)
- Support Lyokoï (talk) 12:35, 21 November 2019 (UTC)
- Support Darmo117 (talk) 14:12, 21 November 2019 (UTC)
- Support Otourly (talk) 16:13, 21 November 2019 (UTC)
- Support Pamputt (talk) 21:32, 21 November 2019 (UTC)
- Support Wargo (talk) 23:18, 21 November 2019 (UTC)
- Support Libcub (talk) 08:56, 22 November 2019 (UTC)
- Support Jpgibert (talk) 14:53, 23 November 2019 (UTC)
- Support JogiAsad (talk) 12:58, 25 November 2019 (UTC)
- Support Tohaomg (talk) 15:08, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:48, 25 November 2019 (UTC)
- Support 游魂 17:07, 25 November 2019 (UTC)
- Support Waddie96 (talk) 18:47, 25 November 2019 (UTC)
- Support Peter Gröbner (talk) 10:25, 26 November 2019 (UTC)
- Support Thibaut120094 (talk) 16:45, 26 November 2019 (UTC)
- Support MarcoSwart (talk) 16:27, 29 November 2019 (UTC)
- Support The Editor's Apprentice (talk) 18:58, 29 November 2019 (UTC)
- Support Romainbehar (talk) 12:53, 30 November 2019 (UTC)
- Support Curious (talk) 21:47, 30 November 2019 (UTC)
- Support Sebleouf (talk) 18:39, 1 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:46, 2 December 2019 (UTC)
Change color of the interwiki link regarding to the content of the sections in the page
- Problem: Cognate is now deployed on all Wiktionaries to manage interwiki links. Currently, all links are blue. The suggestion is to color the interwiki link differently, if on the linked page, there is a section related to the current language.
- Example :
- I'm on the French Wiktionary, on the page "pain". There is an interwiki link to the English Wiktionary because a page "pain" also exists there.
- On this en:pain, there are several sections for several definitions in several languages. There is a section about French word "pain".
- Then, on the French page, the link will be blue.
- Otherwise, if no French section exists on the English page, then on the French page, the link to the English page will be (for example) green.
- Who would benefit: this informs the user that even if a page exist in another language, there is no section about his own language, then maybe he could go there and add it. It would encourage contribution and cross-wiki contribution.
- Proposed solution: improve the Cognate extension or develop a new gadget.
- More comments: a list with the formatting of all the Wiktionaries have already been built and is available here.
- Phabricator tickets: T150841
- Proposer: Pamputt (talk) 18:07, 7 November 2019 (UTC)
Discussion
- Hi! I don't understand when the link is supposed to be blue. Is it only when there are, on both side, the same language sections? Lepticed7 (talk) 09:01, 11 November 2019 (UTC)
Voting
- Support KevinUp (talk) 08:56, 21 November 2019 (UTC)
- Support Lepticed7 (talk) 12:37, 21 November 2019 (UTC)
- Support Lyokoï (talk) 12:37, 21 November 2019 (UTC)
- Support Otourly (talk) 16:09, 21 November 2019 (UTC)
- Support Pamputt (talk) 21:30, 21 November 2019 (UTC)
- Support Libcub (talk) 08:58, 22 November 2019 (UTC)
- Support Maybe as a userscript? BEANS X2 (talk) 12:15, 23 November 2019 (UTC)
- Support Jpgibert (talk) 12:16, 23 November 2019 (UTC)
- Support Noé (talk) 23:12, 23 November 2019 (UTC)
- Support JogiAsad (talk) 13:03, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:57, 25 November 2019 (UTC)
- Support Romuald 2 (talk) 16:21, 25 November 2019 (UTC)
- Support 游魂 17:13, 25 November 2019 (UTC)
- Support Waddie96 (talk) 18:50, 25 November 2019 (UTC)
- Support Dirac (talk) 02:29, 1 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:46, 2 December 2019 (UTC)
Find more active users
- Problem: Small user communities (Wiktionary as well as others) have a problem to find and welcome new users.
- Who would benefit:
- Proposed solution: Solve bug T234798 to improve Mediawiki's existing mechanism for finding "active" users (with 1 contribution in the last 30 days) to add a threshold for at least some number N contributions.
- More comments: When created in early October 2019, T234798 was categorized as a low priority. Hopefully, this wishlist survey could change that.
- Phabricator tickets: phab:T234798
- Proposer: LA2 (talk) 20:57, 23 October 2019 (UTC)
Discussion
- This is definitely a bug (and has been logged as such), but I'm curious as to how we could use the function for the purposes of the project. Could it be used to encourage further editing, for instance? Yannis ✆|☑ 13:09, 27 October 2019 (UTC)
- It's not a bug, but a feature request. Today, when I look at the list of "active" users on Swedish Wiktionary, I get a list of 79 people who made at least one edit in the last 30 days. But many of these have done only one or two edits as part of vandalism. I want to find the people who made at least 10 edits to find newcomers that should be welcomed. It is possible to scroll through the 79 names and pick those with at least 10 edits. But the software could provide that filtering. --LA2 (talk) 20:18, 27 October 2019 (UTC)
Voting
- Support Nice proposition! Lyokoï (talk) 12:34, 21 November 2019 (UTC)
- Support Sadads (talk) 21:44, 21 November 2019 (UTC)
- Support Libcub (talk) 08:59, 22 November 2019 (UTC)
- Support This is an easy way to facilitate collaboration. Nemo 09:09, 22 November 2019 (UTC)
- Support LA2 (talk) 12:56, 25 November 2019 (UTC)
- Support --Stilfehler (talk) 14:45, 25 November 2019 (UTC)
- Support Melroross (talk) 15:21, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:54, 25 November 2019 (UTC)
- Support 游魂 17:11, 25 November 2019 (UTC)
- Support Ciao • Bestoernesto • ✉ 19:47, 25 November 2019 (UTC)
- Support Good proposal! Harshil169 (talk) 13:12, 26 November 2019 (UTC)
- Support Thibaut120094 (talk) 16:49, 26 November 2019 (UTC)
- Support It would be helpful. I hope that we count only unreverted contributions. DCDuring (talk) 18:23, 30 November 2019 (UTC)
- Support Novak Watchmen (talk) 17:46, 2 December 2019 (UTC)
Insert attestation using Wikisource as a corpus
- Problem: Wiktionaries definitions relies on attestations, sentences from corpora illustrating the usages and meanings of words. Wikisource is an excellent corpus for Wiktionaries, especially for classic uses, but it is uneasy to search into the texts for a specific word. Now, the reference of the sentence had to be copy/paste by hand and it's a long and unfunny way to contribute, the result being few quotation from Wikisources (less than 3 % for French Wiktionary).
- Who would benefit: Readers of Wiktionaries would find more examples of usages and a way to access the whole source directly in Wikisource. Contributors of Wiktionaries would have a fancy and enjoyable way to add attestations, similarly as Insert media tool that dig into Wikimedia Commons, and the community may grow with new people that like to add sentences from their readings. Editors of Wikisource would have a new way to shed light on their sisyphean work. Both projects visibility would increase in search engines with more links between them. The global audience of both projects may increase with more connectivity. Also, other projects may benefit from this feature, such as Wikipedia to add quotations in authors' pages.
- Proposed solution: This feature is inspired by Insert media but targeting Wikisource instead of Wikimedia Commons. So, instead of an snippet search offering pictures, Insert attestation would display a list of sentences from a targeted Wikisource (could be same language or other than the source project) that include the targeted sequence of characters. Their is no meaning requirement nor proximity, it is exact results only to keep it simple. In the displayed snippet of results, an editor would just grab a sentence with a single click and it will be added with the adequate sources picked from Wikidata associated with the Wikisource page. The feature would copy the sentence (no transclusion) and the source of the sentence (adding the information for the number of the page in the original manuscript optimally, i.e. "page 35."). This feature may need a specific parser to identify limits of sentences and to bold the targeted sequence of characters.
- More comments: This feature/tool/functionality should be accessible through WikiText editor and VisualEditor. It may be interesting to keep track of the reuses of Wikisource content in other project with a specific What's link here from Wiktionary to Wikisource, similarly as Wikimedia Commons indication of reuses in others projects, but this could be part of another development. This idea was suggested in 2018 with 36 supports, in 2017 and supported by 32 people, a draft was suggested in 2016 with 19 supports and this idea was coined first in a MediaWiki discussion.
- Phabricator tickets: T139152, T157802
- Proposer: Noé (talk) 07:33, 22 October 2019 (UTC)
Discussion
- I support the idea. If it will be possible to add examples from Wikisource to Wiktionary examples then it will be great! It will be real integration of two projects: Wiktionary and Wikisource. The solution of this problem requires: to split Wikisource text into sentences, to lemmatize words, create tables with links from lemmas, wordforms to texts. --Andrew Krizhanovsky (talk) 10:34, 24 October 2019 (UTC)
- In my opinion, it is not necessary to lemmatize, as inflected forms can be good examples for infected forms entries. There is an entry for each forms in Wiktionaries, so if you look for teeth, you don't want tooth in the results. Noé (talk) 13:29, 24 October 2019 (UTC)
- Agree with Noé--So9q (talk) 20:51, 24 October 2019 (UTC)
- I want the user to be able to choose: (1) search for sentences with all word forms of the lemma, or (2) search only this word form (strict search). --Andrew Krizhanovsky (talk) 18:22, 1 November 2019 (UTC)
- Agree with Noé--So9q (talk) 20:51, 24 October 2019 (UTC)
- In my opinion, it is not necessary to lemmatize, as inflected forms can be good examples for infected forms entries. There is an entry for each forms in Wiktionaries, so if you look for teeth, you don't want tooth in the results. Noé (talk) 13:29, 24 October 2019 (UTC)
- I would prefer a tool like [1] for this task. Anyone can adapt or improve it by adding the Wikisource Search API as a backend. Example search for "meaning".--So9q (talk) 20:51, 24 October 2019 (UTC)
- Would you accept making a tool like that official and integrated by default, as suggested in the proposal? That's what the proposal is really about for me—making it easily accessible to all and not just custom JS users (who are a small fraction of Wiktionary editors, let alone readers). Yannis ✆|☑ 13:15, 27 October 2019 (UTC)
- Strong support. I have done this manually many times, especially for words I first encounter at en.ws. This is a great proposal. —Justin (koavf)❤T☮C☺M☯ 19:41, 2 November 2019 (UTC)
- My idea is - page Foo (1), Click on something will run search in wikisource for sentences conatining word foo (2). Then editor must chceck, if this word is in correct context/sense and select part for copy to some input field (3). Sometimes some corrections are needed (…), shorten long sentence, add missing subject from previous sentence... Then click to OK - and there will be example (4) with reference.
- I have word cs:wikt:pitel,
- Search on Wikisource gives me some examples
- I select one of them - sentence
Od dávna trvající věrný pitel vína dobrého.
from Paměti - I got
#* {{Příklad|cs|Od dávna trvající věrný pitel vína dobrého.}}<ref>Mikuláš Dačický z Heslova: [[s:Paměti/1601–1605|Paměti]]</ref>
for copying to Wiktionary.
JAn Dudík (talk) 20:52, 7 November 2019 (UTC)
- I agree with your description, but I also think it could be done in VisualEditor without even see any wikicode. It could be user-friendly and easily accessible for new user, like "Add translation" in some wiktionaries. Like "Insert Media", very easy to use in Wiktionary. - Noé (talk) 16:47, 8 November 2019 (UTC)
Voting
- Support JAn Dudík (talk) 07:23, 21 November 2019 (UTC)
- Support KevinUp (talk) 08:56, 21 November 2019 (UTC)
- Support beneficial for both Wiktionaries and Wikisources. VIGNERON * discut. 11:24, 21 November 2019 (UTC)
- Support Consulnico (talk) 11:29, 21 November 2019 (UTC)
- Support very useful ! Lyokoï (talk) 12:39, 21 November 2019 (UTC)
- Support Manseng (talk) 12:55, 21 November 2019 (UTC)
- Support Le ciel est par dessus le toit (talk) 13:09, 21 November 2019 (UTC)
- Support Nemo Le Poisson (talk) 15:33, 21 November 2019 (UTC)
- Support--Pom445 (talk) 16:11, 21 November 2019 (UTC)
- Support Otourly (talk) 16:12, 21 November 2019 (UTC)
- Support — WikiLucas (🖋️) 19:34, 21 November 2019 (UTC)
- Support Exilexi (talk) 20:12, 21 November 2019 (UTC)
- Support Pamputt (talk) 21:31, 21 November 2019 (UTC)
- Support Sadads (talk) 21:49, 21 November 2019 (UTC)
- Support Hector (talk) 23:43, 21 November 2019 (UTC)
- Support Balajijagadesh (talk) 05:29, 22 November 2019 (UTC)
- Support Libcub (talk) 08:52, 22 November 2019 (UTC)
- Support Jahl de Vautban (talk) 09:13, 22 November 2019 (UTC)
- Support this is so clever! Theklan (talk) 10:26, 22 November 2019 (UTC)
- Support Lionel Scheepmans ✉ Contact French native speaker, sorry for my dysorthography 10:41, 22 November 2019 (UTC)
- Support Unapersona (talk) 17:17, 22 November 2019 (UTC)
- Support Andrew Sheedy (talk) 04:10, 23 November 2019 (UTC)
- Support Jpgibert (talk) 14:52, 23 November 2019 (UTC)
- Support Emptyfear (talk) 17:20, 23 November 2019 (UTC)
- Support Shizhao (talk) 03:03, 25 November 2019 (UTC)
- Support Ayack (talk) 13:33, 25 November 2019 (UTC)
- Support 慈居 (talk) 14:26, 25 November 2019 (UTC)
- Support--Yoavd (talk) 15:17, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:49, 25 November 2019 (UTC)
- Support Romuald 2 (talk) 16:16, 25 November 2019 (UTC)
- Support 游魂 17:09, 25 November 2019 (UTC)
- Support Sintakso (talk) 17:45, 25 November 2019 (UTC)
- Support Vriullop (talk) 18:17, 25 November 2019 (UTC)
- Support Ninovolador (talk) 21:29, 25 November 2019 (UTC)
- Support --Thibaut120094 (talk) 16:41, 26 November 2019 (UTC)
- Support Ivanics (talk) 03:27, 27 November 2019 (UTC)
- Support WhatamIdoing (talk) 16:46, 27 November 2019 (UTC)
- Support I could have used it for the last 10 years. Now, especially because we are trying to improve the veracity of the hundred thousand or more citations and cryptic references to citations copied from turn-of-the-20th-Century dictionaries, like Merriam-Webster 1913, Century 1911, and Chambers 1908. DCDuring (talk) 03:39, 28 November 2019 (UTC)
- Support MarcoSwart (talk) 16:26, 29 November 2019 (UTC)
- Support I think So9q's suggestion to start with the QQ script and build from there is a good one. I also think that any final tool would benefit from having an option to search Wikisource and/or Google Books (QQ currently uses Google Books as a corpus) since it would allow for a much broader term coverage and attestation example variety. The Editor's Apprentice (talk) 18:43, 29 November 2019 (UTC)
- Support DaraDaraDara (talk) 20:33, 29 November 2019 (UTC)
- Support Marxav (talk) 10:15, 30 November 2019 (UTC)
- Support Curious (talk) 21:50, 30 November 2019 (UTC)
- Support Info-farmer (talk) 02:28, 1 December 2019 (UTC)
- Support --Rapaloux (talk) 08:51, 1 December 2019 (UTC)
- Support Poslovitch (talk) 16:45, 1 December 2019 (UTC)
- Support Sebleouf (talk) 18:38, 1 December 2019 (UTC)
- Support Erutuon (talk) 19:40, 1 December 2019 (UTC)
- Support FreeCorp (talk) 20:17, 1 December 2019 (UTC)
- Support Rahmanuddin (talk) 06:50, 2 December 2019 (UTC)
- Support Satdeep Gill (talk) 10:56, 2 December 2019 (UTC)
- Support Geraki TL 13:15, 2 December 2019 (UTC)
- Support Lepticed7 (talk) 13:35, 2 December 2019 (UTC)
- Support Trizek from FR 13:36, 2 December 2019 (UTC)
- Support Saederup92 (talk) 13:37, 2 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:46, 2 December 2019 (UTC)
Create memory games for words in watchlist
- Problem: The watchlist has a fairly limited function.
- Who would benefit: Those who seek to improve word recollection of "favorited" entries.
- Proposed solution: Redirect the watchlist to another site that draws out from the list and randomly selects words for memory games.
- More comments:
- Phabricator tickets:
- Proposer: Clicero (talk) 21:28, 24 October 2019 (UTC)
Discussion
- @Clicero: it looks like a 2019 proposal. Would this proposal fits your need (IMHO, the 2019 proposal is broader)? If so, I will update your proposal to take into account information given last year. Pamputt (talk) 17:11, 1 November 2019 (UTC)
@Clicero: the English name for this is flashcards, perhaps people will understand you better if you use it. MaxSem (WMF) (talk) 19:25, 8 November 2019 (UTC)
Voting
- Support Ayannichka (talk) 16:25, 21 November 2019 (UTC)
- Support Libcub (talk) 09:01, 22 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:51, 25 November 2019 (UTC)
- Support 游魂 17:10, 25 November 2019 (UTC)
- Support Ciao • Bestoernesto • ✉ 19:41, 25 November 2019 (UTC)
- Support Noé (talk) 09:03, 27 November 2019 (UTC)
- Support Novak Watchmen (talk) 17:47, 2 December 2019 (UTC)
Display definitions from Wikisource dictionaries
- Problem: Wiktionaries offer some definitions but there are many ways to describe a meaning, and the actual wiktionary interface doesn't make it easy to display definitions from other dictionaries. Some are mentioned as references but they are not accessible in Wiktionary.
- Who would benefit: Wiktionary readers
- Proposed solution: Many dictionaries are already in Wikisource and we can use them to offer more definitions. A dedicated transclusion may help harvesting automatically entries with a specific tagging in the dictionaries hosted in Wikisources. They could come from several Wikisources, to be display in several Wiktionaries. It could be a new tab next to "Article" and "Talk", named "Dictionaries".
- More comments: Some dictionaries are already properly tagged; for the others, it could be a good opportunity to do it, so that they can more easily be reused in open source projects.
- Phabricator tickets: T240191
- Proposer: DaraDaraDara (talk) 14:32, 8 November 2019 (UTC)
Discussion
- I think it's a great cross-project development, and it's different than the proposal to use Wikisource as a corpora, this one target dictionaries, and the other idea target books. It could be a good opportunity to follow TEI Lex0 guidelines for the dictionaries in Wikisource Noé (talk) 18:28, 8 November 2019 (UTC)
Voting
- Support Noé (talk) 21:44, 20 November 2019 (UTC)
- Support beneficial for both Wiktionaries and Wikisources. VIGNERON * discut. 11:26, 21 November 2019 (UTC)
- Support Lyokoï (talk) 12:40, 21 November 2019 (UTC)
- Support Manseng (talk) 12:59, 21 November 2019 (UTC)
- Support Le ciel est par dessus le toit (talk) 13:12, 21 November 2019 (UTC)
- Support Otourly (talk) 16:08, 21 November 2019 (UTC)
- Support--Pom445 (talk) 16:09, 21 November 2019 (UTC)
- Support Hildepont (talk) 16:34, 21 November 2019 (UTC)
- Support — WikiLucas (🖋️) 18:32, 21 November 2019 (UTC)
- Support Exilexi (talk) 20:23, 21 November 2019 (UTC)
- Support Pamputt (talk) 21:27, 21 November 2019 (UTC)
- Support Hector (talk) 23:41, 21 November 2019 (UTC)
- Support Amir E. Aharoni (talk) 08:21, 22 November 2019 (UTC)
- Support Libcub (talk) 08:53, 22 November 2019 (UTC)
- Support Jahl de Vautban (talk) 09:16, 22 November 2019 (UTC)
- Support Theklan (talk) 10:28, 22 November 2019 (UTC)
- Support Lionel Scheepmans ✉ Contact French native speaker, sorry for my dysorthography 10:41, 22 November 2019 (UTC)
- Support Jpgibert (talk) 12:09, 23 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:50, 25 November 2019 (UTC)
- Support A garbage person (talk) 16:13, 25 November 2019 (UTC)
- Support Romuald 2 (talk) 16:19, 25 November 2019 (UTC)
- Support 游魂 17:10, 25 November 2019 (UTC)
- Support Sintakso (talk) 17:47, 25 November 2019 (UTC)
- Support Eunostos (talk) 20:52, 25 November 2019 (UTC)
- Support JAn Dudík (talk) 09:12, 26 November 2019 (UTC)
- Support Harshil169 (talk) 13:13, 26 November 2019 (UTC)
- Support --Kusurija (talk) 16:56, 27 November 2019 (UTC)
- Support OneLook is a good supplemental source of current definitions in English for comparative purposes, but most definitions there are copyrighted. WikiSource dictionaries would provide copyable starter definitions (usually needing to be put in contemporary terms) as well historical definitions. DCDuring (talk) 18:30, 30 November 2019 (UTC)
- Support Info-farmer (talk) 02:07, 1 December 2019 (UTC)
- Support Jan Kameníček (talk) 18:48, 1 December 2019 (UTC)
- Support Jberkel (talk) 23:30, 1 December 2019 (UTC)
- Support Sannita - not just another it.wiki sysop 13:07, 2 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:47, 2 December 2019 (UTC)
More Lua memory for Wiktionary
- Problem: Lack of Lua memory for basic words. See wikt:CAT:E for currently affected words.
- Who would benefit: All users and readers of Wiktionary.
- Proposed solution: More Lua memory for Wiktionary.
- More comments:
- Pages that lack memory are not being properly categorized and the sortkey is not working properly.
- Standard information such as citations, semantically related terms are being removed as a temporary solution and this is a loss of information for our readers.
- Phabricator tickets: phab:T188492
- Proposer: KevinUp (talk) 16:20, 11 November 2019 (UTC)
Discussion
Alternatively, consider implementing a tool so that the source of each language can have its own separate page, like how all the proposals have its own individual page. KevinUp (talk) 16:20, 11 November 2019 (UTC)
- The most parsimonious solution is to raise the cap on Lua memory. This cap seems arbitrarily placed, and it is crippling for long pages. Metaknowledge (talk) 18:04, 11 November 2019 (UTC)
- Indeed. If all were like in a company we would already have more memory, because the time spent to circumvent the cap is dearer than the trifling amount of more memory that in total would be used (since it concerns but some dozens of pages, for which much dust has been raised). Fay Freak (talk) 21:52, 15 November 2019 (UTC)
- @Noé: Hi. Does the French Wiktionary have the same issue (lack of Lua memory) for entries with short words? I think if we were to migrate information from English Wiktionary to French Wiktionary, the same situation would occur. KevinUp (talk) 23:32, 16 November 2019 (UTC)
- Local community discussion regarding lack of Lua memory can be found here, here and here. If only the Community Tech team would be graceful enough to inform us the actual memory that is needed by wikt:do, wikt:一, wikt:人, wikt:水, wikt:月, wikt:生, wikt:我 which are basic words. KevinUp (talk) 20:15, 18 November 2019 (UTC)
- @Pamputt: Hi. Does the French Wiktionary currently have issues with lack of Lua memory? Do you think the same issue would occur if information from English Wiktionary for entries such as wikt:do, wikt:一, wikt:人, wikt:水 were copied to the French Wiktionary? KevinUp (talk) 11:56, 19 November 2019 (UTC)
- @KevinUp: actually we do not use that much Lua module on the French Wiktionary so I am not aware of such limitations. Yet, maybe JackPotte or Darkdadaah can say more. Pamputt (talk) 18:50, 19 November 2019 (UTC)
- We do use Lua modules quite a bit, although not as much as the English Wiktionary. We don't have as much metadata (languages in particular) and automated content, so I believe we are not at the point where memory is an issue... yet. Our main issue at the moment I believe may be for pages with lots of translations, as in this demonstration page which purports to list the word for "water" in all languages: wikt:fr:Utilisateur:Pamputt/eau. In that case though the limit is execution time (>10s).
- For the memory issue, it would be nice to have an idea of what takes so much memory, so that we can make an informed decision on how much memory will be needed. Darkdadaah (talk) 16:12, 21 November 2019 (UTC)
- Thanks for the reply. For translations, some entries in English Wiktionary use wikt:Category:Translation subpages to redirect content and reduce Lua memory. Yes, it would be nice if we knew how much memory is actually needed by pages in wikt:Category:Pages with module errors. KevinUp (talk) 07:15, 22 November 2019 (UTC)
- @KevinUp: actually we do not use that much Lua module on the French Wiktionary so I am not aware of such limitations. Yet, maybe JackPotte or Darkdadaah can say more. Pamputt (talk) 18:50, 19 November 2019 (UTC)
- @Lo Ximiendo: Does the Chinese Wiktionary use a lot of Lua memory as well? I noticed that it uses similar modules from English Wiktionary. KevinUp (talk) 05:13, 30 November 2019 (UTC)
- @KevinUp: All I know is, that the Lua modules in the Chinese were imported from the English Wiktionary, with modifications made of course. --Lo Ximiendo (talk) 05:29, 30 November 2019 (UTC)
- @Pamputt: Hi. Does the French Wiktionary currently have issues with lack of Lua memory? Do you think the same issue would occur if information from English Wiktionary for entries such as wikt:do, wikt:一, wikt:人, wikt:水 were copied to the French Wiktionary? KevinUp (talk) 11:56, 19 November 2019 (UTC)
- Local community discussion regarding lack of Lua memory can be found here, here and here. If only the Community Tech team would be graceful enough to inform us the actual memory that is needed by wikt:do, wikt:一, wikt:人, wikt:水, wikt:月, wikt:生, wikt:我 which are basic words. KevinUp (talk) 20:15, 18 November 2019 (UTC)
- @Noé: Hi. Does the French Wiktionary have the same issue (lack of Lua memory) for entries with short words? I think if we were to migrate information from English Wiktionary to French Wiktionary, the same situation would occur. KevinUp (talk) 23:32, 16 November 2019 (UTC)
- Indeed. If all were like in a company we would already have more memory, because the time spent to circumvent the cap is dearer than the trifling amount of more memory that in total would be used (since it concerns but some dozens of pages, for which much dust has been raised). Fay Freak (talk) 21:52, 15 November 2019 (UTC)
- There's also a phabricator task for better memory profiling support, which would allow us to do targeted optimizations instead of blind guesswork. – Jberkel (talk) 08:28, 2 December 2019 (UTC)
Voting
- Support as proposer. KevinUp (talk) 03:45, 21 November 2019 (UTC)
- Support Metaknowledge (talk) 05:32, 21 November 2019 (UTC)
- Support Mellohi! (talk) 14:05, 21 November 2019 (UTC)
- Support Smashhoof (talk) 19:36, 21 November 2019 (UTC)
- Support Pamputt (talk) 21:29, 21 November 2019 (UTC)
- Support Sadads (talk) 21:44, 21 November 2019 (UTC)
- Support Libcub (talk) 08:56, 22 November 2019 (UTC)
- Support DCDuring (talk) 03:54, 23 November 2019 (UTC)
- Support Andrew Sheedy (talk) 04:09, 23 November 2019 (UTC)
- Support --Lambiam 09:33, 23 November 2019 (UTC)
- Support I'd like to see Lua experts work closely with the enwiktionary community to resolve this issue. There will be flow-on benefits for all Wiktionary versions. This, that and the other (talk) 01:44, 24 November 2019 (UTC)
- Support — Mnemosientje (t · c) 12:13, 25 November 2019 (UTC)
- Support JogiAsad (talk) 12:59, 25 November 2019 (UTC)
- Support DemonDays64 (talk) 14:42, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:50, 25 November 2019 (UTC)
- Support 游魂 17:09, 25 November 2019 (UTC)
- Support Even though I believe this will not be enough long term. Long term solution is IMO to get translations and other interrelations between words from Wikidata Lexemes where there are no such limits. So9q (talk) 18:47, 25 November 2019 (UTC)
- @So9q: there may be other limits with Wikidata espaecially when it is queried. Pamputt (talk) 06:47, 26 November 2019 (UTC)
- @Pamputt: Do you mean time out? That is a problem, but only for very large collections (multiple millions) of humans, or with lots of filtering on something that does not have P31. None of our current lexeme queries never times out or are even close, that might change of course when the number of lexemes grow.--So9q (talk) 09:19, 26 November 2019 (UTC)
- @So9q: there may be other limits with Wikidata espaecially when it is queried. Pamputt (talk) 06:47, 26 November 2019 (UTC)
- Support Ilawa-Kataka (talk) 19:11, 25 November 2019 (UTC)
- Support Vorziblix (talk) 05:15, 26 November 2019 (UTC)
- Support Thibaut120094 (talk) 16:43, 26 November 2019 (UTC)
- Support Erutuon (talk) 21:16, 26 November 2019 (UTC)
- Support Gce (talk) 21:28, 27 November 2019 (UTC)
- Support Curious (talk) 22:20, 29 November 2019 (UTC)
- Support Canonicalization (talk) 10:08, 30 November 2019 (UTC)
- Support 94rain Talk 12:55, 30 November 2019 (UTC)
- Support — Tom 144 (talk) 16:37, 30 November 2019 (UTC)
- Support AryamanA (talk) 17:28, 30 November 2019 (UTC)
- Support Justinrleung (talk) 18:58, 30 November 2019 (UTC)
- Support Equinox (talk) 10:44, 1 December 2019 (UTC)
- Support Jberkel (talk) 23:26, 1 December 2019 (UTC)
- Support Seems to be rather easy to fix this, but still +1 Sannita - not just another it.wiki sysop 13:08, 2 December 2019 (UTC)
- Support - TheDaveRoss (talk) 15:35, 2 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:48, 2 December 2019 (UTC)
Fix the AddAudio script to upload audio to Commons seamlessly
- Problem: A great user script that easily allowed users to record audio recordings of words on Wiktionary and upload them to Commons is broken. I have posted to phab:T206942, and for assistance at Commons and Wiktionary to no avail.
- Who would benefit: Anyone who wants to hear the audio at Wiktionary, particularly for blind users or those who are learning about foreign languages.
- Proposed solution: My understanding is that there is a problem with the user script interacting with Commons' API. The script has already been made, so it's not starting from scratch, but tweaking how it saves files at Commons.
- More comments:
- Phabricator tickets: phab:T206942
- Proposer: —Justin (koavf)❤T☮C☺M☯ 19:49, 2 November 2019 (UTC)
Discussion
- @Yair rand: courtesy ping —TheDJ (talk • contribs) 12:54, 4 November 2019 (UTC)
- What about using Lingua Libre instead. You "just" need to write the code to support enwikt and all recording will be automatically uploaded to Commons and also on your wiki. Pamputt (talk) 17:51, 7 November 2019 (UTC)
- Lingua Libre bot already add recordings to English Wiktionary. But, it could be great to be able to use Lingua Libre recording tool, and metadata support, directly into Wiktionaries. Maybe it could be related with the proposal to develop a better display of recordings Noé (talk) 10:01, 13 November 2019 (UTC)
Voting
- Support Libcub (talk) 09:07, 22 November 2019 (UTC)
- Support BEANS X2 (talk) 12:10, 23 November 2019 (UTC)
- Support Noé (talk) 23:11, 23 November 2019 (UTC)
- Support JogiAsad (talk) 13:03, 25 November 2019 (UTC)
- Support Melroross (talk) 15:20, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:55, 25 November 2019 (UTC)
- Support Latisc (talk) 16:19, 25 November 2019 (UTC)
- Support 游魂 17:12, 25 November 2019 (UTC)
- Support Waddie96 (talk) 18:48, 25 November 2019 (UTC)
- Support Ciao • Bestoernesto • ✉ 19:51, 25 November 2019 (UTC)
- Support Gce (talk) 21:34, 27 November 2019 (UTC)
- Support The Editor's Apprentice (talk) 18:28, 29 November 2019 (UTC)
- Support Curious (talk) 22:24, 29 November 2019 (UTC)
- Support Romainbehar (talk) 12:53, 30 November 2019 (UTC)
- Support Sebleouf (talk) 18:39, 1 December 2019 (UTC)
- Support - TheDaveRoss (talk) 15:36, 2 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:48, 2 December 2019 (UTC)
Two options for displaying categories
- Problem: In dictionaries, words are normally displayed in alphabetical order. In wiktionaries, when a category is displayed, only a part of words of the category are displayed in alphabetical order, those in subcategories are not displayed. It is often useful to see all words of the category.
- Who would benefit: Everyone using categories.
- Proposed solution: When displaying a category, add a button to be used when the user wants all words, including words in subcategories (and subsubcategories, etc.)
- More comments:
- Phabricator tickets:
- Proposer: Lmaltier (talk) 20:49, 8 November 2019 (UTC)
Discussion
- It may be similar as Deepcat, a script described as supported by some Wiktionaries. A good opportunity to made it core? Noé (talk) 16:06, 10 November 2019 (UTC)
Voting
- Support Pamputt (talk) 21:27, 21 November 2019 (UTC)
- Support Libcub (talk) 09:02, 22 November 2019 (UTC)
- Support Noé (talk) 23:11, 23 November 2019 (UTC)
- Support JogiAsad (talk) 13:02, 25 November 2019 (UTC)
- Support Melroross (talk) 15:18, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:57, 25 November 2019 (UTC)
- Support 游魂 17:13, 25 November 2019 (UTC)
- Support Ciao • Bestoernesto • ✉ 19:53, 25 November 2019 (UTC)
- Support Thibaut120094 (talk) 16:48, 26 November 2019 (UTC)
- Support The Editor's Apprentice (talk) 18:44, 29 November 2019 (UTC)
- Support Romuald 2 (talk) 00:44, 2 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:48, 2 December 2019 (UTC)
Lexicographic knowledge as a service
- Problem: There is very little reuse of Wiktionary contents because the dumps doesn't fit the needs.
- Who would benefit: Reusers
- Proposed solution: Having more export formats, including set-ups to select a set of specific languages or a combinaison languages, or a set of 50k more viewed pages. DICT format, TEI Lex0 format, xml (based on GLAWI) and RDF (based on Dbnary) and so on.
- More comments: Dbnary could be used as the source data, and the other formats derived from it.
- Phabricator tickets:
- Proposer: Lyokoï (talk) 16:06, 10 November 2019 (UTC)
Discussion
- This proposal may be connected with Wiktionary in e-readers and e-book apps and to the development of a Wiktionary mobile app, as they may need a specific format. Kiwix could also be associate to this perspective. Noé (talk) 11:33, 15 November 2019 (UTC)
- Lyokoï, thank you for submitting this proposal! It is unfortunately out of scope, so we’ll be unable to take it on. For this work to be possible, structured Wiktionary would need to first be developed. Hopefully, this is something that can be done in the future. Thanks again, and we apologize for any disappointment. --IFried (WMF) (talk) 00:23, 20 November 2019 (UTC)
- IFried (WMF) What is a « structured Wiktionary » for you ? Wiktionary is already structured, It is one of the most structured project of the mouvement ! GLAWI, DBNARY is very powerful thank to our structure, and I have see a guy (Arkanosis) who generate in 10 min a dictionary of synonym with the french Wiktionary, in a few script. Can you be more explicit about that you need to do for that kind of export ? Lyokoï (talk) 00:54, 20 November 2019 (UTC)
- @Lyokoï: By "structured Wiktionary" I believe we mean one that is built on top of Wikibase. Currently the format of Wiktionary varies by project, since it is all stored as wikitext. I think we could make an export tool for your wiki, but making one that works for everyone may prove to be challenging if not impossible. Would you like to adjust this proposal to be just about French Wiktionary? If so I will run this by the team and we'll try to get this back into the survey before the voting starts tomorrow. MusikAnimal (WMF) (talk) 03:08, 20 November 2019 (UTC)
- Dbnary had made the mapping for 20 wiktionaries, so it is not impossible. Including Dnary code is open, the creator is easy to contact and the model is Lemon Ontolex, the same as Wikidata Lexeme project. There is no need for a Wikibase or any other formalism. I understand that you may not have the specific competences in RDF formatting in your team, but I don't consider it is out of the scope. Doing it for one version is not acceptable, as the need is real for each projects, and already expressed by other in the past years, like in Community Wishlist Survey 2017/Wiktionary/Parse dumps for DICT clients (17 supports). Finally, this proposal seems very much aligned with the 2030 strategy. Noé (talk) 06:46, 20 November 2019 (UTC)
- IFried (WMF) & MusikAnimal (WMF), I support the response of Noé, Wiktionaries doesn’t need to have a Wikibase to be structured. I admit their structures are not absolutely identical, but it’s for the most case just a différent order of sections. They are same granularity of information. I think it is very important for middle sized wiktionaries to be easily reused, it is really encouraging ! Lyokoï (talk) 12:26, 20 November 2019 (UTC)
- @Lyokoï and Noé: Would it make sense to build a tool that allows you to export data from Dbnary to the other formats you've listed? That seems doable. Otherwise, creating and maintaining something that parses unpredictable wikitext seems like it won't scale. I will admit most of us aren't too well-versed with Wiktionaries, but just comparing English vs. French, I see the latter is more template-heavy and in a somewhat different layout, and this is what gives us pause. I apologize that we're running out of time... Voting starts in one hour! So let me know if working off of Dbnary will work, and if so we will unarchive. Thanks, MusikAnimal (WMF) (talk) 17:00, 20 November 2019 (UTC)
- @MusikAnimal (WMF): building a tool on Dbnary sounds good for me! Noé (talk) 21:40, 20 November 2019 (UTC)
- @MusikAnimal (WMF): For me too! --Lyokoï (talk) 11:45, 21 November 2019 (UTC)
- Great, I've slightly modified the proposal to make this clear, and I am moving it back into the survey. Best, MusikAnimal (WMF) (talk) 16:53, 21 November 2019 (UTC)
- @Lyokoï and Noé: Would it make sense to build a tool that allows you to export data from Dbnary to the other formats you've listed? That seems doable. Otherwise, creating and maintaining something that parses unpredictable wikitext seems like it won't scale. I will admit most of us aren't too well-versed with Wiktionaries, but just comparing English vs. French, I see the latter is more template-heavy and in a somewhat different layout, and this is what gives us pause. I apologize that we're running out of time... Voting starts in one hour! So let me know if working off of Dbnary will work, and if so we will unarchive. Thanks, MusikAnimal (WMF) (talk) 17:00, 20 November 2019 (UTC)
- IFried (WMF) & MusikAnimal (WMF), I support the response of Noé, Wiktionaries doesn’t need to have a Wikibase to be structured. I admit their structures are not absolutely identical, but it’s for the most case just a différent order of sections. They are same granularity of information. I think it is very important for middle sized wiktionaries to be easily reused, it is really encouraging ! Lyokoï (talk) 12:26, 20 November 2019 (UTC)
- Dbnary had made the mapping for 20 wiktionaries, so it is not impossible. Including Dnary code is open, the creator is easy to contact and the model is Lemon Ontolex, the same as Wikidata Lexeme project. There is no need for a Wikibase or any other formalism. I understand that you may not have the specific competences in RDF formatting in your team, but I don't consider it is out of the scope. Doing it for one version is not acceptable, as the need is real for each projects, and already expressed by other in the past years, like in Community Wishlist Survey 2017/Wiktionary/Parse dumps for DICT clients (17 supports). Finally, this proposal seems very much aligned with the 2030 strategy. Noé (talk) 06:46, 20 November 2019 (UTC)
- @Lyokoï: By "structured Wiktionary" I believe we mean one that is built on top of Wikibase. Currently the format of Wiktionary varies by project, since it is all stored as wikitext. I think we could make an export tool for your wiki, but making one that works for everyone may prove to be challenging if not impossible. Would you like to adjust this proposal to be just about French Wiktionary? If so I will run this by the team and we'll try to get this back into the survey before the voting starts tomorrow. MusikAnimal (WMF) (talk) 03:08, 20 November 2019 (UTC)
- IFried (WMF) What is a « structured Wiktionary » for you ? Wiktionary is already structured, It is one of the most structured project of the mouvement ! GLAWI, DBNARY is very powerful thank to our structure, and I have see a guy (Arkanosis) who generate in 10 min a dictionary of synonym with the french Wiktionary, in a few script. Can you be more explicit about that you need to do for that kind of export ? Lyokoï (talk) 00:54, 20 November 2019 (UTC)
- I suggest to change the title of the proposal to match the new content. It's not clear whether the current proposal is to have some kind of service as a software substitute or what. The proposal is to have a web API to Dbnary data, correct? Nemo 09:28, 22 November 2019 (UTC)
- Proposals have to be problems not a specific solution, to let the Community Tech team work and find the better way to solve this problem. Here, the problem is how to offer more format on Wiktionaries exports. One suggestion is to build something on top of Dbnary transformation, as a big part of the job of alignment between wiktionaries is already made by this project. So, it is not an API that dig directly into Dbnary. Plus, this is something that already exist in Dbnary website. Noé (talk) 06:51, 27 November 2019 (UTC)
Voting
- Support and I must say I really appreciate the dialogue up here with the tech team. Noé (talk) 08:57, 22 November 2019 (UTC)
- Support Libcub (talk) 09:09, 22 November 2019 (UTC)
- Support Pamputt (talk) 09:21, 22 November 2019 (UTC)
- Support as proposer Lyokoï (talk) 22:19, 22 November 2019 (UTC)
- Support JogiAsad (talk) 13:07, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:56, 25 November 2019 (UTC)
- Support 游魂 17:12, 25 November 2019 (UTC)
- Support Ciao • Bestoernesto • ✉ 19:34, 25 November 2019 (UTC)
- Support Ninovolador (talk) 21:30, 25 November 2019 (UTC)
- Support The Editor's Apprentice (talk) 18:50, 29 November 2019 (UTC)
- Support Marxav (talk) 10:20, 30 November 2019 (UTC)
- Support Info-farmer (talk) 02:26, 1 December 2019 (UTC)
- Support Yes, definitely Sannita - not just another it.wiki sysop 13:07, 2 December 2019 (UTC)
- Support Novak Watchmen (talk) 17:48, 2 December 2019 (UTC)
Sections reorder tools
- Problem: When I work on very long page containing a lot of section like thesaurus, it is not easy to modify the section order to improve the page layout. It is necessary to edit all the page. During the operation, everybody can edit a section and create an edition conflict.
- Who would benefit: contributors
- Proposed solution: it will be interesting to have in graphic modification mode 2 buttons on each section (h2, h3, h4...): up and down. The advantage is a simple method to improve page layout and allow to limit the entry in history to a simple comment like: section reorder.
- More comments:
- Phabricator tickets:
- Proposer: Jpgibert (talk) 20:30, 10 November 2019 (UTC)
Discussion
- Jpgibert, when you say "graphic modification", do you mean VisualEditor? Noé (talk) 14:12, 15 November 2019 (UTC)
- Yes, Noé. I forgot the suitable term when I wrote. Thanks for your help. Jpgibert (talk) 14:40, 15 November 2019 (UTC)
- You're welcome. Then, consider French Wiktionary is the only Wiktionary that offer VisualEditor, for the other wiktionaries, they don't use it. So, your suggestion has to be tied with the proposal to adapt VisualEditor to Wiktionaries.
- translation in French: Bon en fait, on est tous les deux francophones, donc : de rien. En fait, le Wiktionnaire est la seule version de Wiktionary qui utilise l'éditeur visuel, les autres versions ne l'utilisent pas. Du coup, ta suggestion devrait être rattachée ou connectée à celle proposant de construire un vrai éditeur visuel dédié aux Wiktionnaires. Noé (talk) 15:24, 15 November 2019 (UTC)
- You're welcome. Then, consider French Wiktionary is the only Wiktionary that offer VisualEditor, for the other wiktionaries, they don't use it. So, your suggestion has to be tied with the proposal to adapt VisualEditor to Wiktionaries.
- Yes, Noé. I forgot the suitable term when I wrote. Thanks for your help. Jpgibert (talk) 14:40, 15 November 2019 (UTC)
Voting
- Support useful on Wiktionaries but also on other projects with plenty sections, such as Wikivoyage or Wikipedia. Noé (talk) 08:58, 22 November 2019 (UTC)
- Support Libcub (talk) 09:10, 22 November 2019 (UTC)
- Support Pamputt (talk) 13:50, 23 November 2019 (UTC)
- Support as proposer Jpgibert (talk) 15:55, 23 November 2019 (UTC)
- Support Lyokoï (talk) 15:25, 25 November 2019 (UTC)
- Support Liuxinyu970226 (talk) 15:45, 25 November 2019 (UTC)
- Support A garbage person (talk) 16:13, 25 November 2019 (UTC)
- Support 游魂 17:06, 25 November 2019 (UTC)
- Support Ciao • Bestoernesto • ✉ 19:43, 25 November 2019 (UTC)
- Support Peter Gröbner (talk) 10:28, 26 November 2019 (UTC)
- Support Gce (talk) 21:33, 27 November 2019 (UTC)
- Support Novak Watchmen (talk) 17:49, 2 December 2019 (UTC)
Adopt Lingua Libre Bot service as a tool
- Problem: Lingua Libre is a great service to record pronunciation of words and, now, Lexemes at Wikidata. When you record them they're uploaded to Commons and via Lingua Libre Bot they are added to the corresponding word/lexeme. But this bot is mantained by a volunteer, and it seems that sometimes it can be stopped for weeks. This service should be adopted as a WMF Tool and make it more stable and not dependant from an user disponibility.
- Who would benefit: People wanting to record pronunciations
- Proposed solution: Add it to Toolserver and run it independently.
- More comments:
- Phabricator tickets:
- Proposer: Theklan (talk) 11:01, 27 October 2019 (UTC)
Discussion
IMHO, the problem is more general. On a long-term period, LinguaLibreBot and Lingua Libre website itself has to be maintained to add more feature and to fix bugs. I think Wimedia France starts to think about this problem (Eavqwiki may comment more). Pamputt (talk) 17:20, 1 November 2019 (UTC)
Allready an grant, although the solution is different. Will use OAuth, so no bot will be needed. On the talk page, the developer writes: "the files will be transferred from LinguaLibre to Commons using an OAuth authorization". So, in the future an bot will not be used and this issue will be fixed in another way than the proposee here accounted for. (Grants have a lifetime of 12 months)--Snaevar (talk) 12:37, 11 November 2019 (UTC)
@User:Snaevar The project supported by the grant has been implemented: the recordings are automatically uploaded through OAuth on Commons as Theklan mentioned, when it used to be up to the developer to transfer them periodically from the beta version of lingualibre that didn't use OAuth. Even with OAuth though, the bots are needed to upload the recordings to specific places on other projects - not just Commons -, that's where Theklan suggests it'd be useful to have the tool internal to Wikimedia to internalise both the recording process and the "storing" process. Correct? I think that having a separate Lingua Libre website and recorder is useful because that's where contributors without a Wikimedia account can also record (using a wikimedian's account for now but hopefully not anymore in the future). It's easier to explain the use and value of audiovisual content for languages' vitality to a greater number of speakers on Lingua Libre, all the while uploading the ultimate content on Commons - as WikiTongues does for example. Wikimedians on lingualibre could then validate non Wikimedia speakers' content and upload it to Commons using OAuth and the bots applicable as they do now for their own content. But for wikimedians strictly, yes, they could do with an in-built record wizard on the projects to decrease the reliance on bots to upload 100% of recordings, and the developer maintaining them and the record wizard. Eavqwiki (talk) 11:05, 22 November 2019 (UTC)
Seems like some overlap/redundancy with my proposal here: Community Wishlist Survey 2020/Wiktionary/Fix the AddAudio script to upload audio to Commons seamlessly. I don't have strong feelings on which tool/script is the best one. —Justin (koavf)❤T☮C☺M☯ 21:00, 25 November 2019 (UTC)
Voting
- Support Noé (talk) 21:44, 20 November 2019 (UTC)
- Support MichaelSchoenitzer (talk) 23:13, 20 November 2019 (UTC)
- Support Consulnico (talk) 11:30, 21 November 2019 (UTC)
- Support --Lyokoï (talk) 11:45, 21 November 2019 (UTC)
- Support Lepticed7 (talk) 12:39, 21 November 2019 (UTC)
- Support --Rapaloux (talk) 12:51, 21 November 2019 (UTC)
- Support Like tears in rain (talk) 13:07, 21 November 2019 (UTC)