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/Archive2

From OmegaWiki
Jump to: navigation, search

2014[edit]

2013[edit]

2012[edit]

2011[edit]

2010[edit]

2009[edit]

2008[edit]

2007[edit]

2006[edit]

Contents

Expressions and phrases[edit]

The given Expression/translation for Swedish associated with the DefinedMeaning dairy farm - A commercial establishment for processing or selling milk and milk products., i.e, mjölkproducerande gård, has started a train of thought in my mind, which might have been discussed here earlier, but then I have missed it. The Swedish Expression given to me sounds as a regularly constructed noun phrase (a farm where milk is produced) rather than a fixed expression. For people within that line of business it is perhaps a valid fixed expression, so I am not out to get this specific Expression, it just set the train rolling.

I am sure that we will encounter several cases where translators will be tempted to add a phrase as a translated Expression rather than the closest possible Expression. I think we need strong and clear guidelines, and clear examples, on how to deal with this. I try to give some examples here, please add more...

An example that rushes to the top of my head is f ex the Swedish word mormor - The mother of a person's mother, where translators to English might be tempted to use maternal grandmother to serve as an Expression, after all that is often found in dictionaries. But, is maternal grandmother really to be considered an Expression in English? I think it is not. The Expression that should be associated with mormor should imo be plain grandmother, which then would have to be marked as a bad match. Of course farmor - The mother of a person's father would need to be treated in exactly the same way. Going the other way, since Swedish has no common word for the DM grandmother - The mother of a person's parent, both mormor and farmor would have to be added as "bad match translations" aka approximations.

Another: brother - The male sibling of a person. would run into some problems with Chinese. While f ex 弟兄 is possible, it is imo stylistically a bad match (and arguably semantically as well, a native speaker will have to comment on that); since the normal way to refer to brothers is to specify the relative age of the brother in question. So 哥哥 - The elder male sibling of a person and 弟弟 - The younger male sibling of a person would both be added as semantic approximations, while 弟兄 might be added as a stylistic approximation. Going the other way; 哥哥 - The elder male sibling of a person might need both brother and big brother as English translations/approximations.

As I said, this might be self-evident to those who have been working with OmegaWiki a long while, but it still needs to be stated I think. Oh, and maybe I have totally misunderstood everything. *smile* --Sannab 09:15, 23 May 2006 (CEST)

I asked a similar question here. It's not the same question, but I believe the answer will be similar. David 22:30, 26 May 2006 (CEST)

There is not workable solution for this yet, as there need to be flags indicating the politeness level of a word for Chinese, Vietnamese, Korean and Japanese. Without that you can't really work out the difference between 姉 (ane, humble Japanese for an elder sister, thus often used to refer to one's own elder sister), and お姉様 (oneesama, polite Japanese to refer to an elder sister). Oh, there's a lot the developers haven't yet dreamt of... --Mkill 18:02, 30 July 2006 (CEST)

Not just in those languages... just think about toilet, gents and loo in English etc. - a real nighmare for a non-native speaker :-) And pretty much the same happens in Italian, French etc. -- Sergio.ballestrero 01:56, 31 July 2006 (CEST)
Politeness levels in Japanese and Korean are much more complicated than just colloquial/standard language or T-V distinction. Try the Japanese honorifics and Korean honorifics Wikipedia articles to get a glimpse. --Mkill 02:47, 31 July 2006 (CEST)

new software is on-line[edit]

Hoi, I quote a mail from Erik ..

 We have a new version of the WZ code up at

	http://epov.org/wd-gemet/

 This version has the following new features:

 1) "Identical meaning" flag is shown. Note that all the GEMET initial
 terms have the identical meaning set to "0". Unfortunately I have no
 easy way to distinguish the old from the new data. The simplest thing to
 do would be to reset all the identical meaning data to "1".

 2) Data is displayed in tables.

 3) Basic ability to add relations. This is still very experimental
 (Peter-Jan, there are quite a few UI issues).

 The whitespace bug is now also fixed on the live site.

 Peter-Jan also has refactored the code quite a bit. However, there's
 still a lot of work ahead of us to come up with a sensible
 architecture.  :-) 

 Erik
What should be entered at new relations? It is unclear, also because the current relations are not shown in edit mode.
Add relation
Relation type Other defined meaning
No selection [X] No selection [X]
Please explain and/or improve. HenkvD 21:34, 31 May 2006 (CEST)
Upon trying myself a dropdown list of relation types appear. Starting with inputboxes instead of No selection and an Arrow [v] like on Language would be more helpfull.
broader terms GEMET Environmental Thesaurus Relation Types
is part of theme GEMET Environmental Thesaurus Relation Types
narrower terms GEMET Environmental Thesaurus Relation Types
related terms GEMET Environmental Thesaurus Relation Types
And on typing an Other DefinedMeaning a list of DM's appears. HenkvD 21:26, 1 June 2006 (CEST)
In the new software the changes of DM's are not logged on anymore on Special:Recentchanges. HenkvD 11:59, 1 June 2006 (CEST)

Allemanic and Tosk Albanian[edit]

For OmegaWiki we use the ISO-639-3 codes. The consequence is that when a Wikimedia Foundation project code uses a code that clashes the conventions of the ISO-code, it cannot be used within WZ to indicate a language. The "als" code is particular to Tosk Albanian.. Tosk is the language that is the standard for Albanian.

As a consequence, after much consulting, I have deleted the als templates that inform about the language proficiency for Allemanic. When you have a look at the English Wikipedia article you will find that it is typically considered to be FOUR distinct languages. Please help us, to resolve this issue by creating the templates for the variery of Allemannic that you know. Thanks, GerardM 10:41, 4 June 2006 (CEST)

Chinese / Mandarin and simplified / traditional[edit]

In the ISO-639-1 and ISO-639-2 zh and zho were indicating Chinese. This gave the impression that Chinese was one language. In ISO-639-3 Chinese is considered a language family. Typically people understand the Standard Mandarin to be Chinese. At this moment we still consider Chinese to be zho. This is something that consequently has to change in order to be more precise.

The cmn code for Mandarin is there for ALL varieties of Mandarin. To be practical, I propose to use the cmn code exclusively for standard Mandarin. When dialects of Mandarin are included, they will get a suffix.

Mandarin is written in at least two scripts, simplified and traditional. The codes for these scripts are respectively Hans and Hant according to the standards. This is better than what you also see; ch and tw. The problem with these codes is that both are used outside of China or Taiwan.

Consequently, I have asked Erik to have two versions of Mandarin as a language that can be used to enter data in WZ; cmn-Hans and cmn-Hant. GerardM 10:50, 4 June 2006 (CEST)

About WZ, or: What qualifies as an expression, what as language?[edit]

Hi, I tried to find out what range of "objects" is to be covered in OmegaWiki. On the main page it says it's going to be a multilingual resource in every language, with lexicological, terminological and thesaurus information. Further down it's stated that OmegaWiki is above all a multilingual resource about words and expressions.

I take it that "lexicological information" refers to semantic relations - or does it include grammatical, syntactical and maybe even etymological information? "Terminological" means you're aiming specifically at technical terminology of any (?) field of work or knowledge? What about common colloquial speech or slang? "Thesaurus" sounds like a holistic claim: every word of everey language (i.e. the Wiktionary approach) , but I think it may also mean that the words are structured in semantic groups? From what I (believe to) know about Wiktionaries, OmegaWiki and Wikidata, this definition isn't very specific, is it? I thought that WZ focuses on meanings and translations, aiming to include every word of every language.

Not only but also. To understand what we aim to do, the data design is telling. It makes plain that all the diverse information that exists in a Wiktionary could be in there (that was the original design criterium).

Now, what is considered to be a word/ expression/ phrase/ idiom/ character string worth including in OmegaWiki? I found no page addressing this issue. For instance, will there be two entries for the expression "dream" (noun and verb)? Will there be an entry for "dreamt" or "dreaming"? Or for "bats in the belfry" (or "to have bats in one's belfry")? Will there be different entries for "in" in every language that uses this word? In other words, how will homonyms and homographs be dealt with? Will inflected forms get a redirect entry or even a DefinedMeaning?

There is only one Expression for "dream" for English. It can however have multiple DefinedMeanings. And yes, inflections will be there too, they have their own translations :). There will be an entry for every language, the definition is as much required in one language as in the next. The inflected forms will have their own DM, for the definition they can rely on only one of the forms.

What qualifies as language? Any synchronic variety of spoken or written communication systems? Is there something like a minimum size of speaking population or other methods of agreeing on the importance of a language (official language of a country, print language...?).

At this stage we do not want to do much more than ISO-639-3. This includes some sign languages and we will be discriminative, not in our wish to include it, but in doing the written language first.

What about historical languages or stages of development? Would there be an entry "helthe" for Middle English "health"? Or Latin "sanitas"? (If "old" words and languages are excluded, what exactly is "old"?)

Middle English has its own ISO-639-3 code and so do many artificial languages. GerardM 18:30, 11 June 2006 (CEST)

If I've simply overlooked a page or discussion where these questions are answered, please direct me there :-) Yours, --jonas 16:17, 11 June 2006 (CEST)

Thanks for your helping answers. Do we already have an example of an expression with more than one DM? Possibly even different languages? I'm just curious how that would be displayed... Would it be similar to, say, a Wiktionary entry for die? http://en.wiktionary.org/wiki/die --jonas 23:15, 11 June 2006 (CEST) So far I've only found Expression:general - which really gives only a very general impression... (if I may comment in German: karg, wo nicht gar obskur ;-) --jonas 23:26, 11 June 2006 (CEST)
See for example bor in Hungarian (the last 2 paragarphs) the 2 meanings leather or skin and in many other languages meaning boron. How it will look like eventually is not clear as this is still in development. HenkvD 23:41, 13 June 2006 (CEST)

Deleting talk pages....[edit]

There seems to have already been established a praxis to delete the talk pages of Wiktionary:-entries once the Attention-template has been attended to. I must say that I find this disturbing. I can understand it if the change required by the attention-template causes the related Expression to be deleted, though even then I would rather it remained in the history. Of course the attention-templates should be removed once the problem is solved, but I do not understand why the history needs to be removed. --Sannab 09:49, 14 June 2006 (CEST)

Kipcool agrees Kipcool 09:21, 16 June 2006 (CEST)

About double licensing[edit]

Probably not here, but seems that discussion about License temined and officially wiktZ is under double license. What about older wiktionaries? I believe this way their contents could not be imported, i'm wrong? The Doc 10:35, 14 June 2006 (CEST)

I think so. First of all, people can and do allow for multiple licenses and, even when you import data in Wiktionary many liberties have been taken with the licenses of pre-existing material. Often it is not or badly attributed. On many occasions I have stated that importing within the GFDL only is not conformant with the GFDL or not possible. Given the copyright issues with much of the types of data you find in Wiktionary, it is not copyrightable in the first place except as a collection. We would not import in as a collection, the data needs to be massaged BEFORE it is entered in the OmegaWiki database. GerardM 17:33, 14 June 2006 (CEST)
As Gerard notes, there will probably be a vetting process, with some advice from Wikimedia's legal team. We may treat some data as not being copyrightable and import it without any consideration for the license (such as expressions). For the data which is copyrightable, we would have a mechanism whereby each registered user is asked to consent to the license change, and record that information in the database. Then we can choose to import for each Wiktionary page the latest revision that was edited by a user who has consented to the license change (if any).
While we will make an effort to import as much data as possible, I will also point out that there is a huge number of other resources besides Wiktionary out there which we may be able to use to seed OmegaWiki.--Erik 14:17, 15 June 2006 (CEST)
Maybe we can just do the Google books approach: we upload all data of Wiktionary in there, and remove some if somebody claims it to be his own. I say that because I doubt we'll be able to have all users put double-license (just because they are lazy), and it'll be a mess filtering which part is from who in the articles. Though, I see no reason why somebody would object putting his contribs in cc-by (we are all just trying to build a dictionary that can be freely reused). Kipcool 09:31, 16 June 2006 (CEST)

Definitions of animals and plants[edit]

In many cases (though far from all) it is possible to associate a term for an animal or plant with a Expression:scientific name, f ex Canis lupus. Should we take advantage of this internationally agreed upon standard and aim to include the scientific name of the species (or higher order grouping if more applicable) in the Definition? It might lead to a slightly higher degree of bad matches, but would do a lot to stem possible semantic shift.--Sannab 11:48, 14 June 2006 (CEST)

Of course, also dog on en:wiktionary explains dog as A member of the genus Canis (probably descended from the common wolf) that has been domesticated by man for thousands of years; occurs in many breeds. Scientific name: Canis lupus familiaris. HenkvD 20:18, 14 June 2006 (CEST)

upload rights?[edit]

Would it be relevent to restrict upload rights to the "wikidata" group? That troll is really annoying. Kipcool 09:42, 16 June 2006 (CEST)

Possible - though ideally, we want the Wikidata group to include everyone. :-) But it might make sense during the closed alpha.--Erik 12:12, 16 June 2006 (CEST)

Sort languages[edit]

I don't know the page for feature requests, but I'd like that the languages are sorted by alphabetical order. :-) Kipcool 09:45, 16 June 2006 (CEST)

I agree, although this is low priority. HenkvD 10:35, 16 June 2006 (CEST)
At this moment the language is only English, the idea is to have the names of languages in other languages as well. So the order in which they will be displayed is not self evident. This is as far as I recall to be done in Multilingual MediaWiki. GerardM 09:18, 18 June 2006 (CEST)
Chosing the sorting order by a user preference could be possible in some future ? luna 16:24, 18 June 2006 (CEST)

How to contribute ?[edit]

I would love to create the user interface in Sicilian language. How to start ? Thanks. --Giusi 02:02, 18 June 2006 (CEST)

It is like Sabine told you at your userinterface; we will ask Gangleri to import the scn user interface on the Betawiki. GerardM 09:19, 18 June 2006 (CEST)

You have new messages[edit]

That message is there always, even though I've read the message a hundred times. I tried deleting my user talk page, but the message is still there. Bug? Jon Harald Søby 11:54, 18 June 2006 (CEST)

I already told it in insect room The Doc

This is a known issue in the version of MediaWiki we're currently using, it will hopefully be fixed when we upgrade our codebase (this is a bit complex as we have to merge the changes we've made so far).--Erik

Archive[edit]

This page is becoming quite hard to download for my nice but slow 56k. What about creating an archive? Dennis 23:59, 23 June 2006 (CEST)

Good idea :) GerardM 21:54, 25 June 2006 (CEST)

Archiving[edit]

The first archive of the International Beer Parlour can be found here. Thanks, GerardM 21:53, 25 June 2006 (CEST)

25 june 2006[edit]

This was an un-lucky day. The database could not be found on a day when Erik was away from home. This resulted in a whole day of nothing happening at OmegaWiki. I hope there will be few such days.. :) GerardM 07:56, 27 June 2006 (CEST)

note on presentation[edit]

when a word exists in two languages or dialects, and has an identical definition in each, the whole set of translations should not be displayed twice. rather, list the tongues in which the concept exists together. for example, Expression:garden repeats the same information for english and american english. it might instead say at top, "Spelling: garden - Language: English, English (American)". this change will save users time and bandwidth. Aaronbrick 23:39, 29 June 2006 (CEST)

This problem will be mitigated when Multilingual MediaWiki is finished, it would however not work as there are parts to each word that are specific to THAT language. GerardM 07:56, 30 June 2006 (CEST)

International Linguists Beer Parlour[edit]

Today we had a discussion on the IRC of the International Linguist Beer Parlour. Well: I'd say we have enough linguists and people interested in linguistics here that could be interested to join that community as well. More information through the link in the title. Ciao! --Sabine 18:12, 1 July 2006 (CEST)

Countries[edit]

People often associate a country with a language. The consequence is that it is often considered "political" when another country claims as much that a language is also their language. My mother tongue "Dutch" or Nederlands, is not only spoken in the Netherlands.

Because of all the wrangling going on and as Ethnologue does provide information on the languages spoken in a country, I am considering starting portals for countries as well. The point for portals is that I hope that people in countries that are / are to be organised in for instane the WMF chapters find a place for them. Thanks, GerardM 13:09, 2 July 2006 (CEST)

Portal:NL (in uppercase) is now a country portal and Portal:nl (in lowercase) is a redirect to Portal:nld, a language portal. The same case is for a lot of other portal pages. Should the Portal:xx (in lowercase) 1) be removed 2) become a redirect to the uppercase Portal:XX, 3) become a disambiguity page or 4) be left unchanged? HenkvD 19:41, 5 July 2006 (CEST)
I updated the language list for Portal:IT, but there still are two letter language codes I got from Betawiki --Bèrto 'd Sèra 20:02, 5 July 2006 (CEST)
The ISO-639 is in lowercase. The Countries are in uppercase.. Thanks, GerardM 21:50, 5 July 2006 (CEST)
okay, we still miss a portal for arpitan (ISO 639-3 frp) and walser. For walser Ethnologue lists a general ISO 693-2 gem code and a SIL code WAE. Gem really looks too general. What do we use? sorry, it was only me using wrong codes... As per arpitan, there is an arpitan wiki. Do we ask them the babels? I *might* have a contact for walser, too... BTW, I am missing a few language codes in Portal:IT. The list I get from ethologue leaves me with a few red links. Is it my codes being wrong, or just the portals missing? I also have a problem with Sardinia. Ethnologue lists four languages, but we usually have a single ISO 639-2 SC code. I guess we have the split version, right? --Bèrto 'd Sèra 00:47, 6 July 2006 (CEST)

Necessary next steps[edit]

We need to move further I think. I realize that time is short, and developer time is even shorter, and I am sorry for being such a nag, but right now I am not even checking in on OmegaWiki every day.

Step one[edit]

Well, we have tried out the existing set of DefinedMeanings as well as we can I think. We have pretty much run into the wall. I think we can get no further if we do not get the possibility to add new DefinedMeanings.

There are very many extremely basic words missing from the current set, and of course it would be nice if these could be imported from a list, but lacking that, at least give us the means to add them manually!

Step two[edit]

The other major thing missing is the structure to discuss modifications of the first Definition. This however becomes very hard because we still do not have any visual indication on what is the first Definition, nor do we have any talk page for the DefinedMeanings. If we had an easy way to refer to a given DefinedMeaning we could discuss it elsewhere, but Expression:<yadayada>/Definition:<yaaaadayaaada> just wont do as a reference.

To sum up, a short list of what I think is the most important features to get implemented right now:

  1. The ability to create new DefinedMeanings
  2. A flag for the Expression and the Definition that forms a DefinedMeaning
  3. Either a talk page for a DefinedMeaning, or a unambiguous but short way to refer to a DM (if it has to be in an opaque code, so be it!).

Again I apologize if I am being too impatient. *smile*--Sannab 18:20, 4 July 2006 (CEST)

You are not the only one being impatient Sanna :-) there's a bunch of us .... I think it is time to write a mail :-) Ciao!!! --Sabine 18:59, 4 July 2006 (CEST)
Basically I agree. But logging history and differences should not be forgotten, because there still is no trace of what was edited. When a DM gets changed the trace should be on the DM and on all of its expressions (at least that is how I see it). HenkvD 23:37, 4 July 2006 (CEST)
Yes, histories and diffs are important. I guess the FDM (FirstDefinedMeaning) could simply show a special graphic sign along its box (a template?). It would also be handy if it was shown as the closest to the new translation box. Another thing that would come handy is a special page listing the words that miss a translation for your language and have a definedMeaning in at least one of the languages you can use. This opens a second problem: apart from having a FDM, we also have UsedDM(s), those from which my new DM came. I should be alerted when one of the UDMs for my DMs is edited, because it may impact on my translation, too. This means that I should be able to leave a reference from my DM to one or more pre-existing DMs. Doing this could help people in choosing what DMs they should use, when they can use more than one language. Starting from a 2nd level DM should basically be less risky then using a 5th level translation. So the graphical sign could actually be a number. 0 is for FDMs, 1 for a direct translation, 2 for a retranslation, etc... --Bèrto 'd Sèra 02:21, 5 July 2006 (CEST)
Actually I think that in the end it will not be enough to show the first DM by a graphical sign, although that is a very good step on the way. Since any changes made to the first Definition will require reconfirmation/modification of already existing translations, I think that it should actually be slightly more complicated to change it. I would in the long run prefer it if the first Definition was not shown as an editable box next to the rest, but that it was written out as plain (uneditable) text, with a button next to it to change that first Definition. First Expressions I presume should be even harder to change/delete, the only reason to do so would be to fix a typo. Anyway, I think it will be absolutely necessary that there is a "dirty" or "out-of-date" flag for each translated Definition, that is automatically set whenever the first Definition is changed. Without such a flag it will be an impossible task to keep the translated Definitions in phase with the first Definition. Possibly there should be an additional option when editing the first Definition, something of the same sort as "minor", i.e., if the change made to the first Definition is merely the correction of f ex a misspelled word, the editor should be able to check a box that suppresses the setting of the dirty flag on the translated Definitions.
History and differences are of course very important also, but I do not think they are the showstoppers that the items I listed are. Having the translation box adjacent to the first Definition is a very good idea, I would prefer to have it on top.--Sannab 07:51, 5 July 2006 (CEST)
Yes, having a "minor edit" option is a must. I also agree with the need of making 1stDM hard to change. Only I am not sure that having the "dirty" flag propagated by 1stDM changes only will be enough. If I input a 1stDM in piedmontese I can hardly think of people being able to use it. Most translators are going to use an ENG-DM in instead. So the expression 1stDM actually has a relative meaning. --Bèrto 'd Sèra 14:34, 5 July 2006 (CEST)

Words with different meanings[edit]

I checked through some words in the database and I wondered how OmegaWiki will deal with words that have more than one meaning in one language. One example: Druck is a German word that has two main meanings: one is equal to the english word pressure as used in physics, the other, related meaning is equal to the English word print as in the book is in print. Each meaning will need its own Defintion, relation and translations, even though both will be in the same language section. --Mkill 20:39, 12 July 2006 (CEST)

This is no problem. Two DefinedMeanings can have the same Expression (example Druck) in the same language. I don't know of a german example in OmegaWiki, but see for example bor in Hungarian. This has 2 different meanings: leather and skin. HenkvD 10:58, 13 July 2006 (CEST)

Future plans[edit]

Could someone who knows what's going on fill me in on some details?

  1. What can OmegaWiki currently do?
  2. What does OmegaWiki need to be able to do before it can be considered functional?
  3. What are the concrete plans as regards the current monolingual Wiktionaries and the future OmegaWiki? Will all current Wiktionaries be migrated to OmegaWiki in the future?
  4. What can I help with?

Thanks! —Nightstallion (?) 09:42, 13 July 2006 (CEST)

  1. This instance of OmegaWiki is where people who have been given edit rights can contribute on the GEMET content. They can help by testdriving the evolving user interface. We can discuss things.. (it is a fully functional MediaWiki wiki)
  2. To be considered functional, we need versioning to work; this will give us recent changes, history and the possibility to roll back.. This is required before we have everyone edit here.
  3. The functional design of WZ is such that it shoud be able to include the content of the Wiktionaries (they are NOT monolingual). We do want to include the data from the Wiktionaries, if the people and the projects in fact migrate to OmegaWiki is up to them.
  4. What can you do ? Can you develop, have you read this ? And yes, the Babel templates are really necessary.. GerardM 11:09, 13 July 2006 (CEST)
3. It would, of course, be encouraged to migrate all of the current wiktionaries to OmegaWiki at some point? I don't see much point in it if it isn't; in my opinion, OmegaWiki is an opportunity to make the Wiktionary project work as a real dictionary between all languages. One can of course use the monolingual (why not, BTW?) wiktionaries we currently have in that way, but it's rather tedious as compared to this proposal...
4. I'm no developer, I'm afraid. I have read it, and tried to comprehend it, as well. ;) Well, what can I help with the Babel templates? Most of them seem to have been migrated already, no? —Nightstallion (?) 12:57, 13 July 2006 (CEST)

Requests for permissions[edit]

Following a chat on IRC with Gangleri, I have created Requests for permissions, a page where people can request sysop or Wikidata access. Helps keep the process transparent :). —Celestianpower Háblame 13:48, 15 July 2006 (CEST)

At this time the process is not transparant. Yes, people can request but they are given rights based on the whims of people who are the bureaucrats. At this stage the project is in pre-alpha status, access is limited to people who are known good or come recommended by other known good or who are given access for strategic reasons.
The rights given are given on the basis of personal trust. When people are no longer trusted for whatever reason these rights can be revoked as easily as they are given. There are two sides to this coin. There is no formal policy that people can refer to and therefore there is no point in politicking. Politicans are distrusted in the first place and for me it is a surefire way of not getting rights or losing rights. I tend to trust people who are known to do good in wiki projects and involve themselves first and foremost practically. GerardM 22:07, 15 July 2006 (CEST)
I agree, but Gangleri told me to make it, so I did :P. —Celestianpower Háblame 00:20, 16 July 2006 (CEST)
Gangleri is a bureaucrat, he is as enigmatic as all other bureaucrats.. If he wants such a list, I am happy to have him have it. :) GerardM 00:31, 16 July 2006 (CEST)

Chemical formulae[edit]

On the OmegaWiki blog I wrote about how to classify chemical formulae like H2O. Purodha informed us to the existence of some special codes, and I would opt for the zxx code. This is the code for "non linguistic content". I think these formulae qualify as such..

What do you think ? GerardM 18:08, 18 July 2006 (CEST)

Nice! Is this where also things such as 5 or other "almost translingual" stuff, which only differs between certain scripts and not between languages using the same script, will be? \Mike 19:34, 18 July 2006 (CEST)
I also think zxx is most appropriate for formulae, numbers, single characters, symbols, etc. I am uncertain about proper names etc. which I feel are somhow in the domain of a language even though their vast majority does not translate. -- Purodha Blissenbach 22:24, 19 July 2006 (CEST)
I am under the possibly mistaken impression that "zxx" is for tagging resources like images that have no content or content that is not linguistic, e.g. an abstract image within a set of images, some of which may be images of text. By contrast, "H2O" seems like multi-language linguistic content. Note that in English it has a part of speech (noun), a pronunciation ("aitch two oh"), and a specific definition ("the chemical formula for a molecule with two hydrogen atoms and an oxygen atom"). Since the expression has the same meaning in multiple languages, I think "mul" is its proper ISO 639-3 tag. Rod A. Smith 04:04, 20 July 2006 (CEST)
Another view to it might be that formulae, internationally agreed-upon symbols and abbreviations, numerals of various scripts, etc. are in a translingual domain which is 'imported' into certain domains of many, but not all, languages. E.g. chemical formulae are imported into the 'chemistry' domains of modern languages; likely, at a lower weight, also into the 'academic talk' domains. Yet it would be strange to hear a working class speaker in a pub order "another glass of H2O", or find "H2O" moulded into an ancient egypt hieroglyphic text, even on chemistry, even if it has been translated from modern english. --Purodha Blissenbach 12:02, 20 July 2006 (CEST)
If we are dealing with pronounciation at all (beyound what is needed to distinguish homographs) then I am afraid we have to have a 'translation' of all speakable such expressions to all languages applicable. Bear in mind that, e.g. numerals and numbers and the like in their spelt out form are in the each language already, and we shall have a relation linking '9' and 'nine' but we probly neither want to relate '1234567890987654321' to its spelt out form, nor do we want to store a countable infinite number of numbers anyway. The same imho holds for chemical formulae, of which there are too many to enumerate. That leads to the point, numbers, chemical formulae, mathematical equations, etc. can each be seen as a language on their own. In the mathematical sense of 'language', this is precisely so, and btw. since most of their grammars are fully formalized and simple, they're especially 'nice' samples of languages.
If we treat them a languages, we can indeed translate "H2O" to 'water' or 'vand' and vice versa. Also, the 'abstact numbers' language gets localized to a specific language or script, so "4712" becomes '4.712E3' or '4 712'. or '4,712' or '4.712' or 'MMMMDCCXII' or 4712 drumbeats, depending on language, script and domain context.
ISO 639-3 does not have, or allow, language codes for such languages. So, if we follow that approach, we'll have to have Qxx codes for those 'languages' which is one of their intended uses.
Also, because of their infinite vocabulary, they have to be treated more programmatically, which technically means 'words' have to be constructed 'on the fly' and not stored in a database. So, associated with a Qxx code, we'll have a little piece of program code, a regular expression, or the like for those 'languages'. It answers the question wether or not a given expression is a correct (possible) 'word' of the 'language'
When a translation to one of those 'languages' is entered, the translated expression can and should be verified to be valid according to the 'grammar' for 'words' in that 'language'. Note, e.g. for chemical formulae that does not grant the existence of such chemicals. It is correct to mention "H17O", which to the best of my knowledge has never been observed nor can it be contructed, especially in a sentence like this one. Predicates such as 'this is a true mathematical expression' or 'poisonous chemical' are semantic, and not useful in WZ. --Purodha Blissenbach 12:02, 20 July 2006 (CEST)
A slight disadvantage of using Qxx codes for formulae would be that mixing language with formulae would fomally make the aggregate result having to use language code mul. This may be undesirable when such data gets exported. Fortunately Qxx are valid within our own framework only, and need to be dropped on export, when the receiver is outside our framework. So the problem can be remedied by keeping both the standard language code and Qxx with their respective portions of text, then simply dropping the Qxx, which incorporated the formulae into the surrounding language, and if then only one language remains, the result is exported with this language code attached, only otherwise with mul. -- Purodha Blissenbach 12:25, 20 July 2006 (CEST)
  • Taxonometry would be another subject matter which can be seen as an invariant part of, or domain in, many languages. At least in several european languages, grammatical exceptions, or a specific grammatical embedding, apply.

Identical meanings[edit]

If I look at the Expression Expression:some, I see that the spanish translation "unos" is not an identical meaning. However, by going to the page Expression:unos, there is no longer any indication that this Expression is not an exact match of the given DM. \Mike 19:47, 18 July 2006 (CEST)

Ok, Celestianpower checked that box now. But it is still true for the Swedish "lite" and "några". \Mike 20:02, 18 July 2006 (CEST)
Hehe - sorry. —Celestianpower Háblame 00:20, 20 July 2006 (CEST)

Scripts[edit]

I'd like to create a page on Scripts, similar to that of Countries, and a "portal page" per script, that links to the languages using that script, and lists the alphabet including character variants, of each language for alfabetic scripts. Where applicable, also sort order, and similar information should be included. Language pages should link back for each script, they are written in. -- Purodha Blissenbach 22:28, 18 July 2006 (CEST)

  • Before many more of those Babel templates are created:
    • Should we really have Script capability templates resembling language templates?
    • Should names of categories for users be "Script User Wxyz" or rather intermingled with language codes as in "User Wxyz"? We are unlikely to have duplicates because of different code lenghts and letter case, but may lack clarity. -- Purodha Blissenbach 12:57, 20 July 2006 (CEST)

Categories of Portals[edit]

With the advent of Country portals and Script portals, it might be systematical to use Category:Portals as a collective parent category only, and create Category:Language portals. Afaics that's technically easily done modifying only Template:Portal and said two categories. -- Purodha Blissenbach 10:39, 20 July 2006 (CEST)

Ability to add expressions added[edit]

It should now be possible to add new expressions. If you have editing permission, you can do so in three ways:

  • Follow a red link, e.g. Expression:googoo (don't add that one, please ;-)
  • Edit an existing expression and use the "Add language" links
  • Use the inputbox:

<inputbox> type=create default=Expression: buttonlabel=Create expression </inputbox>

Right now, all OmegaWiki content is in the Expression namespace. We'll probably change that soon, but this means that any expression has to be prefixed with "Expression".

The editing user interface is in some need of improvement -- the collapse/expand behavior is currently a bit confusing. We have some other priorities right now so we can't fix that immediately. I'll try to improve at least the RecentChanges behavior a bit today.--Erik 12:29, 20 July 2006 (CEST)

Bureaucrats - Language/Domain managers - admins[edit]

One subject that some people have given a lot of attention is the notion of the organisation of hierarchy in OmegaWiki. First of all, this project will have it's own policies and they are NOT the same as other projects. The reason should be obvious; it is a different project from other projects.

At this moment we are in a pre-alpha stage. We have a group of initial people who are bureaucrat. They are also part of the OmegaWiki commission. People who are given the right to edit are also given the admin rights. Admin is a matter of trust, editing is a matter of trust. As long as you are trusted to do right for the project.

There is a perceived need for one person per language to maintain the meta-data for THAT language. The current vision is that much of what needs doing does not need any discussion; a language does have a noun or it doesn not. An adverb does have a masculine and feminine form or it does not. So far we thought it would be a bureaucrat who would be responsible for this however, it is more likely that we will have a language manager. This role would be given to someone to a single person AND it is very much a technical function.

Another perceived need is for a similar function for a person to maintain the meta-data for a DOMAIN or SUBJECT MATTER. For particular domains, particular RelationTypes are valid for instance only an animal can be a predator or herbivor. Domains are essential to terminology and they are in essence a super set of a collection. A domain is integral to OmegaWiki, a collection is very much an external resource that is integrated into OmegaWiki up to a point.

There will also be a need to give people rights to modify collection info. This would allow authorised people to indicate stuff on behalf of the organisation that maitains such an external resource.

Voting and democracy[edit]

When there is a need to vote on stuff, we will vote. But when we can reach consensus on certain stuff we will not vote; it is much better to have arguments out in the open. When there are no compelling arguments for a certain case, it will not happen. From my perspective, we have to work in the OmegaWiki environment and when we start to split things up in small corners that are private and that does not talk with others we have a situation that does not work. OmegaWiki is VERY much a project with specific principles. When people want to add data to WZ and we have the capability to do so, we will do so. When people want to work on a given subset of our data, they should be allowed to work on THAT subset without being compelled to do other stuff as well. The only exeption would be that it is not OK to do stuff that would break the functionality for others HOWEVER, this functionality should be build in such a way that it does not prevent how other people want to use the data. GerardM 18:52, 20 July 2006 (CEST)

Workshop[edit]

The following was posted by Adam Kilgarriff on the Corpora mailing list


CALL FOR PARTICIPATION; Programme now available Fourth International Workshop on DICTIONARY WRITING SYSTEMS (DWS06)

Torino, Italy Afternoon (13.30-17.30), Tuesday, 5 September 2006 (pre-EURALEX http://www.euralex2006.unito.it)

A dictionary writing system (DWS) is a piece of software for writing and producing a dictionary. It might include an editor, a database, a web interface and various management tools (for allocating work etc.) It operates with a dictionary grammar, which specifies the structure of the dictionary.

The workshop is relevant for:

dictionary project managers lexical database users and developers lexicographers students of lexicography, lexicology, computational linguistics The workshop follows similar successful events in Brighton, UK in 2002 and 2003, and Brno, the Czech Republic in 2004.

Website: http://nlp.fi.muni.cz/dws06

Adam Kilgarriff http://kilgarriff.co.uk
Lexicography MasterClass http://lexmasterclass.com
Lexical Computing Ltd http://sketchengine.co.uk
University of Sussex +44 (0)12 73 705 773
mailto:adam@lexmasterclass.com +44 (0)79 71 867 845

Brett --72.142.116.7 02:58, 21 July 2006 (CEST)

Discussion forum for DefinedMeanings[edit]

With the ability to add new DefinedMeanings the need for somewhere to discuss the wordings of the first Definitions is dearly needed. I have tried to start a discussion forum under the name of DefinedMeanings needing attention. Please comment.--Sannab 14:41, 21 July 2006 (CEST)

Grammatic properties discriminating between different DefinedMeanings[edit]

Let me give a sample first. The standard German verb "flutschen" (roughly to slip/slide) always has to have a concrete subject and object e.g. "Das Geld flutsch mir aus den Händen" (Money's slipping out of my Hands). If a pronomen is used, it needs to refert to something or someone, else you have an incorrectly built sentence.

Now, there is a regional/colloqual form, too, that has no object, and the subject is the pronomen "es" (it) without a reference, or another unconrete and very general placeholder. "Es flutscht" (it works) or "Danke, alles flutscht blendend" (Thanks, everything is mavellous). In Kölsch, we do not have "flutschen" at all, but two different word for the two DMs, "jitsche" and "fluppe" having pretty similar grammatical / syntactical properties.

Entering the Kölsch expressions would be easy to me ;-) but not so the German ones. How do I discriminate between these DMs without referring to the grammar and/or syntax making the difference? -- Purodha Blissenbach 16:04, 21 July 2006 (CEST)

AFAIK, there is absolutely nothing that requires that f ex translations of a given DM need to conform to the original entry as far as grammatical requirements are concerned. DM:s concern themselves mainly with semantics (though I think that stylistics should be a concern too), not with syntax or morphology. The discrepancies you are referring to would need to be specified (via a not yet fully implemented attributes(?) interface on an Expresson basis. If the semantics match, they may be entered as translations, if you wish to at this early stage mark the differences, I am afraid you will need to add an Attention-tempalate with an explanation to the talk page of each Expression.--Sannab 16:11, 21 July 2006 (CEST)

Defining and relating inflected forms[edit]

Some inflected expressions have defined meanings with more semantic information than those of the corresponding lemma, so it's obvious that they need their own definitions. E.g. "dogs" means "more than one animal of the genus..." and "profesora" means "a female who teaches...").

Some other inflected expressions have the exact same semantic value as the corresponding uninflected expressions (the lemmata), e.g. "roja" is the grammatically feminine form of the adjective "rojo", but they both mean the same thing ("reflecting light with an average wavelength between..."). So, it makes sense to list such an inflected expression as a synonym of the uninflected expression. Please correct me if a definition should actually include grammatical details, e.g. for "roja", "the feminine inflection of rojo".

We will later be able to apply the appropriate grammar attributes (e.g. feminine inflection) to the inflected forms when the language managers create those attributes. When that happens, will those grammar attributes be able to relate the inflected defined meaning to the lemma so that "roja" and "rojo" are appropriately related? Rod A. Smith 04:22, 26 July 2006 (CEST)

All inflected forms have their own translations hence all inflected forms WILL have their own DefinedMeanings. The inflected forms "share" the same definition as the uninflected form, in English / Dutch etc the infinitive. The only thing to add is the notion of the specific inflection eg has .. third person singular .. An inflection maps to inflections in another language, when the structure is the same it is easy. When there are for instance "first person singular masculine" and "- feminine" forms, it will get relatively more complicated. When a word has a different meaning other than the standard inflection, it will just get yet another DefinedMeaning. GerardM 07:45, 26 July 2006 (CEST)
Good. That makes sense:
  1. Each language manager will create their inflection type with equivalences to inflection types of other languages.
  2. Editors will make the inflected forms share the definition of the uninflected forms and will tag inflected forms with the inflection types enabled by language managers.
  3. Readers will see "soy"="suis"="am"="bin".
The UI will be a challenge, but the results seem ideal. Rod A. Smith 08:34, 26 July 2006 (CEST)
It does not make sense. How do you want to handle languages that don't inflect? Simple example: "dog" and "dogs" are both 犬 in Japanese, as this language does not have a plural. Of course, always finding a corresponding inflection between languages will be a hassle, because different languages tend to have different cases, tenses, moods and so on.
Next problem: Do you *really* want another DM for every possible inflection of a German / French / Russian whatever verb? Each verb would have more than 20 entries for each language. Impossible.
Did you even think of Finnish? This language has some 18 (?) cases for each noun. Which means that every noun will have 18 translations in all languages to match Finnish cases. --Mkill 15:54, 6 August 2006 (CEST)

"Out of sync" category[edit]

An idea of mine. While we wait for the "dirty flags" or the like, I've made Category:Out of sync and Template:outofsync for use on Talk pages. This should partially replace the Attention system to be language specific. For instance, on OmegaWiki talk:Belgium I've put {{outofsync|swe}} to indicate that I've not updated the Swedish definition after I changed the other ones. This should more or less take away the hesitation that may be felt when one tries to change a definition that has already been translated to languages one does not know. Simply {{outofsync|ISO 3 code of the not updated language}} as many times as necessary should provide some more certainty. — Vildricianus 20:26, 21 July 2006 (CEST)

Note: I see Sanna has made Category:Translated Definitions needing update today, which I guess has the same purpose? Mine now anyway works per language, which may be more useful. — Vildricianus 20:40, 21 July 2006 (CEST)

Template shortcuts to be placed on talk pages[edit]

For you convenience the following templates have been created:

  • {{DMA}} : Defined Meaning requires attention (takes 1 parameter)
  • {{EXA}} : Expression requires attention (takes 1 parameter)

People that really understand parser functions could restructure the template so that it looks a bit better if the parameter is omitted. Siebrand 21:34, 21 July 2006 (CEST)

Since we're still on MW 1.6, I don't think ParserFunctions are already available. — Vildricianus 21:37, 21 July 2006 (CEST)
They are not. Parameters defaults are: {{{7|default-being-used-if-parameter-list-is-shorter-than-7}}}.
Ah, that explains my frustration... ;-). Thanks for the clarification. Siebrand 19:20, 22 July 2006 (CEST)

1000+ recorded changes in 24 hours[edit]

OmegaWiki has had more than 1000 recorded changes in the past 24 hours in the OmegaWiki namespace. Congratulations to all contributors! Siebrand 19:19, 22 July 2006 (CEST)

That explains: There are 6,264 total pages in the database. This includes "talk" pages, pages about OmegaWiki, minimal "stub" pages, redirects, and others that probably don't qualify as content pages. Excluding those, there are 18,446,744,073,709,551,609 pages that are probably legitimate content pages ;) HenkvD 20:07, 22 July 2006 (CEST)

Identical DM's?[edit]

There are a few expressions which seem to have 2 identical DM's.

Is this a software bug or are people adding expressions as new DM'S? HenkvD 14:29, 23 July 2006 (CEST)

Stilte has been solve. That was a problem with the DM that should have been adverb vs. noun. The other one appears to be user error of whichever origin. Siebrand 20:54, 23 July 2006 (CEST)

Blissymbolics likely to come with DefinedMeanings[edit]

From the Wikipedia article, I got the impression that, Blissymbols seem to have several 1000 well founded and documented DefinedMeanings with them. We might consider importing them in WZ. -- Purodha Blissenbach 11:10, 24 July 2006 (CEST)

Redefining OmegaWiki objectives[edit]

Vildricianus advised me to post this here. I would like to discuss an important point that nobody else seems to really consider (or that everybody prefer not to consider): how could a multi-language wiki be possible? I understand that sub-communities are envisioned, with, probably, discussion rooms by language. Anyway, what about discussions (and votes) at the project level (e.g. « may website names be included, and on which conditions? »). It seems that the current view is that such discussions will be in English. This would exclude many contributors (maybe most contributors), either because they cannot speak English at all, or because they think their level in English is not advanced enough. And this would make OmegaWiki an anglophone wiki (which already appears clearly enough if you consider its name).

I am afraid that many wiktionaries could decide to migrate to OmegaWiki and then to disappear. But I am convinced that many contributors of these wiktionaries (which often are rather few) will, immediately or after a while, stop participating. Therefore, the anglophone part should benefit of it, but all other parts will progress much more slowly than now. I don’t think that this is the objective. One major interest of the Wiktionary (and Wikipedia) concept is that all languages are equal, and that everybody can participate equally. This major strength would be lost.

I do not mean that your work at OmegaWiki is useless. I can make two different proposals using it:

  • keeping current wiktionaries, but considering OmegaWiki as a format, not as a wiki, and proposing current wiktionaries to migrate to this format. If the format is well designed, this would allow easy automated imports between wiktionaries, and this would benefit to everybody.
  • same proposal, but all OmegaWiki wiktionaries could share, if they want to, a common database, and redundant information which can be displayed independently of language (e.g. pronunciation in standard phonetic alphabets) would thus be stored only once. This should leave a complete policy freedom to each wiktionary, while allowing automatic information sharing.

I give my strong preference to the first proposal, because the second one would probably not work as simply as I explain it (it still could imply, in some cases, discussions between people not understanding each other). But I am convinced that, without this kind of change in its objectives, OmegaWiki simply cannot be a success (remember the Tower of Babel project: it seems that it was not very successful). Lmaltier 23:33, 25 July 2006 (CEST)

Redefining .. that is a bit premature[edit]

First of all, what you see at the moment is how the current SOFTWARE works. It is really great that we are as far as we are BUT it does miss crucial functionality. Given your concerns, missing the Multilingual MediaWiki functionality is the more important thing. This is the functionality that will allow people to have the content of OmegaWiki show much of the information in the language indicated in the user preferences.

At this moment the data is indeed really English oriented. This can be helped by working on the content, translating defintions, adding Expressions connecting them to the right DefinedMeanings. In your proposal there is nothing what you cannot do in OmegaWiki. The functionality that you need in any language is roughly the same. The functionality that needs building will take effort. Doing it once means that you can improve the quality by doing it once. This is only possible by workin on the same data.

When there is a need for functionality for a specific language, it will be the people who know that language who will need to come up with a solution. This solution has to fit in the greater scheme of things.

All in all, given that we are in pre-alpha, given that having the same data in many places is a REALLY bad idea, I do think we will need to let OmegaWiki mature at least way past it's full functionality before we can seriously discuss this because only then we can see it it will work. GerardM 23:58, 25 July 2006 (CEST)

Your reply is about functionality. My concern was not about functionality (I fully understand the intention), but about discussion at project level between people not understanding each other, which is clearly impossible. If you prefer not to look at the problem and don't want to discuss it now, I feel that this is not only the beginning, but also the beginning of the end for OmegaWiki. Lmaltier 07:56, 26 July 2006 (CEST)
There is no point at splitting WZ at this time. We do not have the necessary functionality in the first place and we certainly do not have the functionality that you propose. You assert that there will be a problem. This has not manifested itself yet. We will cross that bridge when we meet it. GerardM 08:58, 26 July 2006 (CEST)
I agree with the concern of Lmaltier, this project is anglo-centered. For example, if I want to add the verb "boire" (=to drink) and its definition, I'll have to (i.e. I must) translate the English definition given for it. Using English here as the reference language makes thinks simpler (everybody translate English to their language = everybody has the same definition, and we avoir semantic drift), but it excludes people who don't speak English. Another example of anglo-centrism is this beer parlour, which is in English ;-). Also, I'm wondering what will happen if there is for example an issue about an English->French translation, and that there are 2 discussions about it, one in English and one in French, and the 2 discussion gives 2 different conclusions.
I don't have a solution right now. The best solution would be to eat magic pills that makes everybody fluent in English. The first solution proposed by Lmaltier (importing between Wiktionary<->OmegaWiki) seems the most reasonable for me for now, although messy. It's already what is done between some Wiktionary. (In the French wikt, we import stuff from various wiktionaries; In the German wikt, I've imported stuff from the French wikt recently).
However, for small languages, this project gives some advantage: for example, if I add the translation of "hello" in inuktitut, that translation will be automatically added to "bonjour" for example, so I think it's a good opportunity (if they speak English) for small communities that have trouble making their wiktionaries grow (and they are many). Kipcool 11:26, 26 July 2006 (CEST)
Hi Kipcool, I would like to specifically react to one issue you raised that you may have misinterpreted: If you enter the word 'broire' which clearly has a meaning in French, assuming it does not yet exist, and you add a definid meaning for it, only in French, you are most certainly not obligated to add any translations of the DM or even translations or synonyms of the word fitting the DM. The only thing that is happing - mind this: in the current state of development of the software - is that if you are viewing the article for 'boire', you will only see a '+'-sign.
That is because the software currently only allows to display the English defined meaning and no other. I can imagine that in the future, it will show the defined meaning of your preference, and if not available that of your 2nd, 3rd, 4th or 5th preference, ultimately showing only that language that is the only one available. In my opinion this was not an example of the project being anglo-centered, but of a developer adding functionality first in the simplest way he can, being able to build on it later in the development process, which may not even take that long. I'm happy that we no longer see 'Defined Meaning' at the position on a page. Siebrand 15:35, 26 July 2006 (CEST)

I think this project also has benefit for bigger languages.

Now, to reassure you, Lmaltier, I've also been thinking about this for months :-). But I don't think it'll be that big a problem as we think it will be. At discussion-level, there should be a "language community" or "subcommunity" for each language, with their own pages, translations of policies and whatnot (like there would be and currently is on their own wikis). The important thing for that to work properly will be to accept that the English community is not superior or more authoritative than the others, but simply the one with the best-understood language and the majority of members. While central discussion across language communities should indeed be held in the lingua franca of today's world, the idea is to avoid central discussion in the first place, whenever possible. Each subcommunity can discuss things in their own language, and ideas can be exchanged across subcommunities at a central level. Clearly, people who speak two or more languages fluently are crucial there.

But the main idea is to have everything working for both people that have the support of many editors who speak the same language, and for those that have none. The mission of OmegaWiki is to create a dictionary in all languages, period. We will need to develop systems that work for the dictionary to be created, not for any language community to feel happy without relation to the dictionary. To which extent the latter is going to follow the former will be something that is in your own language community's hands. I expect some people won't be satisfied by the way things work, and they are free to fork, but that should not prevent others who are part of that language to continue. In other words, I don't think language subcommunities should be one whole, inseparable, like the current wiktionaries are, and like Lmaltier's idea suggests. In that aspect, there is only one community, of course. — Vildricianus 12:24, 26 July 2006 (CEST)

Language and Communities[edit]

Well I already wrote about this almost a year ago .... http://meta.wikimedia.org/wiki/Ultimate_Wiktionary_%E2%80%93_what%2C_why%2C_where%2C_when%2C_who#Languages_and_Communities

I hope you will appreciate that "English centered" was never considered as such, because OmegaWiki developed out of the Dutch and the Italian community then considering mainly languages like Sicilian, Neapolitan etc. that have more difficulties in getting the right exposure then any other of the "big" languages.

Please read the link above ... well, if you read the whole article, maybe you will also understand a bit more about the "History" of this project - who believed in it and who not.

Most problems already have been consideren in particular talking and thinking in the direction of minority and regional languages.

Thank you for you time. -Sabine 22:51, 26 July 2006 (CEST)

Unless anyone thinks it's premature to open the Spanish language "beer parlour", I'd like to do so, with the help of the Spanish Wiktionarians, of course. The existing Spanish language Wiktionary discussions occur at Wikcionario:Café. "Expression:" is obviously reserved, though, so should it be at Portal:spa/Café? Rod A. Smith 00:25, 27 July 2006 (CEST)
Hi Rod, of course you can open the Café whenever you feel that time is right. There is one thing we then need: if there are questions you cannot answer, please tell us - well I understand quite a bit of Spanish, but I could not answer. This is the moment when our "interface people" need to show up and help with communication. I feel it is a good idea if we start to have one or two Beer Parlours or Café o Circolo in local language. In that way we will automatically start to build effective communication ways between the communities that have different languages - and of course these systems are easier to build when we start bit by bit to implement them than having the necessity to cover immediately all languages. Btw. there is already a different Beer Parlour that was created due to a discussion in the linguists chat on IRC - it is not active yet, but over time I suppose it will be. So have fun :-) --Sabine 09:56, 27 July 2006 (CEST)

a matter of fact[edit]

  • It is wrong to assume that Definitions are in English in the first place. I have created 1st definions in other languages, so i can tell that they don't have to be in English. Btw. I did not translate all of them to English, so if I weren't capable to read or write English, I still had nothing to complain as far as creating DefinedMeanings and adding stuff in my language is concerned. -- Purodha Blissenbach 08:49, 27 July 2006 (CEST)

Opinions[edit]

  • Leaving alone the fact that, there will not be many opportunities to vote, given the rigid technical structure of OmegaWiki,
    • Where are votings of all communities in all languages now? Yes, it is nothing but the Wikimedia foundation Board elections. Looking at the list of voters, their vast majority is from the english Wikipedia, almost the rest is German or from few more European Communitites.
      • You want that changed? I suggest you start selling cheap computers and cheap internet access and reliable electricity supply to the poor of this world, and provide them with sufficient leisure time to become interested in fun stuff like OmegaWiki. Sorry if I sound bitter.
  • What is going to change, whe existing Wiktionarians become WiktinarianZ?
    • They switch software underlying their project.
    • They receive some data from other projects, my guess is, they'll like it.
    • More than with Wiktionary in the way Wikimedia Foundation structures them, OmegaWiki would support several communities of a single language. Take the 'cultural split' of the promoters of Bjelorussian → OmegaWiki certainly allows them to have completely separated community pages, separated domains (or language variety codes, or spelling system identifies, or what; I'm not informed enough to tell which), they do not even have to talk to each other, and still both communities can work on and expand the OmegaWiki data base with their orthography and their language variety.
  • Again, what would be the need for a discussion between each and everyone?
    • technical matters are going to be coordinated between technical peple in the languages concerned, so e.g. European language adminstrators might agree on some common grammatical features, and their mapping from one language to another, which might ease and support translation in a more strutured way than pure word matches do. Ok, who then is possibly part of those discussions? People who could enter translations, i.e. bilingual or trilingual contributors. These can meet in the several bilingual or trilingual corners of the "beer parlor", draw their conclusions, and start implementing stuff.
    • natuarally, this will, at least slowly, be spread by bilinguals having different 2nd languages, so if there is sufficient interest, word about ideas and solutions will spread.
    • If there is a community of sufficient size, allways there are likely also enough translators. If there are not, OmegaWiki will have 'white spots' in the translations table, until matters change, or a language dies out.
    • Maybe we'll not be able to catch all of the about 10.000 languages there currently are. Sadly I must say, we probably shall have to cope with that, then. But likely we are to catch the most vital ones.
  • Community or communities? A big community has subgroups. That seems unavoidable, I am afraid, it is owed to the limited number of contacts man can have within any given period of time, e.g. his electronic presence in OmegaWiki.
    • Part of this is psychology - how do people feel? Rather isolated or part of a community?
    • So there will be subgroups or communities based on various demand, such as language, common languages, technical interest, cultural denomination, subject matters, etc.
    • Since every language communitiy, due to data base design, immediately can see the benefits for themselves that arise with the work of the others, at the minumum making additional translations availabe, a feeling of gratitude is likely there, psycholigically supportig the feeling of one big community, no matter wether or not one can directly talk to each other.
    • If there are enough online contacts to fill their time that engage in direct communication in their languages, the need to talk is sufficiently taken care of, no matter how many there are, one was not able to meet.
  • So we can conclude, large enough (or active enough) communities of each language will do.


  • A word on votings:
    • People can vote an everything they like. No-one will prevent them from doing that. Yet it might not always make sense.
    • There is no point in voting on Grammar.
      • e.g. I for one know that Kölsch verbs have two continuous forms, one being build with "am sein" + <infinitive>, the other with "důnn" + <infinitive> - so why vote?
        • Even if the community would vote that, either it was not so, or, if so, they would not want the continuous forms in their grammar records → so what? I'd initiate a fork, we were going to have two communities, maybe, we were sharing all data except one or two records of grammar rules, and I knew beforehand that, on the long run, "my" community was likely to be more successfull, simply because it got the grammar right. So I would not care about the voting. Why then vote at all?
      • Anyone can use OmegaWiki the way they want, it is free content. So there is no point to vote on specific use issues.
      • Even if it comes to trivialities, like a green, or a blue logo on some entry page - if there is enough support for either, it would be simple to have two entry pages having distinctly colored logos, so what?
      • If someone comes, asking for a vote whether or not he should be allowed to, say, transfer his or her collection of dictionary entries into WiktionarieZ → Most likely everyone is going to tell him "go ahead without asking", but even if not, even if a voting turns his offer down, will he technically be able to share his data, since OmegaWiki is open to that by design. So what to vote on?
    • Imho it boils down the the recognition that, for the community a as a whole, not much more than "board of directors" or "technical steering commitee member" type of elections remain beyond trivia.
      • Ok then, these can even be had without everyone's vote on a OmegaWiki wide level, if they're held in a 'republican' way, where each community, elects representatives, who then in turn will discuss candidates and hold the final election. By sheer numbers, communication will be easier among representatives, since from 7500 languages we come to, say 2537 at most, if we elect only 2537 representatives. I'm not in favour of this approach, but it certainly was an option with a potential to require less demand that, each should be able to talk to everyone.

-- Purodha Blissenbach 08:49, 27 July 2006 (CEST)

Nothing to add :-) great! Ciao :-) --Sabine 09:59, 27 July 2006 (CEST)
I’m very glad to see that I’m not the only one to consider this issue, although everything I read confirm that I understood the problem well, and that I could repeat every word I wrote. The current view seems to be that this issue is not important, compared with advantages OmegaWiki will bring, and there is therefore no need for dealing with it in depth. This reminds me of the European Commission, where the national language issue is the most touchy one, so touchy that the subject is usually avoided, and this has very bad consequences.

Actually, this issue is very important. We must remember that:

  • all contributors are interested in language (of course)
  • most of them are most interested in their own language
  • many of them are very touchy about it. Typical examples are Dutch-speaking people in Belgium and French-speaking people in Canada, but we must remember that most languages in the world might well disappear, and it is very normal that this is a touchy issue.
  • given this, it seems obvious that the fact that wiki-wide decisions will be taken in English would not be acceptable to many of these contributors, and that either many wiktionaries won’t migrate to OmegaWiki, or they would lose many of their contributors. Few or many decisions, this does not change anything on the principle. We may think that nothing justifies this reaction, but this is a normal reaction.
  • the high-level Wikimedia wiki uses English as the communication language, but it is a separate wiki, and that changes everything, from the psychological point of view.

The constructive way is to try to (fully) solve this issue, while keeping all the advantages OmegaWiki brings. This requires open-mindedness, imagination, and accepting that the current view is not intangible. But it’s well worth the effort. My proposals were tentative tries towards this objective.

I am aware that I’ll probably not get much support, because people I speak for are not present here, and because all people reading me can speak English. Nonetheless, I would like to see proposals I made considered and discussed, and other proposals emerging as well. Lmaltier 19:19, 27 July 2006 (CEST)
I think the people who are most involved in the project probably do realize how important this issue is. But I guess that it won't be clear how it'll develop until WZ is fully operational and open to all kinds of editors. I also have to remind you that the old Wiktionaries are free to choose whether or not they merge their project and community with this one.
You mentioned something about Dutch-speaking people in the Netherlands... That example I don't get. — Vildricianus 19:30, 27 July 2006 (CEST) It was Belgium, thank you.
WE ARE IN PRE-ALPHA STATE - definition: OmegaWiki is not complete - many features are missing. Until OmegaWiki is not feature complete at least I will care mainly about getting OmegaWiki as complete as possbile. Then and only then (because a day has only 24 hours) time is due to take up all sorts of issues relatet to OmegaWiki - and believe me: many were not even mentioned here. If we think about all sorts of problems now, we will never be able to get at full production state. If someone wants to open beer parlours in local languages and then immediately start to care about all the issues that will arise out of this, you are welcome. I can only talk for myself and this means: I don't have time to care about communication between differnt language communities in this specific moment and therefore I will remain with English as linguae franca until WZ is feature complete. I hope this is understable to most of you. Now it is time to stop here and care about technical issues. Thank you! --Sabine 23:49, 27 July 2006 (CEST)
OmegaWiki does not aim for the end of Wiktionary projects. It is up to each individual and each community what they want to do. As we take no position on this issue, it is not our concern, we also do not take a position as to the dillution of Wiktionary projects. That is also not our concern.
The major concern we have is for our users. The point is to provide a great service, a service that seems to change to fit the need of the user. When the arguments around OmegaWiki or Wiktionary centre around the EDITORS, we have our focus wrong. Projects like Wikipedia, Wiktionary, OmegaWiki are there to serve a need. This need is to provide information. Having a vibrant community is the means to this end. GerardM 08:10, 28 July 2006 (CEST)
Changing the interface so that OmegaWiki externally appears as a set of wikis (one for each language, and one for technical discussions about software, etc. (this one probably in English)) does not seem such a big change, and it would make OmegaWiki a possible success... But I'll let you work, and won't break the taboo any more. Lmaltier 15:55, 29 July 2006 (CEST)
It is annoying that you insist that you know best. I do not know how things will eventually look like. I am only certain that it will be different from the way it looks at the moment. What I have always said is that the look and feel will be configurable. Technically there are things like skins. We will have different skins. If the French want their own skin, fine .. up to a point. What this point will be, do not ask me now. There will be no artificial seperation between the data that is the one thing I will insist upon.
You implied that there would be this thing that can not be talked about taboo. I will tell you what should be a taboo; people who explicitly say from the start that they will not involve themselves in the project and THEN have the audacity to say that the project has to be run in a different way. GerardM 18:10, 29 July 2006 (CEST)
OmegaWiki will not appear to be more wikis - it is one wiki and it will have user interfaces in different languages (just like now you can choose to have a whatever UI on fr.wiktionary.org). Sorry Lmatier, but I never saw you around before, you did obviously not ask questions, but just make assumptions. It also seems that you did not even look at the link I provided (or maybe you do not understand what is written there - if you don't understand: please tell us). We have been working on this project since 30th of August 2004 always having two things in mind: how to give the best results to users and how to help contributors actively to well invest their time. How this time is better invested, how we think to get users talk - that is written on meta - and it was published there approx. a year ago. Please read up on this project before you start to presume this or that. What I really did not like is that you came here, to a pre-alpha project (and we explained you what this means) not willing to understand that what we have here now is not the finished product. You refuse to do so and to understand that we now must care about the product and its functionality and that we practically don't have time to do all kinds of theoretical assuptions. Problems will arise - that is sure - they will be solved when they come up and not hypothetically assuming this or that spending hours and hours in discussion now only to find out that all is different when we have full production state. It simply does not make sense. It is not taboo to talk about "real problems" and for me you can talk 24 hours a day about hypothetical problems: but please understand that we work here and not just come along every now and then to discuss a potential problem of which we do not even know if it is going to arise. Somewhat irritated ... --Sabine 19:12, 29 July 2006 (CEST) (sorry forgot to sign)
Lmaltier originally posted his thoughts at Gerard's talk page at en:wikt. It was me who told him to try out restating it on this page, where it belongs. And it still belongs here. It's a very real problem not that obviously solved, however functional software can get. Concealing it behind the face of the "pre-alpha" meme is perhaps a good temporary solution, but hardly any constructive. Now I don't say that you need to argue about this for hours on end, or even reply at all, but at least allow other people to state their opinions, concerns and ideas about the future of WZ, without giving the notion that they first have to read up on a gazillion documents and stuff before they're even allowed to comment here. I'm sure there are things neither of you have ever thought about that someone might point out here one day. There are better answers to this than a we're-in-pre-alpha-state-so-don't-let-me-be-bothered-by-this-now attitude. A wiki is a wiki. — Vildricianus 16:42, 30 July 2006 (CEST)

Enotif for watched pages[edit]

Well, we are getting to a stage where we get many, many pages to look after ... that means at least for me enotif for watched pages (that can be activated or not through a checkbox) makes sense. It became hardly impossible to follow all the recent changes and often changes to the Beer Parlour or portal pages are simply not seen. I'd very much like to see this feature. --Sabine 09:59, 27 July 2006 (CEST)

For all that do not know yet: with Invert selection on recent changes you can select all these changes. Notice the ticked box ([v]) on Invert selection. HenkvD 23:43, 27 July 2006 (CEST)

Permission given to use word collections under GFDL[edit]

Dear project members, today I have contacted Dr. Paul Rayson, Director of UCREL, and requested permission to use the data linked to on this webpage containing information on words frequencies in English spoken and written language. To my surprise he has given a positive reaction really quickly and agreed to release that data under GFDL. I will soon upload this data to the wiki and hope we can make good use of it. Siebrand 23:19, 27 July 2006 (CEST)

A list of 7726 most often used words in the survey has been compiled in 8 pages beginning from List of most frequently used English words (1-1000). Siebrand 14:36, 30 July 2006 (CEST)

User interface in your mothertongue[edit]

Today we got new functionality that allows you to have definitions in the language set in your User Interface. When this setting is not set to English, the definition will be shown in the language selected. When there is no definition, it will show the definition in English. When there is no definition in English as well, it will show the definition that is there..

The challenge is obvious; have as many definitions in your own language (do not forget about the DefinedMeaning). Thanks, GerardM 14:13, 28 July 2006 (CEST)

Formatting of Definitions[edit]

Do we need a standard for how a Definition should be formatted? Right now we have Definitions that start with capital letter and those that do not. We have Definitions that end in punctuation marks, and those that do not?--Sannab 20:57, 28 July 2006 (CEST)

Great, this is one of the things that never appear to get settled over on en:wikt. At school, I learnt to properly start sentences with a capital and end them with a period. I've never understood why a dictionary wouldn't follow that standard. — Vildricianus 21:03, 28 July 2006 (CEST)
I don't have a strong opinion about it, so I'll be happy with either outcome. I just want to point that definitions are not "properly" sentences, so the rule to capitalize sentences does not apply. Still, I don't care either way. Rod A. Smith 21:32, 28 July 2006 (CEST)
I'd prefer capital letter and full stop, personally. Not least because we show them in the row at the top, and that looks severely odd without. And without a fullstop, it just looks incomplete somehow... —Celestianpower Háblame 23:04, 28 July 2006 (CEST)
We will need to develop some kind of Style guide (à la w:Wikipedia:Style guide). — Vildricianus 23:10, 28 July 2006 (CEST)
Please add on Definition#Guidelines for writing good Definitions --Sannab 23:21, 28 July 2006 (CEST)



International Beer Parlour

2014[edit]

2013[edit]

2012[edit]

2011[edit]

2010[edit]

2009[edit]

2008[edit]

2007[edit]

2006[edit]