Community Wishlist Survey 2019/Wiktionary

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Wiktionary
7 proposals, 77 contributors

Go-previous.svg Wikisource  •  Admins and patrollers Go-next.svg

The survey has closed. Thanks for your participation :)
Here are the Community Wishlist Survey 2019 results!


Multiple collations per site

Edit proposal/discussion

  • 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) 12:18, 11 November 2018 (UTC)

Discussion

Voting

  • Support Support Leiem (talk) 05:35, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 11:56, 17 November 2018 (UTC)
  • Support Support Urhixidur (talk) 13:14, 17 November 2018 (UTC)
  • Support Support Noé (talk) 16:16, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:02, 18 November 2018 (UTC)
  • Support Support Psychoslave (talk) 04:01, 18 November 2018 (UTC)
  • Support Support Pamputt (talk) 21:00, 18 November 2018 (UTC)
  • Support Support My bot is barely treating a dozen languages by adding or removing defaultsort every day on the French Wiktionary, whereas we have more than 4,500 languages. JackPotte (talk) 22:09, 18 November 2018 (UTC)
  • Support Support Peter Bowman (talk) 22:34, 19 November 2018 (UTC)
  • Support Support Otourly (talk) 10:00, 20 November 2018 (UTC)
  • Support Support absolutely needed on multilingual projects like Wiktionaries to make category sorting correct and the {{DEFAULTSORT:}} keyword close to useless. — Automatik (talk) 13:04, 20 November 2018 (UTC)
  • Support Support Vulphere 13:05, 20 November 2018 (UTC)
  • Support Support Absolutely needed for a good online multilingual dictionary ! Lyokoï (talk) 14:58, 20 November 2018 (UTC)
  • Support Support Pom445 (talk) 16:34, 20 November 2018 (UTC)
  • Support Support Really needed. An additional feature would be the kind of sorting wanted: two sorts are in use in dictionaries: skipping spaces, commas, apostrophes, etc. or skipping only apostrophes, and changing characters such as ",", "-", "/" and other punctuation to a space (and skipping redundant spaces). This second way is used at least in fr.wikt, and would probably be the best one for all wiktionary readers. Lmaltier (talk) 18:39, 20 November 2018 (UTC)
  • Support Support Thibaut120094 (talk) 21:00, 20 November 2018 (UTC)
  • Support Support A good idea. We need it for the intended Konkani Wiktionary in Goa. Fredericknoronha (talk) 21:20, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 15:23, 21 November 2018 (UTC)
  • Support Support KaMan (talk) 16:53, 23 November 2018 (UTC)
  • Support Support Metaknowledge (talk) 23:37, 23 November 2018 (UTC)
  • Support Support Krokus (talk) 12:59, 25 November 2018 (UTC)
  • Support Support Erutuon (talk) 22:13, 27 November 2018 (UTC)
  • Support Support Curious (talk) 21:20, 28 November 2018 (UTC)

Additional edition interfaces and recording formats on the fly

Edit proposal/discussion

  • Problem: Current edition by newcomers and third party parsing of Wiktionaries are difficult
  • Who would benefit:
    • new contributors wishing to participate without having to learn a lot of technical skill requirements
  • Proposed solution:
    1. Offer polished forms requiring zero technical learning to edit Wiktionnaries, while keeping classical wikitext edition available for more experienced users
    2. Save on the fly articles in multiple formats, especially a LSON tree representing the parsed article structure
    3. Allow to manipulate previous entries in modules in order to transclude elements of an article in a programatic way
  • More comments: Probably most of this should be buildable with current infrastructure. Especially tpt pointed me to ContentHandler this week-end which should be useful for this purpose.
  • Phabricator tickets:
  • Proposer: Psychoslave (talk) 20:11, 11 November 2018 (UTC)

Discussion

  • Comment Comment I think it is a very good idea, but, at least in Spanish Wiktionary, I've found at least 3 ways to organize the entries (I don't know if this happens in other Wiktionaries), we must choose one before doing an interface. --Giovanni Alfredo Garciliano Diaz (talk) 17:00, 17 November 2018 (UTC)
    • Thank you @Giovanni Alfredo Garciliano Diaz: for your feedback. Links toward relevant cases (or even documentation if this is a by design choice) is welcome. The proposal didn't specified it, but the tool should of course not be enforced on communities. That's up to each community to adopt the possible outcoming project or even better, involving more in it's conception to adjust its features to meet their desire and needs. --Psychoslave (talk) 03:54, 18 November 2018 (UTC)
  • Comment Comment Proposition 1. looks very good. What is this LSON thing is proposition 2. ? And proposition 3. would complicate things for newcomers. This proposition could be explained in a clearer way (and perhaps not include several tasks at the same time) to federate more votes. — Automatik (talk) 14:53, 20 November 2018 (UTC)

Voting

  • Support Support --Giovanni Alfredo Garciliano Diaz (talk) 17:00, 17 November 2018 (UTC)
  • Support Support JogiAsad (talk) 18:00, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:01, 18 November 2018 (UTC)
  • Support Support I heartly support my own proposition, who would have expected that! Face-grin.svg --Psychoslave (talk) 03:57, 18 November 2018 (UTC)
  • Support Support Hydriz (talk) 12:32, 18 November 2018 (UTC)
  • Support Strongest possible support This would make new editors advantaged in many ways, I'm very confident this would be extremely helpful.Redactyll (talk) 19:49, 18 November 2018 (UTC)
  • Support Support Vulphere 13:07, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 15:23, 21 November 2018 (UTC)
  • Support Support Hello903hello (talk) 12:47, 26 November 2018 (UTC)
  • Support Support Filipović Zoran (talk) 19:27, 26 November 2018 (UTC)
  • Support Support We developed a form-like editor interface for wikicode in plwiktionary. It's specifically designed with our entry structure in mind: several fields (e.g. pronunciation, synonyms, etc.) per section (language entry) per page. It adds support for additional tools like searching usage examples across linked articles, retrieving the IPA and audio files from other wiktionaries... Look for the ext.gadget.editform RL module. Peter Bowman (talk) 11:45, 28 November 2018 (UTC)

Wikidata module for translations

Edit proposal/discussion

  • Problem: Currently each wiktionary maintains a list of translations for each sense (Ex.1, Ex.2, Ex.3). These translations are not connected between language versions, so the effort is repeated in each language edition.
  • Who would benefit: Wiktionary editors.
  • Proposed solution: 1) Create a tool to import existing translation boxes from wiktionaries into Wikidata. 2) Create a module that can display all the translations in each Wiktionary that chooses to use it. 3) Allow to add more translations into Wikidata from each Wiktionary, so that the contributions are not repeated.
  • More comments:
  • Phabricator tickets:
  • Proposer: Micru (talk) 14:44, 9 November 2018 (UTC)

Discussion

@Micru: Would this be solved by https://www.wikidata.org/wiki/Wikidata:Lexicographical_data and https://www.wikidata.org/wiki/Wikidata:Wiktionary ? --AKlapper (WMF) (talk) 20:58, 9 November 2018 (UTC)

@AKlapper (WMF): That is part of the solution (the data would be stored in Wikidata as Lexicographical data), however as mentioned we need a way to import the translation lists from any Wiktionary into Wikidata and then a way to display it on any wiktionary who chooses to.--Micru (talk) 21:15, 9 November 2018 (UTC)

In translation lists, plenty links are in red, and Wikidata do not accept red links, so it could be problematic. Also, the nomenclature of definitions differ from one language to another, there is not script mapping from one language to another. To be clear, A Spanish word will have x definitions in English Wiktionary but y definitions in French Wiktionary, because each definition refers to a culture. So, how do you imagine those can be mapped? Noé (talk) 10:10, 10 November 2018 (UTC)

@Noé: To import a translation list into Wikidata we need a Q-item representing the sense, and as many lexeme items (L-items) as words connected to that item. When there is a redlink it can be just a label in the Q-item in that language, without the need to create a lexeme. The nomenclature of definitions differ from one language to another, however the translation lists tend to be very similar and that is what matters. Normally the only difference between translation lists is that some language versions are more complete than others.--Micru (talk) 11:41, 10 November 2018 (UTC)
The importation of a translation list from CC BY-SA Wiktionary to CC0 Wikidata imply the consideration of translation list as not covered by the licence and free of reuse without keeping the same licence (SA means share alike). This position is not consensual and I personally disapprove. If I understood Wikidata lexicographical data model, Q-item is for concepts, not for meanings. I think it had to be connected with S-item rather than Q-item. I am not sure to understand the solution you suggested for redlinks. In my experience, translations lists doesn't tend to be very similar. The mapping of senses to the reality is different from one language to another, so translation lists are not similar. You can choose to not deal with complex cases and focus on simple cases in a first step, but I think it is not very effective to oversimplify the complexity of translation -- Noé (talk) 10:25, 13 November 2018 (UTC)
Yes! Let's focus on simple cases as a first step!--Micru (talk) 16:21, 17 November 2018 (UTC)

I agree with @Noé: that translation lists from Wiktionaries can't be imported into a CC0 project. Thus said, any tool that might help to coordinate our word relationship lists between different linguistic vesion would be very welcome. So a simple solution that might meet both @Micru: proposition and Noé feedback is a Wikibase designed to store this lists while keeping exact record of license and origin (which Wiktionary version and page). That is, one should not only import the list of translation proposed for joy in the English Wiktionnary and joie in the French one, but also the list of given translations for joie' in the English version and for joy in the French one. No automatic merge of this lists should be performed, but dedicated tools to compare matching lists and possibly manually transfer items from one list to the other would be warmely welcome. Also having a way to query directly this lists from the wiktionnaries would be a nice plus. Psychoslave (talk) 03:38, 18 November 2018 (UTC)

There are cases where someone seems to have manually used a reciprocal translation to write a translation, and it doesn't really work well. Languages don't always map like that. "word1, language A" can be the closest translation of "word1 in language B", but "word2 in language B" might be closer to the meaning of "word1, language A". HLHJ (talk) 06:59, 18 November 2018 (UTC)

Voting

  • Support Support Libcub (talk) 11:52, 17 November 2018 (UTC)
  • Support Support Urhixidur (talk) 13:12, 17 November 2018 (UTC)
  • Support Support Micru (talk) 16:20, 17 November 2018 (UTC)
  • Support Support Giovanni Alfredo Garciliano Diaz (talk) 17:11, 17 November 2018 (UTC)
  • Support Support Much needed such tools... JogiAsad (talk) 17:57, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:01, 18 November 2018 (UTC)
  • Support Support, provided it would meet the feedback given by Noé and myself. If the intention is to merge that into Wikidata within a spacename not respect the license of the Wiktionnaries, I would however be strongly opposed. Psychoslave (talk) 03:38, 18 November 2018 (UTC)
  • Oppose Oppose as the existing structure reflects the nature of the information (see discussion), and there are already cross-language links. HLHJ (talk) 06:59, 18 November 2018 (UTC)
  • Support Support Sebastian Wallroth (talk) 13:18, 18 November 2018 (UTC)
  • Support Support -Xbony2 (talk) 16:39, 19 November 2018 (UTC)
  • Oppose Oppose It sounds easy only in theory. In realty, it sounds more than impossible (see discussion). And simple worlds like "tree" are complex cases. Otourly (talk) 10:16, 20 November 2018 (UTC)
  • Oppose Oppose Not a good idea, only human must be to work on translation, an automatic system will generate more errors than a person. Lyokoï (talk) 15:02, 20 November 2018 (UTC)
  • Oppose Oppose Same reasons. Lmaltier (talk) 18:28, 20 November 2018 (UTC)
  • Support Support Thank you for the edit Nhatminh01 (talk) 11:20, 21 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 15:24, 21 November 2018 (UTC)
  • Support Support looks reasonable :) Gryllida 08:15, 23 November 2018 (UTC)
  • Support Support Sahaquiel9102 (talk) 17:39, 23 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 03:07, 26 November 2018 (UTC)
  • Support Support TheIgel69 (talk) 11:08, 27 November 2018 (UTC)
  • Support Support Merhad77 (talk) 14:02, 27 November 2018 (UTC)
  • Support Support Peter Bowman (talk) 11:41, 28 November 2018 (UTC)
  • Oppose Oppose I agree with Noé, HLHJ and Lyokoï. A word in a certain language doesn't have the exact same meaning in another language. If you dump everything together into one big pile of translations, you won't be able to distinguish between much and many, between ladder and staircase, between actor and actress, between tall and high, between to look and to watch, etc. I'd also like to note that some Wiktionaries have a huge amount incorrect translations (e.g. mg.wikt); blindly importing from those Wiktionaries will pollute the whole database in Wikidata. -- Curious (talk) 21:13, 28 November 2018 (UTC)

Custom list for language learner

Edit proposal/discussion

  • Problem: A student may wants to create wordlists to memorize a new language and then organizes the list by themes (animals, plants), functional categories (emotional verbs, action verbs, nouns) or whatsoever. Wiktionaries have the content for language learners but do not provide any tool for this need and people use instead other websites.
  • Who would benefit: Students learning a new language, contributors to have a to-do list or a list of beloved words, Wikibooks to have an interface with Wiktionary.
  • Proposed solution: Creating a Javascript or a core feature in MediaWiki to record a page into a personal space with an option for subcategorisation that include the link directly under a subsection (i.e. pick a word and add it to verb, colors, animals, new category section in the Custom list page).
We can imagine options to easily edit the Custom List such as:
  • a field to add a word in a category
  • an option to delete a word without editing the whole page
  • a rapid way to reorder sections and words
This tool may be included in Wiktionary or be apart, in a lighter interface, to share the list created everyone.

Discussion

  • 🚩 Agree. I have desired something like this for a while, a great idea.Sigehelmus (talk) 00:42, 4 November 2018 (UTC)
  • Comment: fairly sure mention was made in the previous years to support exporting in structured format, for example for Anki de, fr, zh, to allow shared lists. - Amgine 21:19, 7 November 2018 (UTC)
  • Could be also used by Wikiversities. Otourly (talk) 10:03, 20 November 2018 (UTC)

Voting

  • Support Support Libcub (talk) 11:52, 17 November 2018 (UTC)
  • Support Support Noé (talk) 16:16, 17 November 2018 (UTC)
  • Support Support This should also be implemented on Sindhi Wiktionary. JogiAsad (talk) 18:01, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:02, 18 November 2018 (UTC)
  • Support Support This would be a very useful toolk. The proposition make clear the general purpose, but it also immediately poped more specific use cases like events aimaing at helping migrants to learn French where our current Wiktionnary tooling is unsiffisent to generate quickly useful material. @Sophiedidacressources: might be especially interested in this proposal. --Psychoslave (talk) 03:46, 18 November 2018 (UTC)
  • Support Support Pamputt (talk) 21:05, 18 November 2018 (UTC)
  • Support Support DaraDaraDara (talk) 09:38, 19 November 2018 (UTC)
  • Support Support 4nn1l2 (talk) 05:51, 20 November 2018 (UTC)
  • Support Support Otourly (talk) 10:03, 20 November 2018 (UTC)
  • Support Support Vulphere 13:08, 20 November 2018 (UTC)
  • Support Support useful gadget especially for readers Automatik (talk) 14:55, 20 November 2018 (UTC)
  • Support Support Lyokoï (talk) 14:56, 20 November 2018 (UTC)
  • Support Support Pom445 (talk) 16:35, 20 November 2018 (UTC)
  • Support Support Acer11 (talk) 07:33, 21 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 15:25, 21 November 2018 (UTC)
  • Support Support Very useful tool. Gce (talk) 17:16, 21 November 2018 (UTC)
  • Support Support Teodor (talkcontributions) 20:32, 22 November 2018 (UTC)
  • Support Support yay wonderful :) Gryllida 08:16, 23 November 2018 (UTC)
  • Support Support By erdo can • TLK 09:03, 25 November 2018 (UTC)
  • Support Support Krokus (talk) 12:49, 25 November 2018 (UTC)
  • Support Support Merhad77 (talk) 14:01, 27 November 2018 (UTC)
  • Support Support Grawiton (talk) 20:33, 27 November 2018 (UTC)
  • Support Support Daniel Case (talk) 05:05, 29 November 2018 (UTC)
  • Support Support Donare Vitae (talk) 23:46, 29 November 2018 (UTC)

Context-dependent sort key

Edit proposal/discussion

  • Problem: In most Wiktionary projects, words of different languages share a page if their spellings are identical. Currently, the magic word DEFAULTSORT works for an entire page, which means we cannot define a default sort key for each language in the same page. That is an issue especially for Chinese, Japanese and Korean (hanja). They share characters but their sort keys are totally different (radicals or pinyin for Chinese, kana for Japanese, hangeul for Korean). If it is allowed to define a default sort key for each section, it will be much easier to correctly categorize pages.
  • Who would benefit: Editors of Wiktionary, especially those who edit Chinese and Japanese entries.
  • Proposed solution: Introduction of a new magic word, say, SECTIONSORT, that works for all categories after it up to the next usage of the same magic word. SECTIONSORT should override DEFAULTSORT if both are defined. The use of SECTIONSORT without a sort key should clear the previous sort key (and should not define an empty sort key).
  • More comments: see Community Wishlist Survey 2017/Wiktionary/Context-dependent sort key for a discussion in 2017. It is still a problem.
  • Phabricator tickets: phab:T183747
  • Proposer: TAKASUGI Shinji (talk) 12:19, 11 November 2018 (UTC)

Discussion

How it will be visible in category? Sections can't be added to category. --Wargo (talk) 21:48, 16 November 2018 (UTC)

Currently, one adds a sort key to an entire page. The goal of this proposal is to allow more than on sort key per page: one per section; e.g. one sort key for the Chinese section of , one sort key for the Japanese section of the same entry, etc. This is because a same word may not be sorted the same way in different languages, and Wiktionaries often have entries from multiple languages in the same page, as a page corresponds to a specific spelling (which may occurs in multiple languages). — Automatik (talk) 14:06, 20 November 2018 (UTC)
Notifying WargoAutomatik (talk) 14:07, 20 November 2018 (UTC)

See also my somewhat related proposal (I keep missing the deadline) Community Wishlist Survey 2017/Archive/Allow multiple entries within each category. Urhixidur (talk) 13:30, 17 November 2018 (UTC)

Voting

  • Support Support Libcub (talk) 11:55, 17 November 2018 (UTC)
  • Support Support Urhixidur (talk) 13:15, 17 November 2018 (UTC)
  • Support Support Noé (talk) 16:16, 17 November 2018 (UTC)
  • Support Support Support JogiAsad (talk) 17:44, 17 November 2018 (UTC)
  • Support Support Sounds useful for many types of info besides just words. Wikicat (talk) 20:01, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:01, 18 November 2018 (UTC)
  • Support Support Psychoslave (talk) 03:49, 18 November 2018 (UTC)
  • Support Support Pamputt (talk) 21:02, 18 November 2018 (UTC)
  • Support Support DaraDaraDara (talk) 09:39, 19 November 2018 (UTC)
  • Support Support Otourly (talk) 10:05, 20 November 2018 (UTC)
  • Support Support Vulphere 13:03, 20 November 2018 (UTC)
  • Support Support This solution is necessary to allow per-language manual sort keys when an algorithm may not determine the correct sort key by itself (which is the case for Japanese and Chinese, according to Shinji). Automatik (talk) 13:40, 20 November 2018 (UTC)
  • Support Support Thibaut120094 (talk) 14:17, 20 November 2018 (UTC)
  • Support Support Unsui (talk) 14:48, 20 November 2018 (UTC)
  • Support Support Lyokoï (talk) 14:59, 20 November 2018 (UTC)
  • Support Support Pom445 (talk) 16:34, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 15:25, 21 November 2018 (UTC)
  • Support Support Nuevo Paso (talk) 07:36, 24 November 2018 (UTC)
  • Support Support A garbage person (talk) 17:25, 27 November 2018 (UTC)
  • Support Support Peter Bowman (talk) 11:40, 28 November 2018 (UTC)
  • Support Support Curious (talk) 21:18, 28 November 2018 (UTC)

Insert attestation exploiting Wikisource as a corpus

Edit proposal/discussion

  • Problem: Wiktionaries definitions relies on attestations, sentences from corpora illustrating the usages and meanings of a word. Wikisource is an excellent corpus for Wiktionaries 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 patient 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.
  • Proposed solution: This feature is inspired by Insert media but targeting Wikisource instead of Wikimedia Commons. So, instead of an instant search offering pictures, Insert attestation would display a list of sentences from Wikisource that include the targeted sequence of characters (no meaning requirement). That's a snippets of results that you can choose from. An editor would just grab a sentence with a single click and it will be added with the adequate sources. The feature would copy the sentence (no transclusion) and the source of the sentence (with the information of the page in the original manuscript optimally). 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 a second step of development. This idea was suggested last year and supported by 32 people, a draft was suggested the year before with 19 supports and this idea was coined first in a MediaWiki discussion.
  • Proposer: Noé (talk) 08:57, 30 October 2018 (UTC)

Discussion

The problem of few quotaions should be too in archaicity of texts - wikisource texts are mostly old, by authors which died before 1948. Proposed solution should not be limited to wikitionary↔wikisource. The same use (sentence from wikisource) shoud be useful for wikipedia or wikiquote too. JAn Dudík (talk) 12:30, 30 October 2018 (UTC)

Wiktionary not only describe the language as it is in use nowadays, texts can illustrate archaic meanings. And some texts are published recently directly in a compatible licence. Similarly as Insert media, this tool would be accessible in Wikipedia and other projects as well. I am wondering how it can be use elsewhere, as I am mostly contributing to Wiktionary and Wikisource, so you are welcome if you have some idea to share Face-smile.svg Noé (talk) 18:50, 30 October 2018 (UTC)
  • The GitHub project wcorpus extracts data from Russian Wikisource and transforms data to the database format more convenient to search text in corpus. At this moment there is no user interface in wcorpus, it can be used only by programmers. I hope that this program can be used to create something more perfect. Welcome to read our paper about research based on Wikisource and Wiktionary data. -- Andrew Krizhanovsky (talk) 15:33, 4 November 2018 (UTC)
  • This tool should allow users to choose also the languages of the Wikisource they want. For example I need quotations from Italian Wikisource for the French Wiktionary. Otourly (talk) 10:10, 20 November 2018 (UTC)

Voting

Translation editor as an extension

Edit proposal/discussion

  • Problem: One popular way to contribute to the Wiktionaries content is adding translation. Since editing Wiktionary code is not really user-friendly, javascript gadgets have been developed locally to simplify the addition of translation without the need to modify the wikicode. Actually, Recent Changes are showing mostly additions of translations by IP thanks to those gadgets. French Wiktionary uses Gadget-translation editor.js based on a Swedish Wiktionary gadget, Gadget-translation editor.js itself based on an English Wiktionary gadget, editor.js. On French Wiktionary, a recent evaluation made by Automatik and published on September Actualités showed that between July 2014 and September 2018, 234,989 translations were added thanks to this gadget. This gadget is a very important feature for Wiktionaries and could be improved and integrated with a modern design. This gadget should also work on mobile.
  • Who would benefit: Every person adding translations to Wiktionaries.
  • Proposed solution: A module could be developed to support this feature, improve the design to make it closer to the standard editor and include it in all Wiktionaries.
  • More comments: This feature also checks if the page with a same title exists in the version of the language added (for example, if you add a Spanish translation in English Wiktionary, the gadget checks in Spanish Wiktionary). Then a proper parameter is added to make a blue or a red link. This part may use Cognate module to check rather than a request.
  • Phabricator tickets:
  • Proposer: Noé (talk) 10:05, 10 November 2018 (UTC)

Discussion

  • Is it possible to improve the tool to allow adding translation during the edition of the wikicode? When I create articles, I must save the article to be able to add translation with the tool. Jpgibert (talk) 19:07, 18 November 2018 (UTC)
    Great suggestion! Merci ! Of course, it could be even better if this tool can work also during a classic edition, but I am not sure it could be done, as the two works very differently, but let's keep this idea as a goal Face-smile.svg Noé (talk) 06:51, 19 November 2018 (UTC)

Voting

  • Support Support Consulnico (talk) 23:55, 16 November 2018 (UTC)
  • Support Support Urhixidur (talk) 13:12, 17 November 2018 (UTC)
  • Support Support Giovanni Alfredo Garciliano Diaz (talk) 17:11, 17 November 2018 (UTC)
  • Support Support JogiAsad (talk) 18:03, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:02, 18 November 2018 (UTC)
  • Support Support Psychoslave (talk) 03:50, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 11:56, 18 November 2018 (UTC)
  • Support Support Jpgibert (talk) 19:07, 18 November 2018 (UTC)
  • Support Support Pamputt (talk) 21:01, 18 November 2018 (UTC)
  • Support Support DaraDaraDara (talk) 09:40, 19 November 2018 (UTC)
  • Support Support We strongly need this. Otourly (talk) 10:05, 20 November 2018 (UTC)
  • Support Support don't know if an extension is the best way to implement that, but that would be definitely useful. Automatik (talk) 12:54, 20 November 2018 (UTC)
  • Support Support Vulphere 13:11, 20 November 2018 (UTC)
  • Support Support Unsui (talk) 14:51, 20 November 2018 (UTC)
  • Support Support Lyokoï (talk) 14:55, 20 November 2018 (UTC)
  • Support Support Pom445 (talk) 16:35, 20 November 2018 (UTC)
  • Support Support Lmaltier (talk) 18:25, 20 November 2018 (UTC)
  • Support Support Acer11 (talk) 07:37, 21 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 15:23, 21 November 2018 (UTC)
  • Support Support Every proposal that will make easier to everyone the contribution deserves my support. Gce (talk) 17:23, 21 November 2018 (UTC)
  • Support Support عبد الإله صديقي (talk) 20:11, 22 November 2018 (UTC)
  • Support Support Teodor (talkcontributions) 20:38, 22 November 2018 (UTC)
  • Support Support great idea, i would start to contribute to wiktionary if this was used :) and maybe also extended to not only add translations but also add meanings, add etymology, etc Gryllida 07:19, 23 November 2018 (UTC)
  • Support Support Adithyak1997 (talk) 10:23, 24 November 2018 (UTC)
  • Support Support Arbnos (talk) 23:28, 24 November 2018 (UTC)
  • Support Support By erdo can • TLK 09:04, 25 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 03:07, 26 November 2018 (UTC)
  • Support Support Nemo 22:24, 27 November 2018 (UTC)
  • Support Support BTW plwiktionary uses its own translation-editor.js, but a similar tool would be certainly helpful on eswiktionary. Peter Bowman (talk) 11:41, 28 November 2018 (UTC)
  • Support Support Curious (talk) 21:23, 28 November 2018 (UTC)
  • Support Support Daniel Case (talk) 05:04, 29 November 2018 (UTC)
  • Support Support Donare Vitae (talk) 23:48, 29 November 2018 (UTC)
  • Support Support Edhral 07:28, 30 November 2018 (UTC)