As an anonymous user, you can only add new data. If you would like to also modify existing data, please create an account and indicate your languages on your user page.

International Beer Parlour/Archive20121231

From OmegaWiki
Jump to: navigation, search

Synonyms for 'colonna'[edit]

Happy belated New Year, friends Romans and country man ;-),

Searching for the Castillian/Italian expression colonna we find in my opinion too few extensive definitions. Just added Dutch. English, French, German and more natives are cordially invited to add theirs to improve this very fine project. Thanks in advance. Cheers or better said: Don't Worry, Be Happy,
ClubFavolosa(TFD) 01:01, 6 January 2012 (UTC)

Cannot add meanings in another language[edit]

If I try to add a new meaning in a new language to an existing espression such as Expression:Karo or Expression:Eckstein, which I do in the last section, it is not stored when I klick the [Save] button, while other changes to the existing expressions are. I all the time did three things: Set the language in the headline, set the language in the DM, and enter a definition text in the DM. --Purodha Blissenbach 11:49, 10 February 2012 (UTC)

It did work, but maybe you are not aware of the new system where only one language is displayed on a page.
For example, when you go to Eckstein, it shows only the definitions in German (
if you then hover over "German ▿", a dropdown box should appear (otherwise, refresh your cache) and you can then click on Kölsch.
it should take you to the page , where your definitions are.
(please delete the extra definitions that you have created)
So, if you create a definition in a new language, you then have to switch to that new language, by using the dropdown box.
More on this at
--Kip 16:20, 10 February 2012 (UTC)
Hallo? Ist hier Jemand? --Kip 21:36, 28 February 2012 (CET)

"is" and related matters[edit]

Hello, I am new here and am trying to build the Turkish language entries. Turkish is an agglutinative language, so certain words in other languages correspond to suffixes in Turkish. I am thinking of the word "is" in English (I really am at the beginning!) which can be translated either with the -dir suffix (in more formal speech) or with nothing at all (zero copula in linguistic terminology). For example "Deniz mavidir" means "[The] sea is (always, characteristically) blue". More informally, you would say "Deniz mavi", which means "[The] sea [is] blue". Given this background, I have a few questions:

  • Can expressions be in OmegaWiki be suffixes as well? If yes, is there a rule on writing them? (e.g., can I spell the Turkish translation for "is" as "-dir"?)
  • Given that the translation of "is" can be nothing at all in Turkish, how can this be represented in OmegaWiki? The absence of a synonym does not mean absence of an entry in the database, but that the synonym is a nothing. In fact I think in some linguistics texts, the zero copula is represented with the Ø symbol. Should we create a "Ø" expression to this end? It would not mean the Ø letter but a signifier that is implicit.

--InfoCan 16:42, 8 March 2012 (CET)

For suffixes and prefixes: yes, we have for example Expression:Gehirn- and Expression:-ibility. --Kip 18:51, 8 March 2012 (CET)
For the zero copula, I have no idea. --Kip 18:51, 8 March 2012 (CET)

What about " " or better "‌" (the double quotes are just to show the effect) respectively   or ‌ ClubFavolosa(TFD) 00:29, 9 March 2012 (CET)

This does not look like a good solution to me, it'll look like there is a bug. An explicit symbol, as proposed by InfoCan, would therefore make more sense. --Kip 09:34, 9 March 2012 (CET)

The empty set symbol Ø represents the null morpheme in linguistics. Not only is it used for the zero copula (see some examples I found on the Web at [1][2][3]) but it is also used to denote that a morpheme is invisible as in some irregular words in English that do not take an -s in the plural:

cats = cat + -s = ROOT ("cat") + PLURAL
sheep = sheep + Ø = ROOT ("sheep") + PLURAL

So, using the Ø as an expression here in OmegaWiki would be very appropriate. --InfoCan 20:39, 9 March 2012 (CET)

Currently Omegawiki doesn't even have conjugations and so the "is" problem is not a pressing issue in my opinion. It all depends on how conjugations and declinations are going to be implemented in Omegawiki and that's quite a difficult thing.
Also, a dictionary can never really explain all the grammatical subtleties of a language, that's what grammar books are for. That "is" can be omitted in some cases in Turkish (same is true for Latin) is not really information suited for a dictionary entry. We could create a Grammar Appendix for those kind of things. --Tosca 12:50, 10 March 2012 (CET)
One other thing: An expression is supposed to be a word (or a word form) in a specific language. Expression:Ø would link to many DMs, in many languages just to show that something can be left out? Doesn't strike me as very useful. --Tosca 12:55, 10 March 2012 (CET)
Indeed, "is" is not currently defined in OmegaWiki, but my point applies to "be" just as well. My original point remains, the translation of "be" in Turkish is the zero copula. By not putting an entry for Turkish in the translations/synonyms list to indicate this fact, you would make Turkish look no different from any other language that nobody got around to putting an entry for. Absence of data should not mean that the data is a nothing. The fact that "be" corresponds to a null morpheme in Turkish is useful information and this is a different situation from the fact that there is no word for "shallow" in French. As for Ø having multiple meanings, that would be no different than any other word with multiple meanings. --InfoCan 21:59, 10 March 2012 (CET)

Vowel harmony[edit]

Moving along in the Swadesh list, I have another Turkish-related question, which pertains to other languages with vowel harmony. "Not", as a verb modifier in English, is an infix in Turkish. For example "Ali geldi" means "Ali came" and "Ali gelmedi" means "Ali [did] not come". So, the tranlation of "not" is "-me-" in Turkish. Because of vowel harmony, certain suffixes can be modified depending on the vowel of the preceding syllable. For example, "Ali aldı" means "Ali took" and "Ali almadı" means "Ali [did] not take". So, the tranlation of "not" can also be "-ma-" in Turkish. Semantically "-ma-" and "-me-" are exact synonyms but syntactically they are not interchangeable. Can/should this situation be indicated in OmegaWiki? --InfoCan 17:10, 8 March 2012 (CET)

According to me, but that is open to discussions,

  • "-ma-" and "-me-" should be indicated as exact synonyms
  • A "usage" or "note" annotation should be introduced and used to explain the specific use of each one. We already have an annotation called "usage", which could be used that way, but I am not happy with this one because it is a "simple text annotation" and not a "translatable text annotation", which prevents e.g. to explain the use of a Turkish word in English.
  • So I propose a new annotation, which would be a translatable text (like etymologies), and I don't know how to call it. --Kip 09:38, 9 March 2012 (CET)
Can't we just move Annotation - Plaintext - Usage to Translateable Text? --Tosca 12:25, 10 March 2012 (CET)

In Latin, the English possessive "'s" is translated by a genitive case "-i", "-ae", "-is" etc., according to the declension, so that there are several suffixes meaning "'s", according to the inflexion group (declension). Even in English, it can be "'s" or just " ' " (apostrophe) if the word already ends with an s. This problem is extremely common, both for inflectional morphemes (like "-i", "-ae", "-is"…) and for lexicographic morphemes, like "-tion" ("action"), "-sion" ("evasion"), "-ing" ("firing"), "-al" ("withdrawal") etc., all meaning an action. I already proposed there to treat this with inflexion but nobody answered anything. :-( I'm happy this question is dealt with now. :-) To my mind, as Kip wrote, it should be treated as synonyms when it is lexicographic (i.e. when this creates a new word, present in a normal dictionary) but such a treatment wouldn't be adequate when it is inflectional, because the reader should be able to access the rule (vowel harmony, declension etc.) even if the reader is a translation machine. 22:51, 11 March 2012 (CET)

So, in situations where a word in one language corresponds to an affix in another language, are you suggesting that the SynTrans table should list not the inflectional morpheme ("-me-" or "-ma-" for the Turkish example I gave above), but a link to a grammatical rule? For example "not" as a verbal negation word in English, may have to be linked to the Turkish grammatical rule named "Turkish_verb_negation_rule" which may say something like "if vowel of last syllable of verb root is one of [eiöü], then add "-me-" to verb root, if vowel of last syllable is one of [aıou], then add "-ma-" ". --InfoCan 18:19, 12 March 2012 (CET)
You are probably right in suggesting affixes should be listed. But should all their forms be listed? A problem is that there are quite many declensions, sub-declensions and exceptions in languages as Latin or ancient Greek, so that an exhaustive list, though possible (and realised in grammar books) may be a bit long. My main point however is that such a list is not enough and a note readable only by humans is not sufficient: a computer reading Omegawiki should be said that the Mongolian suffix "-сан" (past participle) has the 4 forms of vowel harmony according to the normal Mongolian vowel harmony rule ("-сан", "-сон", "-сөн" and "-сэн"), while the suffix "-тай" (comitative case), as an exception, only accepts 3 forms ("-тай", "-той" and "-тэй"). The same way, a computer (specially a translation machine) should learn from Omegawiki that the Latin "-ae" is the genitive of the 1st declension, "-i" the one of the second one, "-is" the one of the third one etc., not only that there are genitive forms. I think we need at least an inflexion group field, because, although it's not traditional, vowel harmony could be treated this way too: I don't know Turkish, but in Mongolian, one can say there are 4 groups of words according to their main vowel. Since affixes may be influenced both by vowels and by the last consonant, maybe it would be easier to say that a word can belong to 2 or more groups, for instance a declension group, a vowel harmony group and a last-consonnant group (This said, I don't know any example where the 3 are needed, but 2: yes.). 20:04, 12 March 2012 (CET)
Alright, let me try to summarize. We are saying that an Expression can be either a word, or a phrase, or an affix (suffix/prefix/infix) group. We can have a link to any of these from the Synonym-Translation table. If it is an affix group, its name will be generic (for example "Turkish verb negation suffix group", not "-me-"). It will have a Defined Meaning, which will be a simple definition like "a suffix to negate a verb". In the language-specific entry of the SynTrans table, there should be a "grammatical rule" annotation link where the grammatical rule can be detailed. Agreed? --InfoCan 20:53, 12 March 2012 (CET)

Translatewiki news[edit]

Ciao fellow editors of this great project OmegaWiki,

I noticed that one or two of you might be active @Translatewiki as well. Since a couple of weeks there is a group on professional social network LinkedIn to discuss general features, eventually even bugs that might occasionally happen. The group is simply called "Translatewiki" (without the double quotes). It's a closed group, but when you tell management you're an OmegaWiki editor management will be happy to let you enter and join our 'Discussion' section and more.

Cheers, Klaas V 00:57, 9 March 2012 (CET)

Byebye identical_meaning[edit]

I've just removed the column "identical meaning". I believe it has been more confusing than useful, for several reasons:

  • it looks ugly (for everybody) and confusing (for new users)
  • many people seem to have different expectations of what it is for. If we all have different definitions of what it is, then it is useless (for example, for me it does not make sense to indicate non-identical translations when we already have identical translations)
  • due to the html nature of a checkbox, it is buggy. Basically, in html, when the user click on save, a checkbox sends a value only if it is clicked. If, for some reason, the server does not send all the input of the form, it will be assumed that the checkbox are unchecked, and all the identical meaning will be set to 0, as had happened many times before.
  • even if a definition has non-identical translations, then, we have a proposition of a word in a foreign language that could be used, but that word is not related to its actual definition. That is to say, there is no indication of how the translation is different from the current DM. So in my opinion it is useless the way it is implemented now.

What should be implemented is a separate "non-identical translation" section, where a link is made to other DMs with close meanings for certain languages (I am not sure yet of the actual implementation, but the idea would be to have a definition of the non-identical translation, to know how it is different from the current dm). It should also be separated from the real translations in the database. --Kip 12:18, 10 March 2012 (CET)

Yes! I never liked that thing. It encourages peoeple to add too many translations that are vaguely related to the definition and that makes a DM bloated and useless. --Tosca 12:28, 10 March 2012 (CET)
I think related and exact synonyms can both easily be stored in the same database, doing this requires only a marginal investment of resources. However, display and editability are important considerations, otherwise the editors and users would get overwhelmed. I glanced at some major online thesauruses, they are all organized slightly differently, they may inspire us for a good design here. See the "eat" entry at [4], [5], [6], Macmillan [7], Collins [8] and Merriam-Webster [9]. So until a better user interface can be designed, I think Kip should hold onto the existing data of related words. Let's discuss this more. --InfoCan 14:19, 14 March 2012 (CET)
Yes but "identical meaning" is not about related and exact synonyms, but about approximate and exact translations. I don't know any dictionary that proposes approximate translations...
For related synonyms, we already have what we call "relations" (hypernyms, hyponyms, etc.), which have the advantage to (1) have a name which allows to specify what type of relation applies and (2) link a DM to another DM, so that we can see, for their definitions, how they differ.
What we could do is introduce a relation called "near synonym". This would already be better than the current non-identical translation (since it links to a DM, and not just gives a word), or the "related terms" relation that we got from Gemet. However, the problem would be to agree on an objective definition of what a "near synonym" is... hypernyms and hyponyms (and meronyms and holonyms) have the advantage to have a clear definition.
P.S. with relations: At the moment, if we specify that A is an antonym of B, the relation that B is also an antonym of A is not automatically created. Same with A hypernym of B which should automatically create the relation B is a hyponym of A. This is one of my many projects for the future... (of course anybody can learn php and do it...) --Kip 19:09, 14 March 2012 (CET)

I think for "near synonym" information to be stored, we need to define a concept tree. For example the word "eat" can have the definitions of 1) "consume food" and 2) "destroy over time". These belong to the following concepts (actually, this is how the Oxford English Dictionary does it):

  1. the external world > the living world > food and drink > food > consumption of food or drink > eating > eat [verb (transitive)]
  2. the external world > matter > bad condition of matter > cause bad condition in [verb (transitive)]

(1) would contain "eat", "feed" (intransitive) and "consume", while (2) would contain "eat", "corrode", "erode".

The concept would be an attribute of the DM. --InfoCan 19:20, 14 March 2012 (CET)

I have just been struggling with a case of a near synonym. It seemed to me that I could get around the problem by using hypernym and holonyms but then I became uncertain. I am realizing that I have not understood well some of these relation terms and need some concrete examples. If you could assist me with my questions below, it might also help with finding solutions to the broader subject of near synonyms.

In Turkish there are separate words for "sister of mother" (teyze), "sister of father" (hala), "wife of uncle" (yenge). In English all these concepts are expressed with one word, aunt. So aunt is a near-synonym of these three Turkish words.

  • Would it be correct to label aunt a hypernym of teyze ?
    • yes, a "sister of mother" is an "aunt".
  • Would it be correct to call "relative" a holonym for teyze?
    • No, I think in this case it is still a hypernym. A "sister of mother" is a "relative". It could only work in the case you mention if we had a definition for the plural "relatives", like "the group of people who are related by blood or law to someone". teyze would be a holonym of that group. This could work maybe with family.
  • Should teyze also be in the class of "relative"? (If so, isn't class redundant with holonym?)
    • Class is a bit redundant with hypernym, but the aim is different. I tried to explain it there: Help:Class. A class is only useful if we want to add some class attributes.
      • I am confused. "Relative" is one of the choices under the Class dropdown menu, but does not appear in the list of used classes shown here [10]. Or is this a bug resulting from "relative" being a synonym of "relation"?
        • See [11] It seems that the (ugly) class viewer does not use English as default. If you want to start with learning some php, rewriting this page could be a nice newbie exercise ;-) --Kip 16:36, 19 March 2012 (CET)
      • I am still not clear. What are the class-specific attributes of "relative" (or "släkting" as it is called in the database)? (sorry, I don't think I will have time to learn php in the near future) --InfoCan 17:11, 19 March 2012 (CET)
        • In this case, it is the relation "partners with", which is available only when a DM is added to the class "relative". --Kip 18:41, 19 March 2012 (CET)
          • How was the relation "partners with" attached to the class "relative"? I do not see it mentioned in DefinedMeaning:släkting_(6740). --InfoCan 15:06, 21 March 2012 (CET) And, for DefinedMeaning:niece_(6735), where do the relation terms "is part of theme" and "related term" come from (they are not among the Relations choices)? --InfoCan 17:39, 21 March 2012 (CET)
  • The relation term "partners with" is defined as "goes together on the same level". In this context, how am I to interpret "goes together on the same level" for the concept of "sister of mother": brother of mother, sister of father, or husband of sister of mother?
    • I think that here, "partner" in the sense of "married with" is meant. So I'd say "husband of sister of mother", but I've never used or seen this "partner with" before.
  • As meronyms, should I list all family relative terms or a perhaps a subset of them?
    • same as for holonyms.

Would entering the above information satisfactorily resolve the relationship between "teyze" and "aunt"? Can you think of an example where hypernyms, holonyms etc. cannot help resolve a near synonym situation? --InfoCan 21:11, 17 March 2012 (CET)

Regarding entering all terms or only a subset, it should be kept in mind that at some point, transitivity will be implemented. i.e. the possibility to see relations in the form of a tree, as is done in WordNet.
So, this means that it is best to enter only direct hypernyms, such as a "father" is a "man" and a "man" is a "human", but not indirect hypernyms such as a "father" is a "human", since this can be deduced (by transitivity) from the two others.
For an example with holonyms, maybe: "father" has for holonym "parents" (plural), which has for holonym "family". --Kip 11:03, 19 March 2012 (CET)
It seems that for objects or people, near synonymy can maybe always be expressed by hypernyms, holonyms, etc.
But for more abstract concepts, such as feelings, I'm not sure how this works out. What would be the relation between "happy" and "delighted"? --Kip 11:08, 19 March 2012 (CET)
I am not sure about happy and delighted, because the definition of delighted is "very pleased". Because this definition is a qualification of "pleased", it should be a subset of all the variations of the "pleased" state. Therefore, I think pleased is arguably a hypernym of delighted.
As an example for a holonym, I can think of exuberant, which is defined as "joyously unrestrained and enthusiastic". Because you need both adjectives to define the word, exuberant should be a holonym for "joyously unrestrained" (which we can further breakup as joyful and unrestrained) and enthusiastic, it seems to me. --InfoCan 15:22, 19 March 2012 (CET)
I don't think that hypernyms / holonyms apply to adjectives.
However, we could get some ideas from WordNet. See , "Relations". --Kip 16:41, 19 March 2012 (CET)
  • Going back to teyze ("mother's sister"), until the "non-identical translation" section is implemented, I do not enter "teyze" as a Turkish translation of "aunt", and I do not enter "aunt" as an English translation of "teyze", right? Or do I, but explain the exact meaning in a usage note? --InfoCan 19:04, 19 March 2012 (CET)
    • For Turkish, no, you wouldn't enter "teyze" as a translation for "aunt".
    • For English I am not sure. I think it would not be wrong to add the translation, considering that a "mother's sister" is always called an "aunt" in English (it is also called a "maternal aunt", which also includes mother's sister-in-law, so this is not exactly like Turkish). Then, when we consult "Expression:aunt", we would see "mother's sister", "father's sister" and "the sister or sister-in-law of a parent". This is not wrong, but maybe too many? --Kip 09:05, 20 March 2012 (CET)

Dear Kip, you had written there about the degrees of idiomaticity and accuracy: "Already implemented with the checkbox "identical meaning".". And then you even deleted that checkbox, which was a very unrefined (boolean) way of noting the degree of accuracy. I still think we need something. Moreover, I think this kind of decisions needs a previous discussion, rather than a subsequent one. And it is psychologically inappropriate to delete the other users' work. If the idea is to replace that checkbox by something else, then the new thing should be ready at the time of deletion.

The HTML problem is not serious: you can just replace the checkbox by a radio button or a rolling list. The esthetic problem is not serious either: you can replace by the choice between the signs "=" and "≈" if you prefer. The confusing aspect could be solved thanks to a bubble message, which is extremely easy to implement. You wrote you don't know any dictionary proposing approximate translations. There are very many, specially when the languages and the cultures are very different, but also, for example, in "Le Robert & Collins super senior français-anglais" dictionary, one the the best paper translation dictionary on this planet. I read "conseil d'établissement (Scol) ≃ governing board (Brit), ≃ board of education (US)". What happens is that some dictionaries (specially the small ones) provide for an approximate translation without saying it is approximate. Moreover, sometimes, though the semantically exact synonym exists, its use is different. For instance the exact translation of "sibling" in French would be "germain", an old French word nowadays only used in French genetics (possibly in other specialities too, but this word is not understood by average highly educated French people). It is usually translated by 3 words, "frère ou soeur", which I think is not a French lexical item (neither is probably the plural "frères ou soeurs", but "frères et soeurs" is a lexical item.).

What is ugly and confusing is the "number(old)" you left. I'm VERY grateful to you about the great job you do, but may I suggest you finish the work you began before starting another one, a fortiori before deleting a useful innocent checkbox? 04:58, 21 August 2012 (CEST)

As I wrote here we need to acknowledge that not every DM has a corresponding SynTrans in every language. In such cases we can provide the best available expression for the needs of an interpreter, but a specialist needs to know that the translation is not exact. I agree with Fiable that the identical_meaning indication has to come back in some form. I am not sure how bad the information was before it was removed. Perhaps we can bring back the checkbox but not the old data or we can bring back both and clean up the old stuff. --InfoCan 18:28, 21 August 2012 (CEST)
  • The HTML problem is pretty serious actually, because it set "identical meaning" to 0 for the entire list of translations, which was usually not detected by the user, and also reverting such edit is not obvious. This bug is actually the main reason why I disabled the functionality immediately without prior discussion (which I usually do, and I am sorry when I don't), as I did not see an immediate solution and I saw that several DMs where affected.
  • I considered replacing by a radio button, but this does not work because of the way that radio button works
  • However, I did not consider the solution of a rolling list. I find that the solution with "=" and "≈" is pretty nice. This would solve the ugliness problem.
  • The "identical meaning" information is still in the database, so that I can revert if people complain, which seems to be the case, so ok, I'll implement the dropdown list and put the functionality back. Not sure when I can do that though, because of busy real life at the moment (or, I don't mind if someone else with php knowledge tries to do it).
  • Informing the people with a hint/popup box: of course it is a good idea and easy in pure html, but I don't know where and how to fit it in the MediaWiki php.
  • Personally, I am still not convinced by the "non identical" checkbox, because it does not say in what way it is non-identical, and each person seems to have his own opinion of non-identicality, and I am not sure that a hint/popup will change that. When everybody uses a different system to judge whether it is identical or not, it is clear that such annotation becomes useless.
  • About "number(old)"... I forgot about it, sorry, it is now back to normal. --Kip 20:27, 21 August 2012 (CEST)
Thank you! 13:27, 23 August 2012 (CEST)
Is there a mechanism to ensure that two SynTranses of the same language with non-identical identical_meaning values cannot be entered? This would force the editor to consider deleting the one with identical_meaning=FALSE. --InfoCan 21:42, 21 August 2012 (CEST)
I considered that already, but I did not find a simple way to do this. --Kip 11:48, 22 August 2012 (CEST)
You mentioned that people have different ideas of what represents a non-identical meaning. Can you generalize as to what common types of "non-identicalness" are used? Perhaps we can force (if possible) or at least give the option to indicate the type of non-identicalness used. For example they may simply have paraphrased the definition ("2-3 years old foal" for the Mongolian word that means "foal between 2 and 3 years old"), or put a qualifier in front of a hypernym (young foal), or just used the hypernym ("foal"), etc. --InfoCan 15:29, 22 August 2012 (CEST)
I think that, by contrast to the way the former checkbox used to work, we can consider that the default is "identical meaning" and, in the consultation version of the page, not write anything in this case. Paper dictionaries don't mention this, but good dictionaries do mention when there is a difference. Even the Robert & Collins super senior I quoted doesn't say more and, to my mind, it is in most cases enough. If the word with non identical meaning is itself a lexical item in the language (like "foal"), then the reader can look at its precise meaning. If it is not, then it is probably decomposable into lexical items the reader can see one by one (for instance "2"+"-"+"3"+"years old"+"foal") if he knows a bit the grammar of that language. I think there is much more important work to do than a list of non-identicalnesses, notably inflexion groups. 13:27, 23 August 2012 (CEST)

Requests for comment/Adopt OmegaWiki[edit]

I made a comment at regarding the adoption of OmegaWiki by MediaWiki. If you could make your views known there, perhaps a consensus will emerge. --InfoCan 22:14, 10 March 2012 (CET)

uw_transactions table in SQL export?[edit]

I just refreshed my local OmegaWiki database copy from the .sql export provided on the Development page, and one of the differences I noted when compared to my own copy (dating from August 19, 2011) was that the uw_transactions table is no longer included in the output. Many other tables reference the uw_transactions table with add_transaction_id and remove_transaction_id columns, so I think including it in the export is necessary to achieve full data integrity. Was there a good reason to remove it, other than saving space? László 14:43, 18 March 2012 (CET)

I removed it recently from the dump because I discovered that it contains the IP of users, which I think should not be made public.
I am not sure what would be the best solution... --Kip 10:29, 19 March 2012 (CET)
Would you be willing to add this to the daily export?
mysql -u username -pPassword --execute="SELECT transaction_id, user_id, '' as user_ip, timestamp, comment FROM uw_transactions" -X omegawiki > uw_transactions.sql.xml
This assumes the database is named "omegawiki". Also note the "-X" parameter: this enables XML output, which eases importing into an existing schema. The IP column is redacted by filling it with "". This leaves out the CREATE statement for the table, but that shouldn't be too hard to export.
But how do I merge the obtained XML file with the .sql backup of the other tables? --Kip 19:03, 19 March 2012 (CET)
I would have suggested providing the file as a separate download, but your ultimate solution is even better. Thanks! László 13:36, 31 March 2012 (CEST)
I think I'll rather change the code so that it saves the IP only when there is no user_id (as is done in MediaWiki [12]). --Kip 13:44, 20 March 2012 (CET)
It is now in the dump again, with the IP of registered users blanked. --Kip 18:39, 23 March 2012 (CET)
Superb! Downloading now. László 13:36, 31 March 2012 (CEST)


WordNet is a free resource of the English language that is the product of years of labor and has been used by many other linguistic resources. There is a free French version being developed as well [13]. (Versions in other languages do not have free licenses.)

In WordNet, words have definitions, lexical relation annotations (like hypernyms, attributes, similar meanings, example sentences, troponyms,sentence frames, etc.). To give you an idea of the data, here is the entry for the word "long" [14].

The idea of doing a bulk import of it was discussed in 2009 here [15] but I couldn't tell what became the outcome. Why not do it here? (Other than the reason that there is only one of Kip!) WordNet may not be as comprehensive as the Oxford English Dictionary but it is quite good, any minor imperfections can always be fixed here, and especially the lexical relation annotations are very extensive. Yes, integrating the new info with the old one would be time consuming, but it would still be faster than doing it by hand (the WordNet web client is very very slow). I am imagining an import tool with two panels, the left panel having the different meanings of an Expression in OmegaWiki, the right one having different meanings of an Expression in WordNet and you would click on boxes to indicate which entry matches which one and to select which subset of the information to import into OW. --InfoCan 17:33, 18 March 2012 (CET)

Reading the discussion you linked, it appears that the main issue is the license of WordNet. It is freely available, but the attribution clause from the license seems quite strict: Permission to use, copy, modify and distribute this software and database and its documentation for any purpose and without fee or royalty is hereby granted, provided that you agree to comply with the following copyright notice and statements, including the disclaimer, and that the same appear on ALL copies of the software, database and documentation, including modifications that you make for internal use or for distribution. IANAL, but that doesn't sound very "remix-friendly" to me. László 18:05, 18 March 2012 (CET)
That shouldn't be a problem. Omegawiki's licenses, GFD and CC-BY, also require attribution to the original content creator(s) in all copies and modifications of the software and data. --InfoCan 18:21, 18 March 2012 (CET)

buggy DefinedMeanings?[edit]

Take a look at these: DefinedMeaning:ellas_(7765), DefinedMeaning:ellos_(7766), DefinedMeaning:skeleton_crew_(7767) I ran into these while closely examining the database structure. A total of 41 possibly duplicated defined meanings can be retrieved using this SQL:

select dm.meaning_text_tcid, dm.defined_meaning_id
from (
 select meaning_text_tcid, count(*) num
 from uw_defined_meaning
 where meaning_text_tcid > 0
 group by meaning_text_tcid
 having num > 1
) duplicated_dms
join uw_defined_meaning dm
on duplicated_dms.meaning_text_tcid = dm.meaning_text_tcid
order by dm.meaning_text_tcid;

Below is the complete list. I've put each "set" on a separate row. The first number is the meaning_text_tcid, the second is the defined_meaning_id, linked to the article. They are redlinks, but when you click them you see the old data anyway. I have crossed out the defined meanings that I think should be deleted.

7012, DefinedMeaning:(7206) 7012, DefinedMeaning:(7208) the former has no expressions
7586, DefinedMeaning:(7786) 7586, DefinedMeaning:(7787) the former has no expressions
7812, DefinedMeaning:(8013) 7812, DefinedMeaning:(8014) 7812, DefinedMeaning:(8015) None have expressions
8171, DefinedMeaning:(8370) 8171, DefinedMeaning:(8371) the former has no expressions
145447, DefinedMeaning:(7323) 145447, DefinedMeaning:(7324) the former has no expressions
146000, DefinedMeaning:(7728) 146000, DefinedMeaning:(7729) the former has no expressions
147104, DefinedMeaning:(8086) 147104, DefinedMeaning:(8087) the former has no expressions
149545, DefinedMeaning:(7482) 149545, DefinedMeaning:(7483) the former has no expressions
150591, DefinedMeaning:(8255) 150591, DefinedMeaning:(8256) the latter has no expressions
152588, DefinedMeaning:(7792) 152588, DefinedMeaning:(7793) the former has one expression, but it does not match the definition
152615, DefinedMeaning:(7207) 152615, DefinedMeaning:(7209) the former has no expressions
152716, DefinedMeaning:(7325) 152716, DefinedMeaning:(7326) the former has no expressions
152773, DefinedMeaning:(7396) 152773, DefinedMeaning:(7397) the former has no expressions
152803, DefinedMeaning:(7627) 152803, DefinedMeaning:(7628) both have at least one valid expression, the latter has more, so the former should be merged into the latter.
152901, DefinedMeaning:(7543) 152901, DefinedMeaning:(7541) 152901, DefinedMeaning:(7542) The first two have no expressions
152946, DefinedMeaning:(7591) 152946, DefinedMeaning:(7592) The latter has one expression, that the former also has.
153100, DefinedMeaning:(7765) 153100, DefinedMeaning:(7766) 153100, DefinedMeaning:(7767) The former one has one expression that should be merged into the latter; the middle one is way off and has a few expressions that should probably be merged into one of the DM's matching "They". Probably a lot less work overall to just delete it, though.
153206, DefinedMeaning:(7899) 153206, DefinedMeaning:(7900) the former has no expressions
153407, DefinedMeaning:(8413) 153407, DefinedMeaning:(8414) the former has no expressions

How do we clean this up?

László 18:34, 18 March 2012 (CET)

It was due to a bug that we had some years ago...
I'll see what I can do to correct this in the database. Thanks for reporting the problem! --Kip 10:40, 19 March 2012 (CET)
I just noticed that I need to put brackets around the id in order to make a proper link; fixed that. As for how to proceed: I think the best way to merge the problematic DM's above would be to pick the DM whose describing expression_id most closely resembles the meaning (and indicate it by marking it in the list), and then write a custom SQL script that moves all expressions from the other one(s) to it, and deletes the empty DM's entirely. The remaining cleanup (i.e., removing clearly incorrect expressions) can then be done manually through the web interface. László 22:05, 1 April 2012 (CEST)
I don't think that merging is a solution. From what I saw above, the DMs that share the same definitions have nothing in common (regarding the translations). The solution seems to be to delete the faulty DMs from the database (I think the ones above are already deleted from the web interface).
The reason why I'm still waiting a bit is that I am changing the way to access DM, so that the links will not be "DefinedMeaning:(7591)" but rather "DefinedMeaning:7591" (as you wrote earlier). DMs are only numbers after all, and the text that is shown next to the number is sometimes wrong and has led to some confusions in the past. The php code for that is ready, I just need to run a script on the database to move the DM pages and talk pages. However, my private life is quite busy at the moment, so I'm not sure how long that will take. --Kip 10:03, 2 April 2012 (CEST)
I don't think that's true, because both 7765 and 7767 can be examined in the web interface (or did you mean something else by "deleted from the web interface"?). More importantly, where 7765 has only the (IMO valid) expression "minimal crew", 7767 has three others. So in this case, deleting 7765 would remove valid information.
Regardless how we fix this, can I assume that afterwards, there will be no more DefinedMeanings sharing a single meaning_text_tcid? In other words, can we add a unique constraint to the uw_defined_meaning table on the meaning_text_id column? László 07:41, 3 April 2012 (CEST)
Ok, forget my remark, I picked the wrong example.
Yes, we could add a "unique" on the meaning_text_id column. --Kip 09:15, 3 April 2012 (CEST)
Fixed! I removed the faulty entries from uw_defined_meanings and from uw_objects. --Kip 23:12, 17 June 2012 (CEST)
Awesome! My belated thanks. Onwards to the next inconsistency :) László 23:46, 30 July 2012 (CEST)

Alternative organization for Example Sentence[edit]

I think an example sentence is as important as a definition in giving the sense of a DM. Sometimes two definitions can be written for an Expression, and because they are not stated the same way it may not be clear what the creator of each entry meant. (Example: is "one: An unspecified individual" the same sense as "one: Any person in general, including the speaker"? I couldn't decide.) Example sentences would help us decide.

But more philosophically, I think that the sense of a word is the same thing as its correct usage, that is, a computer program that can use a word correctly (in translating from another language, for example) does not need to "understand" it, as long as it conforms to the patterns of usage observed for that word. I assume that OmegaWiki's design goals include the facilitation of computer-supported applications.

When I write an example sentence in English for a DM of an expression, I try to translate it to Turkish as well, to document how the same concept is expressed in the two languages. However, there is nothing to indicate that the example sentences that I write are translations of each other. Sometimes I write two example sentences each, and it is not necessarily clear which sentence is the translation of which one.

I suggest that the example sentences be organized differently in the relational database of OW. Here is how it would work in practice. Say you enter an example sentence Sent1 for a SynTrans ST1 in a language L1; after you save it, you can go back to this sentence and write an associated sentence Sent2 for it and select another SynTrans ST2 (in language L2) associated with the DM. When you do that, the language L2 of the ST2 you chose will be associated with Sent2, and Sent2 will be associated with ST2. Next time you look at this DM, you will see Sent1+L1 and Sent2+L2 associated with ST1, and also Sent1+L1 and Sent2+L2 associated with ST2. (I hope this is clear!) I think the way to implement this idea is to have a SentenceMeaning entity that can be associated with one or more Sentence entities (keys: sentence_text and lang). The SentenceMeaning entities will have a many-to-many relationship with Syntrans entities.

This way you can see which example sentence is meant to be a translation of which one in a different language.

--InfoCan 17:09, 22 March 2012 (CET)

Yes, also related to this idea Functionality_wanted_..#Namespace_for_sentences and also this International_Beer_Parlour/Archive20101106#Example_sentences. --Kip 18:30, 22 March 2012 (CET)
Reading the previous postings on this idea, I noticed the suggestion that a given sentence can be associated with more than SynTrans, which is also a great idea. This way you would accumulate a large number of manually parsed sentences, a great resource. --InfoCan 19:01, 22 March 2012 (CET)


You may have noticed that I am deleting lots of DMs at the moment. I'm beginning to wonder whether I haven't deleted more stuff than I have added... However, I think it is necessary to delete stuff that is bad/useless/confusing because it makes Omegawiki look bad to visitors and diminishes its usefulness. Better to have a small, well-maintained database than a big one full of messy data.

Most stuff I deleted belonged to GEMET, the environmental database which served as the starting point for Omegawiki. It contained many DMs not suited for a dictionary and faulty definitions and/or translation. Well, it still does. Clean-up isn't finished yet.

Another thing I am deleting at the moment is the class conjugation. I'm very sorry for all the work that went into it, but this isn't how it's supposed to be. Inflections (e.g. conjugations, declensions, plurals) are definitely a feature that we want, but it needs to be implemented via software. One of the conjugations DMs I deleted had the definition "Past participle of possess". The problem is that "possess" has several meanings (for example: to possess a car, to be possessed by a ghost, to have sexual intercourse with) and you can't add translation without knowing what exactly is meant. And I'm wondering if it even a good idea to translate inflected forms. --Tosca 19:39, 24 March 2012 (CET)

You are right. Regarding inflected forms, for example, the simple past tense of lie is lay (last night I lay in bed unable to sleep), while lay in the present tense has a different meaning (I now lay the baby on the bed). --InfoCan 20:28, 24 March 2012 (CET)
You have my support! Thanks for doing that boring job that nobody dares/cares doing. --Kip 21:14, 24 March 2012 (CET)

Regarding GEMET, I notice many expressions whose meaning is simply the sum of the meaning of their component words, such as "agricultural_policy", "abandoned industrial site", or "atmospheric ozone". I would like to help, but want to make sure we have the same criteria. Do you delete these types of DMs? --InfoCan 02:33, 2 April 2012 (CEST)

Meta expressions in definitions[edit]

On the page Help:Defining_a_new_word it says "Do not use "meta-expressions" such as "the word" or "the expression". However, there are some words that cannot be defined without doing that, like "and" (A conjunction to separate the last item in a list from the previous items). Also, some definitions need to be given at a meta-level, indicating the meaning in relation to who is saying it (for example, "this": Something near the speaker that he or she is refering to). It seems to me that if such "meta" definitions are unavoidable, they should be displayed differently from a "normal" definition, otherwise there could be ambiguities ("podium": The thing a speaker stands behind. The "speaker" mentioned in this def is not the speaker of the word, it is a speaker in general giving a lecture). My understanding of a 'normal' definition is one that can substitute for the word it defines and the sentence that used the word still makes sense (e.g., "car": A vehicle with four wheels. Substituting this definition for "car" in the sentence "His car can go very fast" results in a sentence that still makes (almost) sense.). I propose that if a definition does not work that way, then it is a "meta-definition" and should be written inside square brackets (for example, "and": [a conjunction to separate the last item in a list from the previous items]). This would provide some consistency and probably make OmegaWiki more useful for computer-supported linguistic applications in the future. --InfoCan 15:20, 28 March 2012 (CEST)

We had similar discussions (and conclusions) here DefinedMeaning talk:no (5576) and above in this page (see the section about Chinese characters).
So I agree to indicate these definitions with square brackets, and amend the page Help:Defining_a_new_word to reflect this. --Kip 11:17, 29 March 2012 (CEST)
I agree too, but in many cases where a meta-definition is used, this could be and, to my mind, should be avoided. In InfoCan's 2nd example: "this": The thing near me that I am refering 19:33, 6 December 2012 (CET)

Agreed that marking the Meta Definitions is a good idea and using square brackets is of cource a lot better than no distinction. Yet on the long run, I believe that marking should be done in the database, and I expect there to be more than "plain" and "metadescription"s after a while. Likely, a structure similar to that defining grammatical properties should be employed so as to supply possible description types.

WMF support?[edit]

I am copying the following comment from Meta:strategy to here as it is of interest to the community. --InfoCan 01:23, 2 April 2012 (CEST)

A comment from me in my role as WMF Trustee: OmegaWiki is clearly part of the core Wikimedia mission, and could be suppported by the WMF if that is desired by the community here. It sporadically comes up as an issue that we should consider - most recently at the Board meeting we just concluded in Berlin. Warmly, Sj 07:51, 1 April 2012 (CEST)
  • As one member of the community here I would like to state my desire for WMF supporting OmegaWiki. I would like to see OW develop to its full potential, and I can see that with the limited resources that are available, it will take a long time for that to happen. I can feel that once a critical stage is reached (a faster server response time, more functionality, more content) Omegawiki will become appealing to more volunteer developers and content creators, as well as more end-users. OmegaWiki needs support to reach this point as soon as possible. I believe that WikiMedia Foundation is the best suited to provide this support. OmegaWiki aims to make lexical information freely accessible to all, in a non-commercial way, and this goal is one that is already supported by WMF with the Wiktionary. I also believe that WMF has the wisdom to appreciate that OW represents the next generation of Wiktionary. --InfoCan 01:31, 2 April 2012 (CEST)
  • Same as InfoCan ;-) --Kip 10:05, 2 April 2012 (CEST)
    • I was asked off-wiki whether the above could possible have been an April Fool's joke :-O The answer is, no. The date was a coincidence  :-) I am working to revive the new project creation process. Could interested people here please choose a single wiki page to use to consolidate related discussions? OW is the most obvious project to start with. Sj 04:48, 3 April 2012 (CEST)
      • Done, copied to Meta:WMF support. Further discussions will take place there. --InfoCan 20:08, 3 April 2012 (CEST)
      • See further developments there. --InfoCan 16:44, 25 April 2012 (CEST)

Meta:Requests for deletion[edit]

I made a partial list of GEMET words (just those starting with the letter A) that I thought should be deleted. Since I am rather new here, I didn't want to delete them all without getting some feedback and thought it would be more efficient to review them in bulk rather than place {{attention}} templates for each DM separately. They are listed in Meta:Requests for deletion (RFD). I copied that page from Wiktionary and adapted it to here, as I thought we would eventually need such a page here also. Feel free to further modify the RFD page as you see fit (or discuss its design/functionality in its Discussion page). --InfoCan 20:30, 10 April 2012 (CEST)

Spanish: Ser and Ester[edit]

Could somebody who speaks Spanish please improve the definitions of the verbs ser and estar and provide example sentences that distinguish their meanings? A usage note would be useful, as in the Wiktionary [16]. --InfoCan 20:10, 11 April 2012 (CEST)

The same phenomenon occurs in Portuguese. I'm not sure how to define it, but I will try to describe it here.
  • ser is to be in the sense of a property of the subject, usually something intrinsic to it, somewhat permanent or long-term. For example, you would use ser to say that I am Portuguese, because that's an "attribute" of myself, not a transitory state. The same would occur in less obvious and not always univocous cases, such as saying I am married (in the sense that I'm a married person).
  • estar is to be in the sense of a somewhat transient state of the subject, such as whe I say that "I am tired".
Some examples:
I am blind: you would use "ser" to state you are a blind person, but would otherwise use "estar" if you are temporarily blind (such as after an explosion, or after having your eyes pepper-sprayed :))
I am white: "ser" for the racial context, but "estar" if you suddenly realize you are covered in white paint
I am Bill: only "ser" is admissible here
I am standing: only "estar" is admissible here, as a transient state (standing is not a characteristing of your being)
I hope this helps defining the two verbs. Malafaya 00:07, 13 April 2012 (CEST)
Thanks, I think I understand. It seems like "estar" is the direct equivalent of "to become" or "to have become" in English, like "I have become blind" (or white, or standing), but if you don't use that construction and just use "to be" then it becomes ambiguous and you can't really distinguish between these two senses in English.
This information should be stored somewhere and linked to the "ser" and "este" entries in Spanish and Portuguese. Doing this four times seems rather inefficient, if anybody were to correct my text, they would have to do four times. A better solution may be to enter this information in one centralized place and give links to it from the usage fields of these words. For now I'll do create a Help:"Ser" and "este" page and link to that page from the Portuguese and Spanish "ser" and "este" entries. When Kip returns from vacations he may suggest a better solution... --InfoCan 22:12, 13 April 2012 (CEST)
No, "estar" is not really "to become", but really (almost always) translates to the verb "be". There is another verb to say "become" in Spanish, which is "volver", and "I have become blind" would be translated with that verb, and not with estar. Other languages like French (être) or German (sein) don't make the difference between ser/estar (which makes it a difficult verb to use when you are not a native Spanish speaker).
For the moment, I find no better solution that what you did with Help:"Ser" and "este" and linking it from the usage note. We should consider making the "usage note" field multilingual, but anyway, the field is not really adapted to long clarifications, so having it on an extra page seems better. --Kip 22:41, 18 May 2012 (CEST)

Visual dictionary[edit]

Expression:pedalExpression:crank armExpression:chain ringsDefinedMeaning:chain (6665)Expression:front derailleurExpression:rear derailleurExpression:cogsetExpression:rear brakeExpression:seat stayExpression:seat tubeExpression:down tubeExpression:top tubeExpression:seat postExpression:saddleExpression:handlebar gripExpression:head tubeExpression:shock absorberExpression:front brakeExpression:forkExpression:hubExpression:spokeExpression:rimExpression:tireExpression:valveExpression:chain stay

Commons has a number of diagrams (such as [17][18][19][20]) which give visual definitions of certain technical terms. I thought such pictures might be useful on OmegaWiki. I am not sure of how best to implement the idea, I am hoping to get ideas from the community. If you scroll down on the links given above, you can see that each picture has versions labeled in many languages, and also one version with just numbered labels.

Here are some ideas on how this could be implemented.

  • Place all versions of these pictures on one page.
  • Place the version having the numbered labels, and below have a large table where each column corresponds to a label and each row to a language. The intersection cell would have the expression of the labeled part in that language.
  • Make the image with the numbered labels a clickable image. Clicking on a label would take you to the DM of the labeled part, where you can read the definition and the SynTranses.

What do you think? How should it be implemented? --InfoCan 15:49, 1 May 2012 (CEST)

There is a similar project at the English Wiktionary,
where they have added clickable text on top of the images. Since we are multilingual, we would probably need to use numbers instead of words. This is my favorite solution in terms of how nice it looks. However, if you edit the page, you'll see that it is not really easy to edit... I am not sure if MediaWiki is the best tool for this. We could also install any other tool that is not MediaWiki which makes it easy to define clickable zones in an image anyone?.
At Wiktionary, they have also implemented what is your second solution . I think it does not look as nice, but it is at least much eaasier to edit. --Kip 22:54, 18 May 2012 (CEST)
Or maybe this extension --Kip 22:56, 18 May 2012 (CEST)
I think the ImageMap extension will work nicely. The Wikipedia has a tutorial on how to create imagemaps. There is a tool called ImageMapEdit [21] that generates the code for the imagemap as you click on regions of your image. To use it, you need to place the following line
in your common.js page (for example User:InfoCan/common.js). Kip, can we give this a try? --InfoCan 16:25, 12 June 2012 (CEST)
I have installed the ImageMap extension.
It seems to work fine User:Kipcool/bakasabl.
At the same time, I have also installed InstantCommons, so that import of images from commons is done automatically when you refer to the image with Image:PolierMartinWombwellZoffany.jpg.
I have also upgraded the version of php, so if you see something unusual, tell me. --Kip 19:49, 12 June 2012 (CEST)
Thanks. The above bicycle picture is now an imagemap. Clicking on the red dots on the image takes you to an [[Expression:...]] page. This is actually incorrect, the connections need to be made to [[DefinedMeaning:...]] pages. However, the needed DM pages do not exist for the moment, because of the specialized meanings... --InfoCan 20:23, 12 June 2012 (CEST)
This is great :)
I think we need to create a special namespace ( [Visualdictionary:...]? maybe a bit too long?), where such images would be displayed in full size. --Kip 19:13, 14 June 2012 (CEST)
How about naming it just [[Visual:...]] ? --InfoCan 20:29, 14 June 2012 (CEST)
Ok, "Visual" namespace created! --Kip 17:08, 15 June 2012 (CEST)

What to do with GEMET definitions that are not suitable for OmegaWiki?[edit]

There are a number of definitions that were imported from GEMET that are proposed for deletion at Meta:Requests for deletion. While a few of these compound terms may be kept, most seem to be inappropriate for OmegaWiki because their meaning is the sum of the meaning of the words that make them up. Others give multiple-sentence encyclopedic information about their subject instead of a simple definition. Yet, deleting them seems a waste to me, because there is useful information there. They represent parallel corpuses (corpi?) that would be useful for training natural language processing software. I was wondering whether those GEMET definitions that are decided to be not good for Omegawiki should be moved to a different place in OmegaWiki so that information is not wasted. Perhaps a "Corpus" namespace could be created to store them? --InfoCan 19:12, 2 May 2012 (CEST)

Gemet is a corpus that exists on its own ( ). So, it is not a problem to delete the definitions that are not appropriate for OmegaWiki, because they are still at Gemet (which is also evolving on its own, last version is dated 2010, which is later than what was imported).
The multiple-sentence encyclopedic definitions should be simplified to a typical short single-sentence OmegaWiki-like definition.
Gathering parallel corpuses for training NLP is not an aim of OmegaWiki, there are many other projects with that scope. There are already many things we want to do, I think we should exclude this one ;-) --Kip 23:13, 18 May 2012 (CEST)

Mail address[edit]

Is it possible we get an e-mail address with as domain?

In my case it would be (or klaasv in front of the @) Cheers, Klaas V 16:53, 6 June 2012 (CEST)
It is probably possible, but I don't know how. If you find me an how-to to do that for a debian server, I can give it a try. --Kip 17:31, 6 June 2012 (CEST)
I know how you can define e-mail addresses on a debian server, but it depends a lot on the mail system installed, if any. :-( No simple generic way. --Purodha Blissenbach (talk) 23:51, 28 December 2012 (CET)

Mythological creatures[edit]

For the translations of "hobgoblin" (a creature from British folklore), the terms "kobold", "klabautermann", "duende", "kwelgeest" and "gobelin" were entered as translations. I deleted these terms because although these fictional creatures are similar to the hobgoblin, I believe that similarity should not be considered the same as identity for translations.

I would like to get feedback from the community here regarding a policy on similar cases. I think that translations for such fictional characters should be based on documentable attestations. For example, in the Turkish translation of J.R.R. Tolkien's The Hobbit, "hobgoblin" was translated as "hobgoblin", so this character that is foreign to Turkish culture is now known as hobgoblin in Turkish. Therefore, even though there are characters in Turkish folklore that are like hobgoblins, the correct Turkish translation in OmegaWiki should be, not one of those, but "hobgoblin". Does this line of reasoning make sense? --InfoCan 17:49, 7 June 2012 (CEST)

I agree we should check translations if possible like you did. If it's not possible what is the problem to leave it like it is and believe the original editor: WMF calls this: "Assume good faith". Klaas V 17:21, 19 June 2012 (CEST)
Of course I assume good faith, please don't take my comment as a criticism. I wanted to raise awareness on this topic, expressing my view that similarity should not be considered equivalent to identity when translating. --InfoCan 15:38, 20 June 2012 (CEST)

I have no opinion on the ones you deleted due to lack of knowledge. Yet I am not entirely happy with deleting, since this makes us loose information. The problem cases can sometimes be solved using the "not identical" flag and giving a somwhat slanted or imprecise "translation" based on similarity or so. But we shall encounter cases where there is no real translation availabe, or a "translation" has to be not-an-expression, but rather some sort of explanation which you would not use in the way, a translation could be used.

With an unidentical "translation", the definition parts of the two involved DMs would serve to clarify as to how concepts differ and how far they are apart, if the definitions are well done.

With no translation at all, you can and should still go ahead and translate the definition part to the language lacking a proper word. If that is not sufficient, a good explanation can and should imho be given as an alternate definition. Omegawiki currently does not provide for a way to state "no translation" - Not having a spelling for the target language would rather be interpreted as "no translation yet" which is imho somewht unfortunate. How about extending the choice of "exact", "not identical" with "none known" (accompanied by an empty spelling) ? --Purodha Blissenbach (talk) 14:29, 29 December 2012 (CET)

some thoughs on the structure used[edit]

I have been playing around a bit with the concept here, and at home (installed a sandbox version to test it).

And I wonder if there isn't missing an intermediate level concept, or grouping concept that would solve several of the problems and glitches.

Curently there are Expressions, DefinedMeanings and SynTrans; and actual grammatical info is attached to SynTrans, as well as graphical variations (or completly new Expressions created and added in parallel to DefinedMeanings, as if they were synonyms or translations instead of graphical variants.

Actually, the DefinedMeaning concept is a very good one for a multilingual translation base; but it is not as classical dictionnaries work (so, it makes this project unsuitable to eg produce a printed version). Classical dictionnaries don't start with a concept of Expression as defined here, but with a concept that I could call "LinguisticExpression", that is form+language (current "expression") + grammatical kind + etymology (that last being optional, but allows to make appart different entities with same form, language and grammatical kind).

I think it would be a good idea to expand current "expression" to include grammatical info and etymology.

We could then have a name space for raw visual forms (it could be called "Text:") and have "Expression:" for the extended expressions; the naming could then be made much like dictionnary entries, eg:

  • Text:xxxxx
  • Expression:xxxx_(ll)_ggg or Expression:xxxx_(ll)_ggg_N

with xxxx the visual form, ll the language code, ggg a (language specific) grammar info, and N a number if needed to separate two or more otherwise identic expressions.


  • Text:lettone -> Expression:lettone_(it)_sm Expression:lettone_(it)_agg (sm=masculine substantive, agg=adjective)
  • Text:picård -> Expression:picård_(wa)_on_1, Expression:picård_(wa)_on_2, Expression:picård_(wa)_addj (on=masculine substantive, addj=adjective)

(noun picård 1 has same etymology as the adjective picård: "from Picardy", while picård 2 comes from verb "piker")

A call to Text:xxxx should show, grouped by language, all the expressions; when clicking on a language, it should go to "Expression:xxxxx_(ll)", which is a subset of the Text:xxxxx limited to one language. and each complete Expression:xxxx_(ll)_ggg or Expression:xxxx_(ll)_ggg_N would actually be a classical dictionnary entry, with the various meanings (various DM) attached.

I know all that data is already there (or could be added), but it is mainly the way to display/access it that is cumbersome; the grammatical info is a core concept, but currently it can only be added or viewed at the very end of the display tree, at the SynTrans level.

Srtxg 00:22, 9 June 2012 (CEST)

I agree with you and believe that the solution should not be complex from a programming perspective. As you said, all the information is there, they just need to be better organized. This can actually be easily achieved by adding a "GROUP BY..." clause to the SQL code that displays the query results. Currently the results are only grouped by language, but otherwise all entries for a language-expression combination are listed by order of record creation time, or some other obscure internal logic. The way this should be done is as follows. Firstly, DMs having the same etymology should be listed together (for example, the English word "do" in the musical sense (do-re-mi-...) has a different etymology from "do" in the sense of performing an action). Secondly, DMs having the same part-of-speech (nouns, verbs, etc.) should be listed together. Thirdly, those having the same part-of-speech type should be subgrouped according to usage (especially those that are colloquial, pejorative or slang should not come first).
I realize that one problem with the above idea is that etymologies should be "normalized" in the database, meaning that, for example for the English expression "do", 35 of the meanings should have exactly the same etymology ("first person singular of Old English 'don'", etc.) and one of them (about the first tone of the solfège) should have a second etymology. This will require the creation of a new database table about etymologies and a mechanism of selection from existing etymology entries. --InfoCan 20:54, 10 June 2012 (CEST)
As a first step, we can start by grouping by part of speeches, where the part of speech would clearly appear as a hierarchical level, similarly to what Wiktionary does. Who wants to do that?
Yes, let's at least do this. --InfoCan 20:27, 14 June 2012 (CEST)
Grouping by etymologies might be a bit more complicated. Another possibility would be to let the users do that grouping (or ordering) manually, for example by (1) adding a column in the syntrans table called "group number", every syntrans with the same group number would be displayed together - the user could specify for each expression, which definition belongs to which group ; or (2) adding a column named "display order" which would be numbers, the syntrans with the smallest number is shown on top, the one with the largest number at the bottom, and the user could drag-drop in the interface to change the display order.
About whether we do that in one "Expression:" page, or subdivide it as suggested by Srtxg ("Expression:xxxx_(ll)_ggg_N"), I don't know ;-) but at least I like the idea of "Expression:xxxx_(ll)", I think it is better than the current solution with "&explang=85". --Kip 10:48, 11 June 2012 (CEST)
Oxford English Dictionary (OED) is organized roughly the way Srtxg suggests, except that identical words with different etymologies have separate pages, but on one page, there can be multiple definitions if they are all derived from the same root. This seems logical to me. I am not sure whether you all have access to OED, so let me give an example. A "quick search" for "do", gives:
1. D.O. in D, n.
...District Officer....
2. do, n.1
...Commotion, stir, trouble, fuss, ado; usually in phr. a deal of do. Obs. (Common in 17th c.)...
3. do, n.2
...The syllable now commonly used in solmization instead of ut, to denote the first note (key-note) of the scale (movable do); or in some cases the note C,...
4. do., n.3
...Abbreviation of ditto...
5. do, v.
...To put, place....
Each of these five choices links to a separate page (each page has a unique identifier in the form of a number, rather than something like "Expression:xxxx_(ll)_ggg_N"). You click on, say, choice 2 above, and go to "do" as a noun, sense #1, and there find five meanings of it. The page for each entry starts with the etymology (for choice #2, it is a redirect to do the etymology of "do" as a verb). I like this level of organization.
If it is going to be too hard to implement an etymologies table for now, I think I would prefer Kip's alternative (1) of adding a column in the syntrans table called "group number". --InfoCan 19:37, 11 June 2012 (CEST)

I understand that people are not content with many presentational matters here (so am I as well) but I cannot understand a discussion about entering display ordering by letting users enter their preferred positions in a list by assigning numbers to syntrans entries. Since such numbers are not objective nor bear any linguistic relevance, they're bound to be subjects of edit warring. If we need sorting orders, let users have their own ones in their preferences, for instance, and base them of objective data, such as part-of-speech, or similar. --Purodha Blissenbach (talk) 14:46, 29 December 2012 (CET)

Organization of the Visual namespace[edit]

I tried three alternative designs for how the Visual namespace might work. See visual:index1, visual:index2 and {visual:index3, visual:index3/fra, visual:index3/tur}. Which do you think works better? What do you think of either of the page naming systems, can we improve on them? Ideally the system should be understandable to non-English speakers. --InfoCan 23:43, 16 June 2012 (CEST)

I like 1 and 3... can't decide between the two ;-)
option 2 would probably not be practical for the user interested only in one language.
Just some thoughts... We could also have an automatic translation when hovering with a language selector somewhere (see below). Unfortunately, what I suggested would not work well because the user would probably want to see a translation in a language that is different from the language of his interface. At the moment, I don't know how to implement that in MediaWiki. It would be easier with an external website... (translations could be obtained via the omegawiki api)
--Kip 19:15, 17 June 2012 (CEST)
I think option 3 will scale better, that is, accommodate better large numbers of such images. Then, we can organize them into topics such as shown in option 3, and if the number of images increase even more, we can give a "more..." link from each topic section to a subpage. Option 1 has no text in it, in order to be universally understandable, but it seems difficult to express concepts like "biology" or "more..." with just pictograms. Also, Option 3 uses the page naming conventions of the Mediawiki Polyglot extension, already in use for pages such as Help:DefinedMeaning/fr. So, I favor option 3, unless a graphically talented person can persuade us that option 1 can be made like option 3 but using only pictograms. --InfoCan 16:40, 18 June 2012 (CEST)
Do you think we could use something similar to the language selector at Wikimedia Commons? For example on that page [22], below the image, you can select your language and the description below is changed instantly. --Kip 18:55, 18 June 2012 (CEST)
You mean option 3 with the language selector? Yes, that would be a better solution, we wouldn't have to maintain versions of the page for each language. Can the default selection on the selector be that of your preferred language? --InfoCan 19:35, 18 June 2012 (CEST)
Yes, option 3 with selector
Can the default selection on the selector be that of your preferred language? <= I think it is meant to be that way. At least at commons I have it in French by default.

DefinedMeaning titles only with numbers[edit]

For several good reasons, I am about to replace DefinedMeaning titles, for example from DefinedMeaning:four_(5448) to DefinedMeaning:5448.

The good reasons are that the title can be misleading for example when a DM has been changed to represent another concept, such as DefinedMeaning:four_(5448) which actually describes the number "five". The pseudoname can also be of limited use if it is e.g. in Japanese, and displayed as an ugly url if the japanese font is not installed. Another good reason is that parenthesis in an url is not a good idea.

When editing the page, you would still see a translation in your language in the page title, as is done currently. For the above, you would see "DefinedMeaning:5448 - five" as a page title.

Now, my only remaining problem is that in the recentchanges, you'll only see numbers, so that you would actually have to click on it to have an idea of which concept was edited. So:

  1. we don't care?
  2. Should it automatically adds a word representing the DM (preferably in English) in the summary field of recentchanges?
    this is easy to implement. However, summary are displayed far to the right, and it would be in only one language.
  3. Create a magic java functionality that displays a translation in your language when you put your mouse cursor over the "DefinedMeaning:5448" line in the recentchanges?
    A bit more complicated to implement. However, this would have the advantage of being displayed in the user language, and I could enable it also for other pages of the wiki. It could be useful for example for the Visual dictionary.
  4. Or something else?

--Kip 18:45, 17 June 2012 (CEST)

Thanks for fixing this fundamental problem. Regarding above choices, (1) We do care :-) . (2) This should be implemented immediately as it is necessary for following recent changes and is easy. (3) This should be implemented too, to make OmegaWiki a multilingual environment. I suppose it would work similarly to the WikiGadget "Navigation popups"? --InfoCan 16:19, 18 June 2012 (CEST)
Yes, something like "navigation popup", but it would load only a translation in your language, so that it would be faster. If you have it installed, we will have to make sure that they don't conflict.
So, even if I implement (3), you still want (2) as well? They were meant as alternatives ;-) But of course, I can also implement them together, no problem. --Kip 18:59, 18 June 2012 (CEST)
If you can implement (3) quickly then you don't need to do (2). If it will take weeks/months to prepare it, I thought it would be good enough to have (2) available right away, since all current users here seem to know English. --InfoCan 19:38, 18 June 2012 (CEST)
I am not sure how long it will take... That's always the problem with OmegaWiki, things that seem simple to implement are actually not that simple because the code is complex and undocumented...
So, I'll give it a try, and if it becomes complicated I'll go for option 2. --Kip 21:39, 18 June 2012 (CEST)

Change term "DefinedMeaning" ?[edit]

While you are about to make a fundamental change in the display of page names, I have another suggestion. Could we change the name "DefinedMeaning" to something more meaningful? I can tell from its mixed capitalization that DefinedMeaning is a variable name in the database program but for non-programmers the spelling is not natural. Even if you broke it up as "Defined meaning" it is an oxymoron (can you have an undefined meaning? isn't definition a meaning?). Regardless of what you call it internally, to the end-user it is obviously just a definition, so why not have the page name and the URL reflect that? So, instead of for example DefinedMeaning:four_(5448), let's call it Definition_5448. --InfoCan 15:59, 19 June 2012 (CEST)

I am not against a name change, but for me a "definition" is a sentence that you write in a language that defines the "DefinedMeaning". Each definedmeaning has several definitions, one in each language.
I would rather call it Concept. So, Concept:5448.
I know that GerardM was always opposed to call it a concept because he said DefinedMeaning is something different, but don't really agree on that.
The equivalent structure at WordNet is called a Synset.
Of course, there is no point in changing the name internally, so it'll still be called the same. But, changing the name in the interface is a good idea as far as internationalisation is concerned. "SensDéfini" in French is awful, and I guess it's the same for other languages. --Kip 16:49, 19 June 2012 (CEST)
It is awful in Turkish too. OK, how about "Meaning" then? According to Wikipedia "meaning" means linguistic content [23], as opposed to "expression", which is a particular way of expressing an idea [24]. In relation to definition, we can say that a Meaning (in an abstract sense) can have multiple Definitions (in a concrete form, as a sentence) in different languages. --InfoCan 17:03, 19 June 2012 (CEST)
"Meaning" would be ok, but I still prefer "Concept" ;) --Kip 20:20, 19 June 2012 (CEST)

And while we are discussing this, let's talk about "SynTrans" also. I cannot translate it to Turkish, and leaving it as it is is unpronouncable in Turkish. Could we just call it "Term" in the user interface? So, formally, in the documentation we can say that 1) a Meaning has a one-to-one relation to Definition-Language entity pairs, 2) a Meaning has a one-to-many relation to Term-Language entity pairs. --InfoCan 17:28, 19 June 2012 (CEST)

"SynTrans" was named so because it is a combination of "synonym" and "translation". However both of these concepts imply a relationship to a given word. The only indication of what that given word is is the name of the DefinedMeaning page (like DefinedMeaning:four_(5448)), and if the indication is removed, there will be nothing left to which the words in the SynTrans list are a synonym or translation to. In fact, currently, the source word (like "five") is among the among the words in the SynTrans list. So, logically, that list should be called something else, like "signifier" perhaps, but that sounds too technical. "Term" seems an internationally understandable word to me. --InfoCan 17:40, 19 June 2012 (CEST)

Do we have the term "SynTrans" in the user interface? --Kip 18:47, 19 June 2012 (CEST)
It is not. But it is a term used in Help:SynTrans. Because everyone has read that page, it has become part of the jargon used here, to refer to the words in the Synonyms and Translations list. A more easily translatable word for this database entity would be nice. --InfoCan 19:56, 19 June 2012 (CEST)
I think it would be better to keep it in English. I don't really see a good term that expresses what a "SynTrans" is. In my understanding "Term" is the same as "Expression". We don't really have a word that says "one particular meaning of one particular word". --Kip 20:20, 19 June 2012 (CEST)
"Term" and "expression" are not the same thing. Expressions are words or groups of words. You can talk about "ambiguous expression", that is, an expression can have more than one meaning. A term on the other hand is defined (by the OED) as "any word or group of words expressing a notion or conception, or denoting an object of thought".
SynTrans is a programmer's name for a database table and/or a program variable but I believe it does not need to be used by non-technical end-users. The term is currently used at the user interface (Help:Part_of_speech) and in the help documentation (Help:SynTrans) and so it is part of the jargon of OmegaWiki. However, it cannot be translated to most other languages in a natural way.
To an end user, SynTrans appears to be one of the words in the "synonym or translations" list for a DefinedMeaning. I am suggesting that a common word that means the same thing, "term", already exists in English and other languages. "Term" can be used instead of "Syntrans" in the user interface and documentation. Simplifying the jargon of OmegaWiki is just one step that can be made to make it more accessible. --InfoCan 16:33, 20 June 2012 (CEST)


Could we add "Nautical" to topics please? --InfoCan 18:02, 21 June 2012 (CEST)

Done! --Kip 23:45, 21 June 2012 (CEST)

Identical meaning[edit]

The removal of the "Identical meaning" checkbox left some erroneous info. For example, in DefinedMeaning:aunt_(5591), the three Georgian words seem synonyms of each other while they represent in fact three diferent kinship relations: mother's sister, father's sister, uncle's wife. How to work around this at this point? Malafaya 18:16, 3 July 2012 (CEST)

Imo, the translation should be moved to the correct DM. We have already DefinedMeaning:hala (1372531), DefinedMeaning:teyze (1372595) and DefinedMeaning:yenge (1372601). I have added them as hyponyms of DefinedMeaning:aunt_(5591) (they were already in "incoming relations"). --Kip 18:50, 3 July 2012 (CEST)
Maybe a way of marking such DMs as obsolete or something would be in order. It makes no sense for people to work in these. Ultimately, they could be deleted when empty. Malafaya 18:57, 3 July 2012 (CEST)

The removal of the "Identical meaning" checkbox is not acceptable, even if the non-identical translations should be removed. Nobody can find those translations now because they appear as all other translations. There are many other examples than the above mentioned ones. On the other hand in some cases there are no expressions in a language that match exactly but close enough to use it for that defined meaning. Maybe those should have their own definition but they should still be linked to the non-identical (but close) definitions. --Ortografix 23:08, 1 October 2012 (CEST)

Category name for image maps[edit]

Which sounds better: Category:Imagemaps, Category:Schemas, Category:Illustrations, or Category:Diagrams? --InfoCan 17:40, 9 July 2012 (CEST)

Category:Visual Dictionary ? --Kip 19:10, 9 July 2012 (CEST)
The page Visual:flower currently belongs to Category:Biology imagemaps, I think it should be changed to something more familiar because "imagemap" is not a widely used term. We also need to think about whether the term we use goes well with subdivisions of the main category. For example, which sounds better, Category:Biology visual dictionary or Category:Biology schemas? --InfoCan 19:31, 9 July 2012 (CEST)
What you guys think about simply Category:Pictures eventually abbreviated to pix [perhaps this would be exaggerated bandwidth saving ;-)] Klaas V 14:04, 11 August 2012 (CEST)

Holonym usage[edit]

Can a term have two holonyms if one of them is part of the other? For example, is it correct to say that the knee has the holonyms of "leg" and "body", or should it be just annotated as holonym=leg? --InfoCan 18:00, 16 July 2012 (CEST)

My idea (but I think no "official rule" for relation annotations exists) was that we annotate only with direct holonyms (and direct hypernyms, etc.), similarly to what is done on Wordnet, so that other larger holonyms can be inherited automatically, and holonyms can be browsed as a tree (also like what is done at Wordnet), but this has not been programmed yet, it is just in my head. --Kip 19:06, 16 July 2012 (CEST)

DefinedMeanings with no definition[edit]

Consider the following SQL statement:

select dm.defined_meaning_id, e.spelling from uw_defined_meaning dm left join uw_expression e on dm.expression_id = e.expression_id where meaning_text_tcid = 0

In words: all DefinedMeanings, with their defining expression, that have no definition. This gives 157 results:

DefinedMeaning:GEMET_Environmental_Thesaurus_Relation_Types_(2) DefinedMeaning:Institutionen_(5215) ... DefinedMeaning:urbano_okolje_(5422)

Incidentally, none of these have SynTranses that have not been removed, because the following query returns "0":

select count(*) from uw_defined_meaning dm left join uw_expression e on dm.expression_id = e.expression_id left join uw_syntrans st on st.defined_meaning_id = dm.defined_meaning_id where meaning_text_tcid = 0 and st.remove_transaction_id = 0

Can we simply remove these and the corresponding (removed) syntranses? Are there any other foreign keys that might reference these? The various *_attribute_values tables through uw_object? László 00:22, 31 July 2012 (CEST)

Expressions without add_transaction_id[edit]

Are these expressions used or are they part of the early experimental stage of Wiktionary Z? Hiong3-eng5

They are used, but were created in the early stages of OmegaWiki. I am not sure why add_transaction_id = 0, maybe it was before "add_transaction_id" was introduced, or it was a bug in the software. --Kip 10:16, 16 August 2012 (CEST)

Policy to create separate definedMeanings or not[edit]

Everybody is invited to participate to that important discussion: Policy to create separate definedMeanings or not, after having read at last the 2 previous ones: Need for a policy to produce definedMeanins and Don't verbs and corresponding nouns of action express a same meaning?. Having a look at the others discussions of the same page would be a good idea too. 09:22, 27 August 2012 (CEST)

derivational relationships[edit]

The Wiktionary has a "derived terms" section in some of its entries where words that are derived from the given word are listed. For example, the entry "-cide" lists words like "pesticide", "homicide", etc., and the entry "pest" lists words like "pesticide", "pestilence", etc. It seems to me that this could be implemented here at Omegawiki in the same way as how semantic relationships are currently done. The software could also automatically populate a "derived from" field in the target word, using the same mechanism that currently populates the "incoming relations" field. For example, for the expression "pesticide", the incoming relations would list "derived from=pest" and "derived from=-cide". Any thoughts? --InfoCan 16:26, 11 September 2012 (CEST)

adding a new tort[edit]

Hoi, I tried to add the English word tort. I am not able to. Is this a bug ? Thanks, GerardM 11:06, 13 September 2012 (CEST)

Special:RecentChanges shows you created it, in fact twice. Browser issue? --InfoCan 15:29, 13 September 2012 (CEST)
You need to select the language in the dropdown (cf. ). You can access the English word directly at
The (apparently non-intuitive) language selection dropdown will be changed to a tab-like system when I take the time to commit my local code changes, so that it will be more obvious that several language exists for a given word. --Kip 19:09, 13 September 2012 (CEST)


Would it be possible to make the Cebuano language editable? I would like to copy some entries from this public domain dictionary. --Cosimo Lelio 23:03, 19 October 2012 (CEST)

It is already editable and we have 149 words in that language. Did you not find it in the dropdown list? --Kip 11:14, 20 October 2012 (CEST)

I must be doing something wrong. Cebuano does appear in the list, but my edits seem to have no effect. The editing page saves, no error messages appear, but nothing shows up on the DefinedMeaning page? --Cosimo Lelio 12:26, 20 October 2012 (CEST)

I am not sure what could cause this... I added a word in cebuano yesterday and it worked.
Maybe encoding problem? Instead of copy/paste, can you try by typing the word with your keyboard? --Kip 12:24, 21 October 2012 (CEST)

Turns out the problem was the summary line on the edit page. I wanted to add '+cebuano translation from'. Edits with this summary seem to get rejected. Maybe the spam filter thinks it's spam because it has an URL. --Cosimo Lelio 18:22, 23 October 2012 (CEST)

That's probably it, I have added this kind of filter. I'll see to disable it for registered users (I think it was already the case). --Kip 10:59, 24 October 2012 (CEST)
I have changed the spam rules, it should work now. Can you try it with a url? I am sysop, so for me it worked already. --Kip 17:11, 24 October 2012 (CEST)
No joy. Then again, it's not all that important. No need for you to spend more time on this. Thanks. --Cosimo Lelio 14:21, 27 October 2012 (CEST)

Sindhi (Gurumukhi script)[edit]

Where do I add the translations for Sindhi (Gurumukhi script) ?? Thanks, GerardM 18:45, 23 October 2012 (CEST)

There were some metadata missing. You can now translate it at Expression:Sindhi (Gurumuki) (and the other one Expression:Sindhi (Arabic script) ). --Kip 11:11, 24 October 2012 (CEST)
Thanks, GerardM 12:27, 24 October 2012 (CEST)

Definition of the day[edit]

Unlike other dictionaries, OmegaWiki is organized around definitions, rather than words. So, wouldn't it make more sense to change the "Word of the day" box on the Main Page to "Definition of the day"? :-) --InfoCan 16:50, 7 November 2012 (CET)

Why not... Besides changing the title, do you have something else in mind, like a change in the presentation? Or linking to DMs instead of expressions? --Kip 21:08, 7 November 2012 (CET)

How about something like this (with a box around it, and links for Edit and Archive, and RSS, Facebook, etc.):

Not having what is necessary for subsistence.
necessitous • needy • indigent

It would be ideal if you could write a SQL query such that, depending on the languages in which the definition is available, different versions of this box are generated, and they are inserted in the appropriate version of the Main Page. --InfoCan 23:35, 8 November 2012 (CET) Should be possible if we had access to the interface. Do we or can we get it? Klaas V 11:07, 26 November 2012 (CET)

A solution that I already considered is to create new parser functions specific to OmegaWiki (such parser functions have to be created in the php code)
One would be for example {#wdtranslate:123456|en} and would write the list of translations of DM 123456 in English, separated by a dot (or anything else), and another one would be {#wddefine:123456|en} and would put the definition in English. By default, {define:123456} without parameter could output the definition in the user language.
It should not be too complicated to implement, because the functions to get the list of translations and definition, given the DM number, already exist.
Any php beginner volunteer to give it a try? --Kip 13:12, 26 November 2012 (CET)
It seems to me that modifying the Word of the Day box by putting the definition first and the expression next (in English only) can be accomplished very easily and I suggest we do this first. This may seem a cosmetic change, but conceptually it is important because it emphasizes the difference between OmegaWiki and other dictionaries. Since the Main Page is the display window of the project, it should show to newcomers that definitions are the primary entities of our dictionary and expressions are their attributes, rather than vice versa. I suggest we worry about writing the PHP parser code later. --InfoCan 17:42, 29 November 2012 (CET)
Ok, as you say, the English-only version is easy to implement.
Let me do that over the coming days because I need to modify the script that posts automatically on facebook as well. --Kip 00:23, 30 November 2012 (CET)
I have changed my script. We'll see tomorrow if it works :-). --Kip (talk) 22:50, 21 December 2012 (CET)

Update 26-11-2012[edit]

No big changes, and mostly internal code changes, including:

  • the "combobox" to select your language for expression with multiple languages has been changed to a tab system, which should be more intuitive for new users. See for example Expression:Paris.
  • the sorting function now uses a jQuery sort, instead of a built-in sort. It should be faster (the sort is automatic when the page finishes loading), and the code is cleaner.
  • The annotation column now says "show" and "hide" instead of "Annotation▿" and "Annotation▵" (someone complained that the change of arrow was not very visible)
  • showing and hiding sections has also been rewritten in jQuery (maybe faster?, code cleaner).

Next, I'll put back identical meaning, by changing its checkbox to something else. People who want to use "identical meaning" (not me) should clarify when and how it should be used, by updating the page Help:Not identical/. --Kip 20:55, 26 November 2012 (CET)

Relation terms for verbs[edit]

I noticed that WordNet uses two relationship terms for verbs that are not available here: troponym and entailment. See Wikipedia for their meanings. --InfoCan 17:56, 29 November 2012 (CET) Also, WordNet uses "derivationally related form" as another relationship type. For example, the verb "paint" has the derivationaly related terms of paint (as a noun), painter and painting. These would be useful to provide here at OmegaWiki. --InfoCan 18:14, 29 November 2012 (CET)

"troponym" and "entailment": if you understand the concept well enough to add some of these, then we can have that. As always, the first step is to check that these concepts have a definition on OmegaWiki.
"derivationally related form", I think, is a Syntrans->Syntrans relationship. If I remember well, last time someone tried such a relation, it did now work. Apparently there is a bug somewhere in the software, but I haven't tracked it yet. --Kip 00:21, 30 November 2012 (CET)
Both expressions are defined now. --InfoCan 20:10, 30 November 2012 (CET)
Sorry, I had not seen your reply.
I added the relations "troponym" and "entailment".
Unfortunately, it is not possible to restrict them to verbs, so they are shown for any word type. --Kip 15:18, 19 December 2012 (CET)

Etymology selection dropdown menu[edit]

I just entered the exact same etymology three times for an expression having three different meanings but the same root (Expression:yakamoz). Similarly for the word "do", 35 meanings of it derive from one etymology ("From Middle English don (“to do”)..."). These are good examples for why each etymology need to be stored only once in a separate table in the database and then linked to from expression that use it. We already do something very similar for selecting DMs for a relationship (hypernym, antonym, etc.). Could we implement it for etymologies as well?

Implementing this mechanism would also make it possible later to group definitions according to etymology . For example, in the Wiktionary, the English word "flag" has 17 definitions and is grouped under 4 different etymologies [25].

--InfoCan 20:29, 30 November 2012 (CET)

As I think of it there are two ways to implement this. Etymologies can be linked to either DMs in ancient languages, for example

English: "do"

-> Middle English: "don",

or English: "automobile"

-> French: "automobile"
-> Ancient Greek: αὐτός
-> French: mobile
-> Latin: mobilis

Or they can be linked to an Etymologies table: English: "automobile" -> "French automobile, from Ancient Greek αὐτός (autós, “self”) + French mobile (“moving”), from Latin mobilis (“movable”)."

The first one may be simpler, but it may not work well in the following example:

Possibly from one of the following:
an abbreviated fanciful spelling of "all correct" (oll korrect), as part of a fad for similar comical abbreviations (of which no others have survived) in the United States in the late 1830s; see How 'OK' took over the world
Choctaw okeh (“it is so”); see okeh, The Choctaw Expression "Okeh" and the Americanism "Okay".
an abbreviation of "Old Kinderhook" (referring to Martin Van Buren)

What do you think? --InfoCan 20:44, 30 November 2012 (CET)

I agree with the idea to have etymologies shared between several expressions. The same is needed for example sentences. It requires an additional table in the database. I am not sure how to implement it in details, because I did not yet think about it in details ;) only that it makes sense and is feasible.
Also, some hierarchical-thingy should be implemented to browse through etymologies. So that you would have English"automobile" from French "automobile" and when you click french, you have "from Ancient Greek ...". This hierarchical-viewing would also be useful to browse through hypernyms, etc., like what is done at Wordnet. --Kip 14:23, 6 December 2012 (CET)
Wiktionary cleverly classifies meanings according to etymology. The second level of classification in Wiktionary is the word class. Like Wiktionary, all big dictionaries have at least 1 level of meanings groups. Since some words have very many meanings (For instance Oxford dictionary lists 33 meanings and sub-meanings for the word "time".), we will need such classification too, and Wiktionary's logic may be the best one. So maybe the 2 problems can be dealt with together. 20:02, 6 December 2012 (CET)

Adding Bosnian language to the Omegawiki database[edit]


I am new to Omegawiki and have looked through help pages, FAQs, etc. but couldn't really find an answer to my question.

While visiting the Dicts website (, I saw the list of available Omegawiki languages. Bosnian is not there and I would like to know what I could do to change this. I have already translated/localized several websites into Bosnian and have large linguistic resources at my disposal.

I know that Bosnian is part of the editable languages ( but when I get to the Bosnian portal (, there is no real topic about that question.

I would be extremely grateful if someone could help me on this.

Regards, Senad

We already have the Bosnian language, with 691 words so far. For example, we have the word bosanski (both in Bosnian and Serbian). We also have the Bosnian language for the interface.
The Bosnian portal is probably not up to date, as we don't have Bosnian contributors.
But if you edit a word to add translations, you should see the Bosnian language in the dropdown menu. seems to have only a small subset of the ~400 languages available at OmegaWiki. I don't know why. --Kip 10:57, 17 December 2012 (CET)

Thanks for the info Kip. It is much clearer to me now. I will be trying to get more familiar with all tools and features and hopefully bring some contribution myself in the future. Let me wish you a happy new year.

Italian Main Page[edit]

If not logged in using an Italian IP-address @MetaMainPageIt with some messages in red. How to avoid this user unfriendly behavior?
Deleting it is the hard way. Do Italians arrive at the English page when we do? Klaas V 11:05, 19 December 2012 (CET)

You arrive at the Italian main page when you are not logged in and use an IP-address, or when you are logged in and set your interface in Italian. I think in this case the best would be to delete the Italian main page, or find someone to update it. --Kip 12:42, 19 December 2012 (CET)

Only when I'm not logged in. I delete it. Uodating is too much work Klaas V 13:15, 20 December 2012 (CET)

Update 19-12-2012[edit]

  • the "identical meaning" column is back, in the form "= / ≈" and is selected with a combobox instead of a checkbox, which solves the previous bug (where all identical meaning were set to false, sometimes, when saving a page).
    • previous data has not been lost, as can be seen here: DefinedMeaning:her (342069)
    • since "=" is the default, maybe it could be set as a blank " " to look more pretty??
    • I still think that this column is useless because everybody has his own expectation of when it should be used, and because it says that a word is not identical, but does not link to the real definition of the not identical translation.
    • People using it should agree on when / how it should be used, and put the result of the agreement on the help page Help:Not_identical/.
  • if you view an expression with "not identical" definitions, the presentation has been changed a bit, as can be seen here. In particular, the "Approximate meanings" section has been put in italic, so that it is clear that it is not an actual definition in that language, and that it is not on the same level as "exact meanings".
  • also I have fixed the issue that the page looked ugly for a short instant when loading it (because the CSS was loaded too late)
  • and for language sorting, I noticed that it was not sorting diacritics as expected (é, è, Ä ...). I fixed some of them, but not all. Please tell me if a word is not sorted as expected. I have heard that in Dänish, "ä" is expected to be at the end of the alphabet, whereas this is not the case in German. There is now the possibility to change how a letter is sorted according to the user language so this is not a problem.
  • --Kip 15:20, 19 December 2012 (CET)
Looks good, thanks Kip. I like the approximate meanings section in the definitions page. Regarding the = and ≈ symbols, I think they look very similar and at first glance some users may not notice the difference. Perhaps we could use = and ~ instead? --InfoCan 15:54, 19 December 2012 (CET)
Or show them in a different color e.g. = resp. Klaas V 10:21, 21 December 2012 (CET)

MediaWiki 1.20[edit]

OmegaWiki has been updated to Mediawiki 1.20 (from MediaWiki 1.18). For the new features, see release notes 1.19 and release notes 1.20.

For us, it is basically improved stability, and a newer version of jQuery which is probably supported by more browsers. But mostly, the update to MW 1.20 was needed to update the Babel extension. --Kip (talk) 13:00, 20 December 2012 (CET)

Ah, new feature, with MW 1.20, I was able to remove the button for moving a page when viewing an Expression or a DefinedMeaning :). --Kip (talk) 13:10, 20 December 2012 (CET)

Our Twitter account[edit]

Merry Xmas and Happy New Year

When I have some time I publish Expression of the Day on Twitter.

  • That was the last tweet with new profile. Any ideas how we can make more promotion in social networks? Klaas V 13:51, 20 December 2012 (CET)
  • There are many language-specific forums where a note about OmegaWiki could be placed. Search under Google for "french language forum", "turkish language forum", etc. --InfoCan (talk) 15:32, 20 December 2012 (CET)
Right, InfoCan! I'm on some of them. Some follow us and/or we follow them BTW I want to change the text so active users are mentioned if they want in alphabetical order: Gerard M (?), InfoCan (?), Kip (?), Klaas V and many others Kip had a great idea. No names at all, but a link to the Beer Parlour! Klaas V 13:18, 22 December 2012 (CET)

hypernym question[edit]

I have a general question about holonyms. Some words can have multiple holonyms: for the word "door", is it correct to enter as its holonyms, the words "house", "car", "cabinet", "refrigerator", "garage", "lift"/"elevator", etc.? Or would there have to be multiple definitions for "door", for example one of them meaning 'door of refrigerator', whose holonym would then be "refrigerator"? --InfoCan (talk) 15:46, 20 December 2012 (CET)

Good question, but I don't know. I see the two solutions as you say, but can't choose between the two... --Kip (talk) 18:11, 20 December 2012 (CET)
Since "door" is a rather abstract concept, it seems that the holonym of "door" should be equally abstract, like "enclosed space". Then, "enclosed space" would be the hypernym of "house", "car", refrigerator" etc. However, I don't think this solution can be implemented in Omegawiki with our current rules, because "enclosed space" would be considered a "sum of parts". Perhaps we should relax this rule and allow such entries if they allow relationships between expressions to work properly? --InfoCan (talk) 19:25, 20 December 2012 (CET)