Requests for comment/Adopt OmegaWiki

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

OmegaWiki is a formal multilingual dictionary based on the MediaWiki extension WikiLexicalData.

Proposal: That the Wikimedia Foundation approve adopting the OmegaWiki project and allocate resources to support any technical aspects of migrating this project to Wikimedia servers. The project would continue to complement the work done on Wiktionaries, and to provide potential models for a Wikidata-backed multilingual dictionary.

See the page OmegaWiki for details on the proposal.

Feel free to discuss the proposal by editing this page.

Discussion[edit]

  • I would like to add that I am currently the only one who actively takes care of the server (e.g. editing Localsettings, updating MediaWiki, etc.), and who does some programming (repairing bugs and adding new features). I fear that without me, there is no OmegaWiki anymore (a little dramatic, I know...). Having it adopted by the WMF would offer some security to its future. --Kip (talk) 12:41, 14 February 2013 (UTC)
  • I support migrating this to Wikimedia servers, marked as a part of Wikidata.  ono  23:51, 24 February 2013 (UTC)
    Wikidata uses the WikiBase extension, whereas OmegaWiki uses WikiLexicalData, which is now maintained by Kipmaster. The projects have different goals, with Wikidata being more aligned with Wikipedia and OmegaWiki with Wiktionary. If you want OmegaWiki as another namespace or subdomain of Wikidata, that may be possible, but merging them completely (database and all) would require more discussion. πr2 (t • c) 00:25, 25 February 2013 (UTC)
    As it is, OmegaWiki and Wikidata can share a one on one relation. As it is the concepts known in OmegaWiki allow access to Wikipedia through the existing Wikidata link from languages Wikipedia does not support.
As it is Commons pictures can be associated with concepts and this does allow for seaching for pictures in other languages. The principles are working it just needs an interface.
So YES, by all means discuss the issues. But do realise that a lot of thinking and hard work by great people including Eloquence went into this. GerardM (talk) 12:55, 27 February 2013 (UTC)

Supporters[edit]

Please put you name below to indicate your support and interest in OmegaWiki, and having it hosted by Wikimedia. It is not a vote at this time, but just to get an idea of how many people would be interested.

  1. --Kip (talk) 10:47, 11 February 2013 (UTC)
  2. Rinaku (t · c) 19:53, 11 February 2013 (UTC)
  3. --İnfoCan (talk) 11:37, 13 February 2013 (UTC)
  4.  Klaas ‌ V 12:52, 13 February 2013 (UTC) (User:Patio @OmegaWiki)
  5. +1, but not an editor on OmegaWiki. πr2 (t • c) 12:27, 14 February 2013 (UTC)
    • you don't have to be an editor on OmegaWiki, we have had our vote there already ;-) --Kip (talk) 12:42, 14 February 2013 (UTC)
  6. --Tosca (talk) 17:48, 16 February 2013 (UTC)
  7. Conny (talk) 22:18, 16 February 2013 (UTC).
  8. Malafaya (talk) 15:05, 18 February 2013 (UTC)
  9. Ascánder (talk) 16:41, 19 February 2013 (UTC)
  10. Kelson (talk) 10:55, 20 February 2013 (UTC)
  11. Veeven (talk) 13:41, 20 February 2013 (UTC)
  12. Makes sense and the proposal seems well thought-of. Benefits are clear for both sides. Waldir (talk) 14:50, 20 February 2013 (UTC)
  13. Alhen (talk) 13:17, 24 February 2013 (UTC)
  14. Not really involved at this stage, but it has aspects to which I would like to contribute. · · · Peter (Southwood) (talk): 15:13, 24 February 2013 (UTC)
  15. If they want to be adopted then this sounds sensible, they certainly seem to be in scope. WereSpielChequers (talk) 18:58, 24 February 2013 (UTC)
  16. Yes, please. I have an account there and I am omega editor but I did not start contributing, yet. But I am really interested in hosting OmegaWiki by the Wikimedia Foundation. Vogone talk 20:56, 24 February 2013 (UTC)
  17. --PatrickLemke (talk) 21:34, 24 February 2013 (UTC)
  18. --Steinsplitter (talk) 21:56, 24 February 2013 (UTC)
  19. Alan Lorenzo (talk) 22:02, 24 February 2013 (UTC)
  20. What are we waiting for? I WANT IT NOW! Go, go, go! ;) --Psychoslave (talk) 23:04, 24 February 2013 (UTC)
  21. This, that and the other (talk) 06:29, 25 February 2013 (UTC)
  22. Cquoi (talk) 08:31, 25 February 2013 (UTC)
  23. The project does everything which would have been required not to hate wiktionary from the start. It is as useful as wiktionary is pointless. :-/ --grin 09:49, 25 February 2013 (UTC)
  24. --Manuel Schneider(bla) (+/-) 13:00, 25 February 2013 (UTC) support, OmegaWiki is a lovely ressource. I also opt for discussing how we could merge it with Wikidata and Wiktionary.
  25. Support: It should start as an incubated project. Once it is working, each Wiktionary community should vote whether to move or not. Some semi-automated transition tools could be created to ease a possible transition.--Micru (talk) 13:16, 25 February 2013 (UTC)
  26. It will be helpful to both WMF and OW.--Nizil Shah (talk) 22:06, 25 February 2013 (UTC)
  27. Yes check.svg Strongly Support, it would be very helpful and also very useful, if the Wikimedia Foundation can have them both: the “OmegaWiki” and the “Wiktionary”.
    That's why I strongly agree the Wikimedia Foundation could take over and adopt the “OmegaWiki”, in order to make it as a project under the Wikimedia Foundation.
    Thank-You Very Much. ~~ Erwin Mulialim(talk) 04:05, 26 February 2013 (UTC).
  28. Yes check.svg Support heck yes. Fox Wilson (talk) 23:25, 26 February 2013 (UTC)
  29. Yes check.svg Support – Ypnypn (talk) 00:26, 27 February 2013 (UTC)
  30. Rahmanuddin(రహ్మానుద్దీన్ (talk) 09:38, 27 February 2013 (UTC))
  31. Yes check.svg Support--俺はバカ (talk) 12:07, 27 February 2013 (UTC)
  32. Yes check.svg Support - GerardM (talk) 12:51, 27 February 2013 (UTC)
  33. Kiran Kumar Kamsetti(కిరణ్ (talk) 08:31, 27 February 2013 (UTC))
  34. SupportΛΧΣ21 06:19, 28 February 2013 (UTC)
  35. It's good time for that! As far as I know, OmegaWiki is one of early predecessors of Wikidata idea, created about 10 years ago. We can't let OmegaWiki die. WMF should adopt OmegaWiki, combine forces with successful Wikidata and Wiktionary and get synergistic effect for world human knowledge. --TarzanASG (talk) 16:18, 28 February 2013 (UTC)
  36. Riley Huntley (talk) 07:45, 1 March 2013 (UTC)
  37. Mutually beneficial, seems to be a positive acquisition, if one can call it that. NativeForeigner (talk) 23:25, 1 March 2013 (UTC)
  38. Yes check.svg Suport Sure I suport and I hope that Wikicionary merge with OmegaWiki. - Sarilho1 (talk) 19:42, 2 March 2013 (UTC)
  39. Yes check.svg Support --Oldak Quill 01:14, 3 March 2013 (UTC)
  40. Yes check.svg Support But I would prefer to merge OmegaWiki/Wikidata/Wiktionaries into the same project. --Netol (talk) 02:11, 5 March 2013 (UTC)
  41. Pharos (talk) 06:16, 5 March 2013 (UTC)
  42. Yes check.svg Support 78.50.39.219 09:19, 6 March 2013 (UTC)
  43. Support. I'm not very familiar with OmegaWiki, but I believe that it would be a win-win to bring it under the WMF banner. WikiPuppies bark dig 22:33, 6 March 2013 (UTC)
  44. Yes check.svg Support The relation to Wiktionary is similar to Wikipedia/Wikidata. As a lot of features already have been developed it seems to be a good base, instead of developing it from scratch (as an extension on Wikidata).
  45. About time, though it's an old site using "Wikidata take 1", and it's going to take some work to get it into some sort of usable shape. ;-) --Kim Bruning (talk) 09:38, 8 March 2013 (UTC)
    Currently I am introducing more and more Ajax in its code to make it more "modern" and more responsive. But yes, there is still a lot to do... --Kip (talk) 09:47, 8 March 2013 (UTC)
  46. Filceolaire (talk) 15:39, 10 March 2013 (UTC)
  47. Yes check.svg Support I hope that Wikicionary merge with OmegaWiki. - --Massimop (talk) 16:06, 11 March 2013 (UTC)
  48. Yes check.svg Support A unified database of the world's languages is a terrific idea. Any technical issues should be resolved through the normal discussion and consensus process after the project is adopted.--ArnoldReinhold (talk) 16:11, 11 March 2013 (UTC)
  49. Yes check.svg Support Silver hr (talk) 21:10, 11 March 2013 (UTC)
  50. I support the idea of it, but I think it should be merged into Wiktionary if possible instead of creating a separate project. Wiktionarians in particular would need to support the proposal. Cbrown1023 talk 21:22, 11 March 2013 (UTC)
  51. Strong Support Wiktionaries are useful for their own language, since they can explain more about the etymology of the word, they can also present idioms and stuff alike that are not translatable. The words in other languages should be located on a single project, i.e. OmegaWiki. Amqui (talk) 23:27, 11 March 2013 (UTC)
    • No, words of other languages are addressed the same way as words of the hme language: they get definitions, usage notes, pronunciation notes, etymologies, etc. Information is duplicated across wiktionaries, true, but it's described in different languages, just like Wikipedia information is often duplicated but in different languages. This duplication is required. Lmaltier (talk) 20:51, 13 March 2013 (UTC)
      • 99,8 % (and I'm generous) of entries in another language contain only translations. Even that, having OmegaWiki doesn't refrain Wiktionaries to include words in other languages. But takes me for example, I like to add words in languages that don't have a Wiktionary (mainly Native American languages), I'm always wondering which Wiktionary to choose, why would I add the same thing on English, French, etc. Wiktionaries, it's just discourage me of adding those words. OmegaWiki serves a different purpose. Amqui (talk) 01:33, 14 March 2013 (UTC)
        • You propose to drop the principle which makes wiktionaries so original and so powerful. In many cases, bots can be used to copy information between wiktionaries. But this process is always controlled by people knowing the language, there is a human control, and this makes the difference. Lmaltier (talk) 21:43, 21 March 2013 (UTC)
  52. Yes check.svg Support Miguel2706 (talk) 22:23, 20 March 2013 (UTC)
  53. Yes check.svg Support It Is Me Here t / c 15:08, 22 March 2013 (UTC)
  54. Yes check.svg Support --Ushau97 talk 12:05, 24 March 2013 (UTC)
  55. Yes check.svg Support --TheMillionRabbit 03:02, 26 March 2013 (UTC)
  56. Yes check.svg Support --Frank C. Müller (talk) 14:46, 27 March 2013 (UTC)
  57. Yes check.svg Support --rɛg (talk) 12:04, 28 March 2013 (UTC)
  58. Yes check.svg Support --Ort43v (talk) 08:09, 4 April 2013 (UTC)
  59. Yes check.svg Support --benjozork --Benjozork (talk) 22:32, 10 April 2013 (UTC)
  60. Yes check.svg Support -- DerFussi 19:58, 15 April 2013 (UTC)
  61. Yes check.svg Support -- Hiong3-eng5 (talk) 05:18, 16 April 2013 (UTC)
  62. Support Support With the cavecat that Omegawiki would be integrated into Wikidata.--Snaevar (talk) 17:09, 24 April 2013 (UTC)
    Which may or may not ever be possible. – Ypnypn (talk) 17:24, 24 April 2013 (UTC)
  63. Yes check.svg Support Quiddity (talk) 06:11, 1 May 2013 (UTC)
  64. Yes check.svg SupportMcDutchie (talk) 14:14, 18 May 2013 (UTC)
  65. Yes check.svg Support Strongly. Witionarys work great for larger languages and these should certainly be kept. However many of the Wiktionaries for small languages and incubator Wiktionaries are stuggling, and some are a real mess - which disheartens contributors. I know as I have tried to contribute to both the Tibetan and Dzongkha incubator Wiktionary - but to get a critical mass of contibutors - let alone maintainers is almost impossible - and Tibetan and Dzongkha are relatively large languages compared to some. I've found it much easier to conribute for these languages through OmegaWiki which keeps things ordered very well. Sure there are limitations and problems - but these could be solved. (And some of the problems people perceive actually aren't there.) I also feel that it might make good sense to merge the WikiLang proposal with this as well since a large part of documenting languages involes documenting the vocabulary and concepts. - CFynn (talk) 06:29, 22 May 2013 (UTC)
  66. Yes check.svg Support (in spanish because i don't speak english ok?) Es un desperdicio de recursos los wiktionarys, usando la información de wikidata se pueden crear diccionarios mucho mas eficaces (en tiempo de trabajo de los usuarios de cualquier idioma) y sin tantas subjetividades en las definiciones, se deja bien en claro a que se refiere cada uno con cada expresión, me gustaría leer la opinión de alguna persona experta en el tema, como algún lingüista para saber cual es la mejor propuesta y adoptarla por mas que se haya trabajado mucho o no en otra.--Esceptic0 (talk) 22:05, 30 May 2013 (UTC)
  67. Yes check.svg Support--U5K0 (talk) 16:08, 9 June 2013 (UTC)
  68. Yes check.svg Support I support, as a general matter, the principle that Wikimedia should support any free-licensed text that is legal and submitted in good faith. --HectorMoffet (talk) 07:27, 17 June 2013 (UTC)
  69. Currently, Wikidata serves only Wikipedia links. I believe that OmegaWiki should serve as a Wikidata for Wiktionaries, which actually makes more sense (and is more useful) than Wikidata (or is that just me?). The url ought to be wikt.wikidata.org or something similar, so that Wikidatists can contribute more easily there. I would also support Wikidata supporting the other projects, like Wikibooks, Wikiversity...But Wiktionary is in most need of Wikidata.--Seonookim (talk) 06:22, 30 June 2013 (UTC)
  70. Yes check.svg Support Reduces editing work across the different wiktionaries. --Shibo77 18:10, 2 July 2013 (UTC)
  71. Yes check.svg Support I think it also could substitute the Wiktionaries, but it's better to hold biggest Wiktionary(ies, if any in addition to en.wikt). I think we will have to change the name of the project, because the current means nothing encyclopedic. --Tn4196 (talk) 05:38, 14 September 2013 (UTC)
  72. Yes check.svg Support for the merge with Wikidata — Ivadon (talk) 16:12, 14 September 2013 (UTC)
  73. Yes check.svg Support because it should have been within the Wikimedia Foundation's projects from the beginning and btw. for many less resourced languages it is right now the only place to go in order to be able to easily reuse the data for other scopes (e.g. spell checkers, Apertium etc.) - work once use multiple times --Sabine (talk) 05:27, 19 September 2013 (UTC)
  74. Support Support per proposal. --Ricordisamoa 15:25, 25 November 2013 (UTC)

Opponents[edit]

Please write below arguments why you think that adopting OmegaWiki as a WMF project would not be a good idea.

Against the idea of an all-in-one dictionary, prefer keeping separate Wiktionaries[edit]

  1. in my opinion this is not relevant. You just split up forces. Simply improve the existing Wiktionarys! If your contribution is reasonable it will stay there!--92.201.151.62 16:30, 27 February 2013 (UTC)
    As I see it, forces are already split between 170 Wiktionaries. OmegaWiki is an attempt to unite the forces. --Kip (talk) 16:54, 27 February 2013 (UTC)
    It would be hard work to adopt Wiktionaries to even use WikiData, which is not much of an improvement. I doubt that the idea of improving leads to anything but wasted labor. Purodha Blissenbach (talk) 10:12, 6 March 2013 (UTC)
    It seems that this proposal is trying to fix the problems wiktionary has. While you might say 'simply improve the existing wikitionarys!' if the system itself is faulty then it needs to be fixed, yes?
I think this would be great particularly for smaller and minority languages which struggle to get enough ongoing contributions for a Wikitionary. It is much easier for these with the OmegaWiki structure. Wiktionaries work well for larger languages with many active contributors - and there is no need to abolish or merge those (which isn't proposed anyway). Sure there are many improvements that could be made to OmegaWiki and its stucture but these can be made and would probably be much easier if it was adopted by WMF. CFynn (talk) 06:35, 22 May 2013 (UTC)
  1. Strongly oppose. Wiktionaries are a great success, OmegaWiki is a total failure (just have a look at Alexa figures and compare them!), for many reasons, the main ones being 1. principles of the project cannot be understood by normal readers. 2. this is a single project, leading to English as the discussion language. This actually excludes all contributors uneasy with English. Commons is in the same case, but the need for discussion is much lower, and this is therefore much more acceptable. In any case, Wiktionaries must be kept, OmegaWiki cannot be used instead. Lmaltier (talk) 20:37, 13 March 2013 (UTC)
    This is not to use OmegaWiki instead of Wiktionaries, but beside it. The two projects serve a different purpose. Wiktionaries are indeed a success and I contribute to it, but they are really not practical to use to find translations since the interwikis points to the word in the same language but on a different language Wiktionary (even Wikipedia is more useful to find translation). The translations section on entries on Wiktionaries are very hard to maintain, every time we add a translation on a page, we would need to add it to every other Wiktionaries for it to be complete. Maybe Wikidata could be use so translation sections are kept on a central location to be used by all Wiktionaries... Amqui (talk) 01:39, 14 March 2013 (UTC)
    Really? I am afraid that the ultimate objective of proponents is to get rid of wiktionaries by language (see the comment about uniting forces above). This was the objective of OmegaWiki, and it failed. Lmaltier (talk) 21:53, 21 March 2013 (UTC)
    Only the English and French Wiktionaries are a great success. The 168 other Wiktionaries not so much. --Kip (talk) 09:49, 14 March 2013 (UTC)
    @Lmaltier: Other projects such as Commons, Wikidata, Meta-Wikimedia, and Wikispecies, are all multilingual, and seem to work OK. --Ypnypn (talk) 01:52, 14 March 2013 (UTC)
    They are not really multilingual, as far as I can tell: discussions are in English. But Commons and Wikispecies have less need for discussions, and the problem therefore is much less serious for these projects. But Omegawiki needs discussions, nd they are in English. Kip's native language is French, but his Omegawiki blog is in English. This clearly shows the issue. Lmaltier (talk) 12:23, 2 April 2013 (UTC)
    C'est pour ça qu'il y a très peu de non-anglophone sur ces projets. Ces projets marche comme les projets en.wiki et en.wikt c'est à dire en en avant tout. V!v£ l@ Rosière /Murmurer…/ 13:33, 3 April 2013 (UTC)
    Très peu de non-anglophones sur Wikimedia Commons ? Qu’est-ce qui te laisse à penser ça ? Pour ma part, je pense que tu fais erreur. (et je parle pour Commons car c’est mon home project, mais pour autant que je puisse le voir c’est tout aussi faux pour Wikidata.) Jean-Fred (talk) 00:15, 4 April 2013 (UTC)
    Y-a-t-il beaucoup de français qui ne parle pas un traître mot d'anglais contrairement à toi et moi ? J'en serais vraiment étonner. Quand j'ai proposé à ma mère d'exporter ses photos là-bas elle m'a répondu qu'elle n'osait pas le faire parce qu'elle n'y comprenait rien. J'ai regardé le nombre d'utilisateur se revendiquant fr-N qui avait la boîte babel en-1 ou en-0, résultat = il y en a vraiment peu. Et je doute que ce soit ceux-là qui participe le plus au décision au discussion et décision communautaire ou qui possède les outils de maintenance. C'est ce que je voulais dire par utilisateur non-anglophone (et pas seulement les utilisateurs ayant une autre langue maternelle que celle Shakespear désolée pour l'imprécision). V!v£ l@ Rosière /Murmurer…/ 00:56, 7 April 2013 (UTC)
    Commons a la volonté d'être un projet multilingue. Oui, l'anglais y est utilisé pour un grand nombre de discussions, car il permet d'inclure un grand nombre de contributeurs. Oui, il est possible de contribuer sur Commons en franaçsi.
    Commons:Commons:Bistro est une page sur laquelle il est possible de discuter en français de tout sujet concernant Commons, de demander l'intervention d'un administrateur en français, etc. Il y a également Commons:Commons:Service d'aide.
    Concernant les outils de maintenance, oui, je vois un cas : M0tty déclare ne pas parler anglais (mais a cependant été évalué comme en-1,5 par un wikimédien néerlandophone) et est administrateur de Commons.
    Enfin, de peu nombreuses mais existantes DR sur des questions Françaises (liberté de panorama par exemple) se tiennent en français (10 par mois ?). --Dereckson (talk) 13:14, 25 April 2013 (UTC)
    i am sorry for you - but you will never be able to create a complete "translation table". Language is dependent on the context. computer programs like Google Translate will in future become so powerful that they are capable of finding the correct translation. Then they will pass something like the w:Turing test (at least for translations). Rather than writing that wiki you should write a good translator, if your intention is to help to translate something. Otherwise you are free to create a page on Wiktionary for any proverb and give the correct translations on that page. --92.201.47.69 19:17, 14 March 2013 (UTC)
  2. Sadly oppose. Content duplication within and across Wiktionaries is a major problem. If I thought OmegaWiki was a viable way of reducing duplication, I would support it: but I think Omegawiki makes things worse, not better. I apologise that they are so long, but here are my thoughts:
    • Words which are denotatively similar enough to translate each other are rarely connotatively synonymous; ΩW's basic structure and practice of presenting terms from different languages as having exactly the same definition is unsound. ΩW's failure to include usage notes of interest to all languages (like those marking wikt:en:nigger as offensive and wikt:de:Führer as restricted in its usage) is surmountable; more problematic is its inability to include usage notes of interest to only a few languages (like the note in de.Wikt's entry on the Lithuanian meilė warning that it is a false friend of German Meile—something of interest to Germans but not e.g. Koreans).
    • Some proponents think ΩW will be able to consolidate translation tables, and tout this as a major reason to adopt it. Proponents of WikiData think the same of WikiData. If the goal of either is reduced content duplication, at most one can host the tables, but I think neither will be able to take translations off the various Wiktionaries' hands, because translations are often inexact and not mathematically transitive: it can be accurate to translate English foo into e.g. Basque as bar, Basque bar into French as baz, and French baz into Indonesian as qux, though it would be inaccurate to translate foo as qux; how could any unified table handle this?
    • en.Wikt has simple, .js-assisted mechanisms for adding translations and creating new entries; new contributors use them to add dozens of translations and create new entries every day. Other Wiktionaries, laid out in their own languages, also have many active users. ΩW is said to have only 10 regularly active users, and I doubt this is without good reason: ΩW's lingua franca is English, and its translation tables are based in English terms (it assigns translations to English senses: for translations of the German laufen, I am taken to DefinedMeaning:run (6323)). This makes it hard for people who do not speak English well to contribute translations or anything else to ΩW, or to participate in discussions: such users are better served by Wiktionaries in their own languages. Meanwhile, if ΩW is to grow, it will likely have to poach anglophone users from en.Wikt and other projects.
    • In conclusion, I do not think ΩW will be able to take any burden/data off the various Wiktionaries' shoulders, I think en.Wikt (at least, if not other projects) will not move its data to ΩW, I think that far from reducing content duplication, ΩW is just another competing standard, ... I think ΩW is just doing a bad job of what Wiktionary (and en.Wikt specifically) already does. -sche (talk) 03:01, 21 March 2013 (UTC)
    • PS, I suggest that this RfC be advertised on the Wiktionaries. I've posted a notice in en.Wikt's Beer Parlour. -sche (talk) 03:01, 21 March 2013 (UTC)
      • I agree with you (except that I find that duplication is not a problem). Also note that most of these issues (e.g. the fact that translations are not transitive) are the same for Wikidata, which should be used only for fully automated tasks, such as interwiki links. Lmaltier (talk) 21:53, 21 March 2013 (UTC)
      • Can you give an example of intransitive translations? πr2 (t • c) 22:10, 21 March 2013 (UTC)
        • Although verbs exhibit nuance and 'intransitivity' better and more often than nouns, the first examples that spring to my mind are the Basque words "neba" and "arreba", which translate into English as "brother" and "sister". "Brother" and "sister", in turn, translate into Abenaki as "nijia" and "nitsakaso"... but "nijia" cannot be translated as "neba", nor can "arreba" be translated as "nitsakaso": "neba" is the term for a female's brother, while "nijia" is the brother of a male; "arreba" is a male's sister, "nitsakaso" is a female's sister. (I'm still trying to recall some verb examples that show both my point about translations' intransitivity and my point about words' non-synonymity more clearly, but that's a start.) -sche (talk) 06:38, 24 March 2013 (UTC)
          • "a female's brother", "the brother of a male", and simply "a brother" are different concepts. In OW, they will be represented by different DefinedMeaning pages, each having a different set of translations. These concepts will be linked together with hypernymy relationship. Each concept have a definition which is exactly here to avoid the semantic drift when you jump from one language to the next several times.
          • Furthermore, when you want to enter a translation that is inexact, e.g. that English "brother" can be translated as either "neba" or "nijia", you can indicate them as not identical translations. --Kip (talk) 14:37, 4 April 2013 (UTC)
    About usage notes: we could easily implement a system as you say. We have something called "translatable texts", we can define a usage note as a "translatable text", i.e. any word can have usage notes in all languages. And then we show the usage note in the language of the user. It is totally possible to do. --Kip (talk) 15:19, 4 April 2013 (UTC)
    In OmegaWiki you can write a definition of a word in the same language - and any other languages. The translations of English (or other languages) definitions are quite seperate. You can also mark "translations" as imprecicse. The structure may be a little confusing at first because it is a little different - but easy enough to get used to. Many of the objections I'm seeing here may simply be due to unfamiliarity with OmegaWiki.
  3. Sufficiently Oppose. I have serious doubt about this project per problems explained by sche. 1) By being brought into the family of Wikimedia projects, OmegaWiki could raise the quality of Wiktionaries. ===> How ?
    2) In particular, translation tables could be managed centrally on OmegaWiki, instead of being duplicated over more than 100 Wiktionaries, similarly to how Wikidata works for interwiki links. ===> Duplicated translations is annoying BUT apply it blindly is very very bad idea. If I well understand, you group everything on one page ? But some word lost defenitively precision. How do you treat for example the case of one word from Korean language which make no difference between blue and green : 푸른 for this both color (amalgamate in one : 푸른) they are lot of chance that this fact will be treat imprecisely and translate aswell. Ex : "bleu" , "vert" in French like if this words was equivalent to 푸른 but they aren't. By the way I invite you to take a look to see the actual article 푸른 on fr.wiktionary and you'll see by yourself what happen when entry aren't checked by human, PiedBot is source of numerous mistakes on fr.wiktionary and it is really hard to solve it because we lack of impacted languages speakers. PiedBot had made real amont of mistakes and we already spread it on mirrors sites which use Wiktionnaire without correction. It is what happen when we make silly bot usage without understand the language concern and your project will favorise this kind of mistakes for severals reason :
    • you want automatize something that can't be done : translations.
    • massive usage of bots (even if the bot-user don't apprehend language, as PiedBot's puppetmaster who didn't know nothing about Korean, he'll work on it with his bot anyway).
    • lack of active members.
    Furthermore in our project we have an active user who drain blindly a lot of translations from other wiktionary and apply it on our project whithout distance and criticize, he made, him also, a lot of mistakes.
    For now I just can't trust your translations cause your project seems ready to unite things in same place that can't be done properly. Your project can maybe make good work on easy and significative word like car / plane / cat which seems have no ambiguities (but who can be certain that all languages process this similary ? Maybe a language on Earth use one word to define car&plane whithout make any difference between) but defenitevely not the kind of word like 푸른 & co. That's why I think translations have to be done from one word A to an other B only and not from B to C about the word A, this process provoke inaccuracy.
    Then the other point is the fact that wikidata can, later, process this word data informations so why take yours instead ?
    I understand your project need Wikimedia to growth but not the contrary because the 1 and 2 benefits seems illusions, 4 when Wikidata will improve it'll not need pass by your project, just let really the 3 (5 rest to prove). V!v£ l@ Rosière /Murmurer…/ 13:33, 3 April 2013 (UTC)
    We don't do bots, exactly for the reasons you give above. In OW, translations are sorted by meanings, and a human is needed to check that each meaning corresponds when adding translations. The English Wiktionary has done a good job to sort its translations by meanings, which is good, but most translations from the French Wiktionary - and others Wiktionaries, and most dictionaries - cannot be reused without manually checking that the meaning is the same.
    In OW, "푸른" would have its own page with a definition like "the color having a wavelength between 450 and 560nm", together with exact translations from some languages having the same concepts (some Mayan languages also have only one name for both colors), and will show that there are also inexact translations, identified as such, e.g. "blue" and "green" in English. It will further probably indicate that "blue" and "green" are hyponyms of "푸른". Similarly, in the page "blue", you'll see that "푸른" is indicated as an inexact translations, and you would obtain its definition when clicking on it.
    Colors are always a problem. Names for colors in different languages often cover slightly different ranges of the spectrum though there may be cosiderable overlap. As you suggest, the way to solve this could be to define the range of the spectrum to which native speakers would apply the term. CFynn (talk) 07:23, 22 May 2013 (UTC)
    Why take OW instead of Wikidata? Because OW is there already ;-) and dictionary-Wikidata is only at a "could we maybe?" stage, and might not happen. If it happens, I'll probably be one of its developers :-) --Kip (talk) 15:03, 4 April 2013 (UTC)
    Ok thank you I didn't got this point, so if the bot aren't inside I'm done. Like I said it's "sufficiently oppose", it's closer to the neutral than the oppose. I'm sceptic but if it's adopt count me to the volunteers. I'll help for French language, I'll make my own opinion on the field. If you really want a success you maybe should recruit some "volounters" (just 1 or 2) from each wiktionary project in order to test the project, wikt users will see if omega can be really a tool who improve collabs and partnership between wiktionary or if just a failure. You have 1 frenchy on the roster. V!v£ l@ Rosière /Murmurer…/ 01:17, 7 April 2013 (UTC)
    I think this: «you maybe should recruit some "volounters" (just 1 or 2) from each wiktionary project» is to be applied. Automatik (talk) 16:54, 8 April 2013 (UTC)
  4. Oppose. Language is not mathematics. We should’t force it to fit a pattern just so it can be better stored in a database. Ungoliant MMDCCLXIV (talk) 21:08, 16 June 2013 (UTC)
  5. Oppose. Alexa rankings do make a difference.
    OmegaWiki: #289,803 (⬆️275,852)
    Wiktionary: #570 (⬆️245)
    Scientistaryaman (talk) 20:16, 26 October 2013 (UTC)
    @Scientistaryaman:: If/when OmegaWiki becomes a WMF site, I guarantee it will get a lot of publicity and a boost in rankings. Besides, it might even become a subdomain of WIktoinary, in which case this is a moot point. PiRSquared17 (talk) 20:22, 26 October 2013 (UTC)

Would rather have a Wikidata implementation instead[edit]

  1. Too little and too late. Adopting OmegaWiki would be an unqualified strategic mistake. Omegawiki is ill-suited to support wiktionary projects with cross language data. It will be very simple to migrate the cross language information into Wikidata phase II but will require significant community and development work to integrate OmegaWiki for this task.
    Looking at its beer parlor it seems that SQL is one of the top languages under discussion. Which leads one to ask how mature is this extension and haw can it possibly deliver on its many promises?
    This request is a kin to asking the WMF to adopt a zombie project. Other WMF project have not been very as successful as wikipedia - but their problems were unclear at the outset. In the case of OmegaWiki this is not the case - there is no reason to expect that it will become a success at this stage - just the opposite that it will divert resources and create chaos in the community.
    Will WMF developers will not take over its code base - they do have a large number of new projects and a well established history of ignoring this type of extension. The WMF has for a number of years providing Wiktionary project with minimal tech or other support.
    Beside the obvious waste of resources, bringing this project into the WMF's will have largely negative repercussions in delaying and complicating the the natural evolution of Wiktionary projects. Once Wikidata reaches phase III, Wiktionaries will not only migrate their inter-wiki information but also their infobox like translation templates - at which point the WMF will have a lexical resource which will be far superior than OmegaWiki, without any of the down sides such as needing software integration and project by project consensus for deployment. While I understand Kips intentions are good he clearly does not get what Wiktionaries are about in terms of community or as lexical resources.
    While I believe WMF should support a hardware upgrade since this is an open culture project I am against adopting the project outright.
    I make a counter proposal - let's see if the community is at all interested in someone automatically pushing OmegaWiki content into say English/German/French Wiktionaries? If that works to a significant degree I might change my mind . OrenBochman (talk) 00:16, 5 March 2013 (UTC)
    I so much don't get what Wiktionaries are in terms of communities that they made me sysop at the English and French Wiktionaries (then Checkuser at English and bureaucrat at the French one).
    Wikidata supporting Wiktionaries as you state is far from being decided. At the moment it is just a "possible use maybe in the future".
    As of today, OmegaWiki is much advanced in terms of features (if you want to know how mature it is, don't ask yourself, just try it out), and more lexically-oriented. Though if it happens as you say, it is also not a problem. Wikidata being structured like OmegaWiki, transferring/merging data from one to the other is very easy. --Kip (talk) 13:38, 7 March 2013 (UTC)
    If it's possible to use OmegaWiki contents to add contents to wiktionaries, this would be great. But how? A definition in Omegawiki doesn't correspond to a word (or only to the word the editor was having in mind, in a particular language) and, therefore, is not always the right one when you try to apply it to a word of a different language. Lmaltier (talk) 22:04, 21 March 2013 (UTC)
  2. Oppose. I am certain that the way forward will be influenced by the lessons learned from OmegaWiki, but adopting a completely independent technical foundation for the use case for which wikidata is intended and presently being rolled out on the Wikipedias would be an error. --Vigilius (talk) 10:49, 26 March 2013 (UTC)
  3. Weakly oppose. It's very difficult for me to follow at a reasonable pace this discussion, and I learned a little English. What about those who do not know enough about the language?
    I think furthermore Wikidata could help simplify a lot of work, while keeping the benefits of local wiktionaries (speak in his maternal language). Automatik (talk) 16:54, 8 April 2013 (UTC)

Technical oppose, against the OmegaWiki software in itself[edit]

  1. Technical oppose, have no opinion on the project. Last time I perused the extension, I wasn't pleased (granted, things may have improved since then). There was tons of raw SQL, lots of unescaped output, and generally a lot of code that doesn't follow conventions. Until the code is brought up to current standards (for security and convention), I can't see any other WMF devs putting in the time to review this top to bottom (which would be required for deployment). ^demon (talk) 16:32, 8 March 2013 (UTC)
    I will try to work on that in the coming days. It would be stupid if that is the only outstanding issue (though I would have rather spent the time on implementing new features). Help if of course welcome, it is opensource. --Kip (talk) 09:00, 12 March 2013 (UTC)
  2. Technical oppose, have no opinion on the project. Agree with demon, this extension does not look ready for WMF usage. Loose from having security issues and not following MW conventions it is also has a quite some general design issues by the looks of it. --Jeroen De Dauw (talk) 14:40, 11 March 2013 (UTC)
    Agreed that the code should meet standards. Can you give a gross estimate or your opinion about the amount of work needed to overhaul it? --Purodha Blissenbach (talk) 13:45, 14 March 2013 (UTC)

Would prefer keeping OmegaWiki away from the WMF[edit]

  1. Oppose I oppose for several reasons. Mainly:
    1. I don't believe so much in multiplying Wikimedia projects. Wikipedia, the most successful project, has already been losing contributors for 6 years. Adding projects would split up forces, as said 92.201.151.62. There is room for advert-free money-free open-source projects in this world, but the space is limited. At the beginning, we were looking for simple contributions, now we want expert contributions, for free, with no benefit for the contributor, excluding companies etc.. This economic model cannot extend indefinitely. I think we should better let Omegawiki try another model, more balanced between economical interest and editorial independence. Omegawiki already accepts companies as contributors, and hyperlinks towards their websites, all things forbidden in English Wikipedia and others.
      Where are these hyperlinks companies websites on any of the content pages of OmegaWiki? I can't find them. Oh yes, there is a tiny link to their own "word of the day" Facebook page on th.e front page, but that is all I could find there - except for the bigger link to MediaWiki. In comparison the "External Links" sections of many Wikipedia articles, are littered with links to companies websites and other sources of often very biased information CFynn (talk) 07:59, 22 May 2013 (UTC)
    2. I agree with OrenBochman that it is probably too late. I was in favour of merging the Wiktionaries when I knew about the "Ultimate dictionary" project, but now Omegawiki has its own database and software extension and would compete with Wikidata and Wiktionaries. So the same foundation would host two competitors, which would create a conflict of interests. I would better let the 2 projects independent in a free competition, which doesn't exclude some cooperation. Getting all the good open-source dictionary projects under one umbrella wouldn't be good for cultural diversity. --Henri de Solages (talk) 14:46, 15 April 2013 (UTC)

Others[edit]

  1. Oppose - Amgine/meta wikt wnews blog wmf-blog goog news 16:30, 21 April 2013 (UTC)
    Not that you're required to provide one, but I'm curious: what's the reason for your opposition? --Waldir (talk) 23:32, 21 April 2013 (UTC)
    Get back to me after you've hassled everyone who did not provide a justification for their supports and I will happily provide you with my reasoning. - Amgine/meta wikt wnews blog wmf-blog goog news 23:36, 21 April 2013 (UTC)
    Sorry if my comment made you feel hassled, it was not my intention. I repeat, I am not saying that you're required to provide a reason, I was just curious. If you don't want to state your reason, just say so, you have that right. In any case, note that the case for support was presented in detail in the proposal being discussed, so it would be redundant to repeat the arguments if one agrees with them. On the other hand, the proposal does not (understandably) go into detail about downsides, which is why opposes without a statement are left kind of hanging without a default rationale. If you could at least say with which of the previous opposers you agree, that'd already be helpful for the discussion :) --Waldir (talk) 03:26, 22 April 2013 (UTC)
    If one accepts the argument (which I do not) that supports agree with arguments made in OmegaWiki#Benefits and find them sufficient, then one must also accept that opposes disagree with those arguments, or find them insufficient. No more need be said. The request for further justification, however politely phrased and harmless in intent, is a form of intimidation applied (in this case) to only one position in the discussion. - Amgine/meta wikt wnews blog wmf-blog goog news 15:37, 22 April 2013 (UTC)
    That would be valid if the items in the benefits section of the proposal were opinions which one could agree or disagree with. However, they are mostly facts, or at least reasonable assumptions, to which simply saying "no" would bear little refutation value. Finding them insufficient also implies disadvantages which outweigh the (explicitly stated) benefits, and it is only in the interest of those aware of them that these downsides be equally explicitly stated, for an informed discussion to occur. But I won't insist; if you won't justify your vote, so be it. So much for constructive criticism... --Waldir (talk) 20:52, 22 April 2013 (UTC)
    I disagree with your presumption "they are mostly facts, or at least reasonable assumptions". I, and others, clearly do not make such a presumption. Yet we have not asked every voter to severally state their justifications for their vote that we might debate their opinion. You've already missed my initial constructive criticism: this discussion appears to be taking place in a hostile environment to healthy discussion because one position challenges every vote of opposition. I will happily lay out my point of view when the environment is balanced and less-hostile. - Amgine/meta wikt wnews blog wmf-blog goog news 21:54, 22 April 2013 (UTC)
    Obviously, you've missed the point of the present page. It is not a vote (this is written in the present page as well), it is a request for comments (see what the title of the page says?), with an additional "who is interested?" section. "Oppose" is not a comment. The guy who added the "oppose" section actually also didn't understand either, but at least he provided comments, so it was in the scope of the page. I have now clarified a bit. --Kip (talk) 13:52, 26 April 2013 (UTC)
    Well, I don't think I have. *If* I have, so have the 40+ supporters who have not commented, yet who are not taken to task for doing so. (Of course it's clear this isn't a page about getting comments, but rather selling the concept, or it would have clearly outlined the costs as well as the benefits to all parties.) But if you'd like you can read my thoughts on the matter. You cannot have it both ways: those who oppose the idea forced to defend their positions while those who support it are not. - Amgine/meta wikt wnews blog wmf-blog goog news 17:07, 30 April 2013 (UTC)
    I think it's a pretty known and used standard that oppose votes are those who need to make detailed explanations. If I write only support, it is obviuous what and why I am supporting. If I vote oppose, I have to state my reasons why I'm against the proposal. Just writing a bare oppose vote without an explanation is useless at its best. — ΛΧΣ21 03:50, 2 May 2013 (UTC)
    Hi, I think it's OK now that we see wikt:User:Amgine/OmegaWiki position. It has more than enough comments to justify the oppose vote. Just writing "Oppose" is not constructive criticism, and I'll admit that I thought this oppose "vote" needed a reason, but this discussion about a single comment is getting pretty pointless. Besides, the position is already outlined on the aforementioned "OmegaWiki position" page. Isn't that enough? Regards, PiRSquared17 (talk) 03:54, 2 May 2013 (UTC)
    Two points: 1) "Me too!" is not useful; it isn't a comment about the proposal. There are clear and valid reasons to support the proposal which were not outlined in the proposal. If, however, you accept "Me too!" supports, you must also accept "Me not!" opposes. 2) Demanding justifications of opposers but not supporters means you will have fewer opposers posting, but not fewer people who oppose. - Amgine/meta wikt wnews blog wmf-blog goog news 04:06, 2 May 2013 (UTC)
    Well, I mostly agree with that comment, but this is getting off-topic for the RfC, and your comments have already been noted on en.wiktionary. PiRSquared17 (talk) 04:15, 2 May 2013 (UTC)
    Why would those opposing need to make detailed explanations? If you only write "Support", your reasons aren't clear at all. Obviously, loads of reasons for opposing are immediately apparent, and there's no real argument in favor of adopting this ludicrous project, which would cause endless damage for no benefit, besides for requiring an enormous amount of developer time. Right? ...
    Or perhaps you're a bit biased in thinking that it only makes sense for opposers to have to defend their views. --Yair rand (talk) 06:13, 2 May 2013 (UTC)
  2. Oppose Oppose: We already have Wiktionaries, which are not really successful, so why adopt another quite similar project? Furthermore an adoption doesn't mean that OmegaWiki will get more popular at all, there are already a lot of projects (f. ex. de.WN) that nearly nobody uses. |FDMS4 (talk) 15:01, 8 December 2013 (UTC)

Undecided[edit]

  1. It should be noted (at least as far as my understanding goes) that OmegaWiki is both 1) a project to create a reference work, in particular a multilingual dictionary and 2) a piece of technology that allows one to do so. In the first aspect, the goals of tis project completely overlap with Wiktionary, as such it should be merged with that project and not made into a separate WMF project. The second is where the questions remain for me: 1) To what extent will Wikidata support the same features in the future? This could eventually making OmegaWiki redundant in both aspects. 2) What is the quality of this technology and do the current developers plan to maintain it? There must be reasons as to why this extension in not currently being used on Wikitionary already. The WMF developers are unlikely to be willing to invest in or even maintain this technology. —Ruud 12:17, 10 March 2013 (UTC)
    There is only one OmegaWiki, there are many, many Wiktionaries... So with what community should it merge ? It makes more sense for those who care for the integration that OmegaWiki offers to join it. GerardM (talk) 09:08, 12 March 2013 (UTC)
    This is somewhat of a non-counter-argument. Besides not addressing my second point, where I indicated my real concerns lie, I suggested it should be merged with the project. One might could of course argue that the project is a community of communities, instead of one homogeneous one, but this is besides the point. —Ruud 20:37, 14 March 2013 (UTC)
  2. Omegawiki currently has several unrelated problems that impediate both its growth and acceptance. Here are some:
    1. Politically restricted to languages listed in ISO 639-3. This appears nonsense when you look at proposals like WikiLang. There are literally hundreds of research and/or documentation projects that could use OmegaWikis approach when more language types were allowed, such as *-lects, historic languages, reconstructed protolanguages, etc.
    2. Concept not documented well. You could as well say, it was hard to understand, but I oppose. Documentation is the problem.
    3. No Import. Having to provide a lingual "Definition" of each new word makes mass imports close to impossible.
    4. While the concept of dealing with concepts that words are representants of is well suited for the huge parts of languages inventories of words which can be seen as "ontological", it is hardly suited for some of the comparatively little rest. Yet people stumble over the rest and get lost.
    5. Use case missing. People who might use OmegaWikis data are unlikely to contribute much new data and vice versa. There is no killer application that would pull in new contributors.
    6. Contributing too time consuming. When learning new words of new languages, pupil maybe write them down into a plain text wordprocessor file. They could use Omegawiki instead but would have to spend prohibitively more time on it.
    7. Hard to share data with other projects. There is simply hardly any import/export capability yet. Leave alone dynamic data sharing over the internet.
    I believe that mentioned problems can be solved and cost would not be too high. We should be prepared to address them, however. --Purodha Blissenbach (talk) 13:45, 14 March 2013 (UTC)
    Politically restricted to languages listed in ISO 639-3 is not true, we make up our own code when there is no ISO639-3 for a language we want to add.
    Hard to share data with other projects: we have started building an API.
    --Kip (talk) 14:10, 26 April 2013 (UTC)
  3. From reading the discussion above (never heard of OmegaWiki, and had very little involvement with Wiktionary), I doubt WMF will sign up to this. However, there is clearly a lot of overlap between what OmegaWiki is doing and what a future link between Wikidata and Wiktionaries might do, and that overlap creates substantial learning potential. So I would support WMF giving some funds to OmegaWiki to help keep it going (there are grants programs...), and to explore co-operation and potential data exchange. Rd232 (talk) 18:36, 16 April 2013 (UTC)
    If I understood well, grants of the WMF are not for "keeping something going", like paying for servers, there are more for a one-time investment, like paying for research, or for new hardware. --Kip (talk) 14:10, 26 April 2013 (UTC)
  4. I'm undecided. I've heard comments against (duplicities, security, problems with 1 to 1 translations, splitting users, English bias, etc.) but I'm sure all of them can be fixed. I've allways desired a unique, multilingual, opensource, free, structured-data, collaborative, online dictionary: something like OmegaWiki. I miss on Wiktionaries the form interfaces for introducing data (there are thousands of templates!). I hate to add content in a single Wiktionary while all the others remain empty: IPA pronunciations, inflection and conjugation tables, translations (with the necessary annotations), images and ogg files, references, etc. almost everything should be replicated within all Wiktionaries, shouldn't it? I'd like one Wiktionary-OmegaWiki. Hosting it in WM servers? I'm not sure; I would say "yes" if this is a first step for fusing all wiktionaries. -Aleator (talk) 15:55, 21 April 2013 (UTC)
    Agree with you for this point, but why OmegaWiki more than Wikidata ? V!v£ l@ Rosière /Murmurer…/ 02:31, 25 April 2013 (UTC)
    Note that the proposal at the top of the page says, among other things: "provide potential models for a Wikidata-backed multilingual dictionary." ;-). There is the idea of reimplementing OmegaWiki as a Wikidata extension (or plugin or whatever), however, it would need more investments in term of programmers (so, more time and more money) and could be done maybe in a second step after having adopted OmegaWiki. --Kip (talk) 14:10, 26 April 2013 (UTC)
  5. A comment from a fairly significant contributor to English Wiktionary (the mega-contributors such as SemperBlotto and Equinox have better things to do than commenting here, I figure):
    • English, Russian, French, German, and other Wiktionaries should not be merged with OmegaWiki.
    • OmegaWiki seems to be an interesting experiment of its own, but so far generating very little interest.
    • Alexa ranks: wiktionary.org: 461, omegawiki.org: 1,559,100.
      • Visitors in subdomains of wiktionary.org, per Alexa:
        • en.wiktionary.org: 40%
        • ru.wiktionary.org: 17%
        • fr.wiktionary.org: 15%
        • de.wiktionary.org: 8%
    • English, Russian, French, German, and other Wiktionaries should be left free to duplicate each other's content; the duplication is not a problem.
    • A large Wiktionary such as the English one already mostly does what OmegaWiki does: document all languages using a particular language as the description or meta language, in one database.
    • Whether OmegaWiki would significantly benefit from the technical resources of Wikimedia Foundation, that I do not know.
    • That Wikimedia Foundation would significantly benefit from hosting OmegaWiki seems really unlikely.

      --Dan Polansky (talk) 14:29, 8 May 2013 (UTC)

Interested programmers[edit]

Are there any volunteer programmer, interested in either implementing new features in OmegaWiki, refreshing the code (which could be for example ajaxified), or reimplementing OmegaWiki as a Wikidata project? Please indicate your name below, and your ideas. We could have some fruitful discussions. Some knowledge in Php, Java and Sql would probably be needed, but if you are bold you can also try the "learning by doing" approach.

  1. In any case, there is me. --Kip (talk) 12:34, 29 April 2013 (UTC)
  2. me too  Klaas|Z4␟V:  11:33, 21 May 2013 (UTC)
  3. me also --Hiong3-eng5 (talk) 08:45, 3 June 2013 (UTC)
  4. here! --Ricordisamoa 20:45, 13 September 2013 (UTC)
  5. Purodha Blissenbach (talk) 11:45, 3 November 2013 (UTC)