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

From OmegaWiki
Jump to: navigation, search

Contents

2014[edit]

2013[edit]

2012[edit]

2011[edit]

2010[edit]

2009[edit]

2008[edit]

2007[edit]

2006[edit]

Collections[edit]

Hello, Iwanted to know how I could see all DMs in a collection ? Is there such a page (like Special:Whatlinkshere) which provides this kind of information ? Thanks, le Korrigan bla 10:51, 10 November 2006 (CET)

We are working on exactly this. I expect something along these lines in the next weeks. GerardM 11:24, 10 November 2006 (CET)
OK, thanks ! le Korrigan bla 12:03, 10 November 2006 (CET)

lld[edit]

Would it be possible to add "lld" language (my language) to the language list? I could add some words... :) We already have the babel infos for lld... Dennis 22:41, 13 November 2006 (CET)

Yes, we can. Have fun adding Ladin :) GerardM 23:43, 13 November 2006 (CET)

Credits...[edit]

I am negotiating the licensing of a database of ~10k definitions in ~10 languages with ~1M speakers. The copyright holder may want credit, probably at the level of expressions. My proposed solution: add a copyright character which holds a link to the credit (Which would read something like "This data provided from [blah] thanks to blah, licensed under GFDL with no invariant sections." and have a talk-page explaining the circumstances and asking people to please not remove it.) I would then tell the copyright holder that there was no legal guarantee that the credit would follow the data, especially if rebundled, but that I had made a good faith attempt to see that it did. What do people think? Certainly, I can't use a linked word, it would be confusing and besides I can't say "credit" in most of these languages. And it seems excessive to ask for a whole new feature for this situation. I understand that people might not like the copyright symbol around here, but it has the advantages of being one glyph, being generally understood, and being correct in denotation (though not connotation). --Homunq 20:34, 16 November 2006 (CET)

OmegaWiki is available under both the CC-by and GFDL. What we CAN do is import data under a userID that is explicitly associated with the person/organisation granting us the right to use the data. We are also quite happy to publicly acknowledge the partners that make OmegaWiki a reality. :) GerardM 21:14, 16 November 2006 (CET)
I suppose a Collection could be used as well, to show the origin. HenkvD 21:42, 16 November 2006 (CET)

Italian's Interface[edit]

I can translate the interface in English, but I do not succeed to modify the system messages because the pages are protect. How translate I thwe interface? --Fede Reghe 21:54, 16 November 2006 (CET)

I suppose you know that the Mediawiki part of the interface is already available in Italian, and some dozen more languages? --Purodha Blissenbach 07:26, 22 November 2006 (CET)

The importance of an order and something more[edit]

By today's "Word of the Day" (Expression:smile), I really understood how important is an alphabetic order of the language names in the definition and translation table of each page. I think is nothing more than a row of SQL code and it would help really much... one thing more: I think is a good idea to consider giving a precise background-color to the language the users choose in the preferences. For exemple, this background color should be visible in the translations, in the definitions, etc.. I think it would help the user to find a quick correlation betweeen the page, the X translation on that page and is own mother language... Or maybe just to help him/her to quickly understand if a translation has already been added, etc.. What do you think? Other think: I'm trying to build up a simple XML script for OmegaWiki, a script that everybody could insert in his/her own google personalized home page (as it exists for Wikipedia, I'm starting from that script). Do you think this is a good idea which could help the wikitionaryz's development and spreading? Dennis 23:45, 17 November 2006 (CET)

For your first suggestion... you can click the heading of the tables (Either "Language" or "Spelling"/"Text" and it sorts it alphabetically. -Rappo 00:14, 20 November 2006 (CET)
Thanx Rappo, I didn't notice it. Dennis 10:33, 20 November 2006 (CET)
Wow. I did not know it either. It should be made more noticable (as it is in many databases). HenkvD 20:36, 26 November 2006 (CET)
Yes, but you cannot sort the list and record it : it remains unsorted ! Grasyop 23:07, 7 December 2006 (CET)

about "Annotation"[edit]

I saw that we have a new thing near each object in modification mode. Its name is "Annotation". What exactly is its destination ? luna 10:28, 22 November 2006 (CET)

And as I am asking stupid questions : how can we use "alternative definitions" ? and why ? luna 10:39, 22 November 2006 (CET)

Last stupid question : Is there any place (but IRC) to find information about all that (new) stuff on the definitions pages ? What about Collections, Class, Relations and all those I did not see ?

Collections and Relations can be found at Editing relational data. Class cannot be used yet. Annotations should be added in there as well, but I don't know if and how to use it either. HenkvD 10:57, 22 November 2006 (CET)
"Annotation" will be used for example to add example sentences, but this is not active yet (there is nothing to select in the drop-down box)
"alternative definitions", not sure how to use it. I guess some words can be defined for example in a normal way, understandable by most people, and in a scientific way, more accurate but harder to understand. (I have no example in mind).
"Collections, Class, Relations" How come I had never seen the page HenkvD mentioned? It should be linked from the English portal, and maybe the main page... I will translate it when I have time. Kipcool 11:32, 22 November 2006 (CET)
There ia one other page How to edit the dictionary entries, setup to edit OLPC definitions. Strange that none of these are linked from the main page. HenkvD 11:44, 22 November 2006 (CET)
I added relevant links to the main page, as I did for the French mainpage. Other languages should update their main pages too, I think. Kipcool 12:58, 22 November 2006 (CET)


Translator page[edit]

Do we have, or should we set up, a page where we post information that should be translated in other languages? Like for example:

You mean a Requests for translation page like it is used on meta? IMHO that would be a good idea. There are people who feel better to do such things instead of adding terminology. --Sabine 13:15, 22 November 2006 (CET)
Forgot: having that WikiRead WikiWrite feature for OmegaT would be really interesting for such stuff .... --Sabine 13:17, 22 November 2006 (CET)


Preventing orphans and double DM's[edit]

I want to propose a few minimum guidelines for creating new DM's to prevent Orphans (Expressions that are not linked to other expressions) and in that way preventing double DM's.

  • A new DM should have a definition. Sounds logical, but see Medizinpflanze. Examples are not ment personally (in fact you can't see who created these).
  • A new DM should have a few translations into other languages. See Hiphop, it has only synonyms in German. Don't create a local dictionary.

Without these guidelines the chance is almost zero that an other user will find this DM when he/she want to start an expression in an other language.
Preferably: add as much translations as possible and translate the definitions in a few major languages. Adding relations might help as well to find a related DM. As OmegaWiki is in a pre-alpha stage of development the goal is not to create as much DM's as possible but to get the software on a higher level. HenkvD 20:17, 26 November 2006 (CET)


Insect room and Bugzilla[edit]

See all 11 issues that were reported in the Insect room and were ready for Bugzilla here. Siebrand 15:24, 30 November 2006 (CET)

Special:Statistics[edit]

Special:Statistics count seem to miss out the most relevant namespaces. It is necessary to have them counted by Special:Statistics for OmegaWiki making it into the top http://s23.org/wikistats/wikis_html.php

192.168.0.1 16:06, 11 December 2006 (EST)

Yes, we should replace it with the number of article of the Expression namespace (number 16). Apparently, a dev has to do this. Any dev around? Kipcool 16:10, 11 December 2006 (EST)

Sidebar link to MainPage[edit]

I am trying to make the "Mainpage link on the side bar" link to the French main page, but whatever I change (MediaWiki:Sidebar/fr, MediaWiki:mainpage-url-fra,...) it still links to the English Main Page. Has anybody done that for another user interface? Kipcool 10:13, 13 December 2006 (EST)

Apparently a problem with the Mediawiki software itself. — Pill δ 17:21, 16 December 2006 (EST)
Yes, you can do that in the same way, I did it for russian. I posted a description to the insect room, which may be archived by now. One step of the tricks was a redirect from manipage/fr → manipage/fra if I recall it right… --Purodha Blissenbach 20:59, 16 December 2006 (EST)
See Insect_room/Archive#.22Main_Page.22_link_always_leads_to_English_page, but I am not sure it works correct as the russian mainpage is not linked now. If sombody gets it working: could he/she do it for all other mainpages as well. HenkvD 10:28, 17 December 2006 (EST)

How to edit this message?[edit]

When anonymous (or users without wikidata rights) the following message appears:

Closed alpha testing.
Editing is limited to a closed group of users until we have versioning and changelogging. Please contact GerardM or another member of the OmegaWiki Commission for access.

How can this be edited (and changed to the OmegaWiki Commission)? I can't find it at the system messages. HenkvD 08:55, 16 December 2006 (EST)

Bots on OmegaWiki[edit]

Yesterday evening I got so sick and tired of manually replacing WiktionaryZ by OmegaWiki or Expression that I decided to make the pywikipediabot framework work with OmegaWiki. And I got it working, except for one 'minor' details: case sensitivity on the first letter of a page name. This morning GerardM found a solution for that. And then it was like Expression:De beer is los.: the bot made a few thousand succesful edits in the Portal namespace. I currently have no idea on how the bot would do anything within the WikiData namespaces, but at least we have created access. If you're in a hurry to start botting, please drop me a line on IRC or on my talk page. I will ask Andre Engels to add the changes for the framework to work with OmegaWiki to pywikipediabot as soon as possible. Cheers! Siebrand 07:20, 20 December 2006 (EST)

Adding content to the relational part of the database is to be done after consultation. It is NOT a good idea to indiscriminately add content. This will lead to an utter chaos. Once you have identified a DM as that specific concept you have data for, that is the moment when you can start uploading.
At issue is that as long as we do not have the tools to merge content, automatic uploads have to be handled with care. GerardM 07:43, 20 December 2006 (EST)
Using it has very little to do with getting the tools to actually do it. I very much encourage the development of ways to change the data with a bot, even though we do not yet know how we will use it. Siebrand 08:32, 20 December 2006 (EST)

Shortcuts[edit]

Hello,

Here I have made a template for shortcuts to come to meta-pages easier and faster. But now I don't know: Should we make all shortcuts with the prefix OW: how the German Wikipedians and Wiktionaryans use to do it (with the prefixes WP: and WT:) or should we make shortcuts with the prefixes of the namespaces (e.g: M. for Meta:) like in the Meta-Wiki of Wikimedia or should we pass on prefixes? Or are the shortcuts a bad idea? Your statements, please! :-)

--Möchtegern 08:02, 20 December 2006 (EST)

P.S.: For this page the shortcut would be OW:IBP, M:IBP or IBP.

And how should we handle different languages? DM (exists already!) for DefinedMeaning and DM/fra or SD for DefinedMeaning/fra or SensDéfini? HenkvD 11:01, 20 December 2006 (EST)
I don't know. On the one hand the page is called DefinedMeaning/fra and you can memorise DM/fra, if you can't speak french. On the other hanside SD is shorter ans if you can't speak french, you won't need a shortcut for this because you won't need this page. What thinks the others? --Möchtegern 13:11, 20 December 2006 (EST)
  • Why do you think a shortcut like DM/fra would be used for?
  • Currently, you can as well us DM and, then follow the link "français" on the page.
  • With the advent of MediaWiki mulitlingual MediaWiki, I suppose, software will take care of that automatically, and serve a page in your language (as set in your user preferences), or a choice of available languages, if there is no translation to your selected language.
  • Currently, my preference is for short shortcuts, i.e. no colon-prefixes. I might change my mind on convincing arguments, however. --Purodha Blissenbach 10:12, 23 December 2006 (EST)

Seasons greetings ..[edit]

:-) Knopfkind 06:41, 23 December 2006 (EST)

Merry Christmas - :) GerardM 06:19, 23 December 2006 (EST)

Merry Christmas to all of you!!!--Sabine 13:17, 25 December 2006 (EST)

Part of speech[edit]

Now that we have part of speech, it is of paramount importance that we get complete overviews of the parts of speech of various languages. I have created a more or less complete, as far as I can see now, overview for Dutch. Please add a page for your language and build a similar tree.

Adding the parts of speech to the annotation interface is a bit tricky at the moment. Please ask for advice on IRC before experimenting. Siebrand 07:28, 25 December 2006 (EST)

  • would it be useful to made "case walk trough" description? - Likely only if it can be expected to hold some time, am I right? --Purodha Blissenbach 09:39, 25 December 2006 (EST)
    • I think a description would be very usefull. HenkvD 14:10, 25 December 2006 (EST)

facilitating translation of critical documents[edit]

  • Create a list of documents that we think are critical for the understandig of new editors in this wiki with links to the /Translations template
  • Set up a translators guide
  • Set up a translators coordination centre

(just in case I am not able to execute this myself) Siebrand 10:00, 29 December 2006 (EST)

    • Wee! Done! Just add something like {{Translations|lang=nld}} ({{Translations}}) to your language portal and you have all resource links and target links at your fingertips. Please improve where you see fit. Cheers! Siebrand 13:43, 29 December 2006 (EST)



Translations without creation of a new expression?[edit]

Hi folks. I think it can be helpful, if we had the possibility to decide if a new expression is automatically created when one adds a translation. For example, there are some DMs where language X doesn't have a single lexeme for, but where a translation made of several lexemes is used (there is no word for "turn of the year" in English, for instance, but there is one in Dutch and German). This translation should not be missed on the page of that DM, but it should also not exist as an expression. We shortly discussed that in the chat, but I want to know more opinions about that. Saludos cordiales, --Thogo (Talk) 19:00, 30 December 2006 (EST)

I agree with Thogo on this, as I said on IRC. When translating, I want to know the expression that a speaker of that language would use for a concept, even if it involves more than one word. ¡Feliz nochevieja! —Celestianpower Háblame 19:09, 30 December 2006 (EST)
I would think that it suffices to have the definition translated. GerardM 19:27, 30 December 2006 (EST)
That's what I don't think. If I look for "Jahreswechsel" and want to know how I say that in English, I will be not satisfied finding just the definition translated, because I know what a "Jahreswechsel" is. I would be searching for "turn of the year" and would be consternated if I don't find that on the page. --Thogo (Talk) 19:50, 30 December 2006 (EST)
We are not in the business of making up new words. If there is no such word we do not make them up. GerardM 03:45, 31 December 2006 (EST)
The suggestion is, to store a translation without creating an expression at the same time. I wonder, wether a translation of the concept will do, if one wants to translate a word or an expression to a target language not having an adequate word, but maybe be an usual way to express the concept? From a practical standpoint, if I was looking for a translation, I would be most satisfied finding "turn of the year" as either the Definition or among the translations. If I were not good at english, I might otherwise be tempted to use "change of the years" or "switching years" or something similar, which of course noone really uses, or I might try to split a compound word into its parts, and translate them one by one, in such cases. So, while I think, indeed, we should not make up new words or expressions, having a translation handy would be beneficial, even if an expression as such, or a word does not exist in the target language. --Purodha Blissenbach 06:31, 2 January 2007 (EST)
Yes, that's what I meant. I didn't suggest to create new words... --Thogo (Talk) 10:19, 2 January 2007 (EST)
Yes, no-one is suggesting creating new word. What we're suggesting is that you should be able to translate the concept, even if there isn't a word for it. As with the example, we would say "turn of the year", and that should be indicated on the page. Regards, —Celestianpower Háblame 17:40, 4 January 2007 (EST)

Previews[edit]

Could a preview functionality be added for use when editing? I made about 8 edits when I could've made just one having previewed it. I decided to move this to the functionality wanted section, where it belongs. Oops. Jfingers88 14:55, 2 January 2007 (EST)

Relations Question[edit]

Hello, I have a question about using relations. I've recently been adding a lot of federal subjects of Russia to the expressions here at OmegaWiki (mostly to see relations put to an interesting use), however I think that the relations seem to be getting redundant. For example, the Central Federal District has "is part of theme Russia" as a relation. Should Moscow, which is a federal city inside the Central Federal District) have both "is part of theme Central Federal District" AND "is part of theme Russia" as relations? Or just the former? Thanks, Rappo 09:41, 3 January 2007 (EST)

The relation types that we currently use have been inherited from GEMET, as such they demonstrated really well our ability to include relations. Before we can include other resources, we will need to use more clever relation types and, they need to be much more focused as well. I do not know really what a "theme" is.
What we are working on are three types of relation types:
1 Universal relation types; they can be added everywhere
2 Domain relation types; they can be added when specific conditions are set
3 Collection relation types; they can only be used to link DM's that are part of a specific collection. In essence these relation types are the ones that we would like to integrate with domain relation types and NOT make them collection bound.
So yes, it is ambiguous at the moment. It is a function of our current to be improved on functionality. GerardM 10:06, 3 January 2007 (EST)
Imho there is a quite different use for collections from domains. Let me give two somewhat exaggerated examples illustrating that:
  1. A car maker having certain models and having certain parts built into them may want to share his terminology of auto parts, e.g. so as to have repair shops and do-it-yourselfers find their official ways of naming them. Thus, a "Model-T central motorblock straight swing lock bolt of 1926 to 1929" may be in the domain "auto parts", or possibly "Ford Model T auto parts" but as well in a collection that is administrated by Ford Motor Company, since in addition to the plain fact of belonging to a domain of speech, or to a domain per subject of speech, it has an index in the collection, say Fords part number, which is given to it by an authority responsible for defining exactly this collection.
  2. There are several collections of languages, e.g. ISO 639-1, ISO 639-2 terminologic codes, ISO 639-2 bibliographic codes, ISO 639-3, one defined by the IOC, and likely several more. Different codes or numbering systems index them, all which are under different administrating authorities. Yet all language names themselves, semantically, are in the Domain of language names - unlike the codes which are serving diferent purposes, and therefore can be said to be part of different themes, or in different domains - language names themselves are not.
As a result, I see overlapping yet different areas of applications for Domains and Collections in the way they exist now, be it implemted or planned. --Purodha Blissenbach 12:23, 3 January 2007 (EST)
What Rappo asks in the original question: should we use only A is part of B, B is part of C, or should we include redundant relation A is part of C as well?
My view on this is generally: do not use additional redundand relations. There could be exceptions though, especially in the example of Moscow. It is the capital of Russia, as well as a city within the Central Federal District. Many of the other relations can be removed in my opinion. I had entered these at the time that the regions were not yet defined.
On the other hand all terms within for instance chemistry (see incoming relations at chemistry; have a few seconds patience when you sort them alphabetically) could be a usefull list. Personally I think it is too difficult to keep such lists complete, with the result that a user incorrectly assumes a term is not available, although it is present on a deeper level. HenkvD 14:15, 3 January 2007 (EST)

Handling transisivity[edit]

How can I express the suppletion/intransitivity of this verb?

  • to go
  • he/she goes (third-person singular simple present)
  • he/she/it is going (present participle)
  • he/she/it went (simple past)
  • he/she/it is gone (past participle)

Thanks, MovGP0 17:16, 5 January 2007 (EST)

At this moment you cannot. This is part of the inflection / conjugation functionality that we do not yet have. GerardM 17:34, 5 January 2007 (EST)
I suggest to handle such words as translations with equal meaning. Then we add additional Informations like Time and Person by using Annotations:
go { time:present, mode:simple, person:I, person:You }
goes { time:present, mode:simple, person:He, person:She, person:It }
going { time:present, mode:participle, person:They }
going { time:present, mode:participle, person:I, person:You, person:He, person:She, person:It, person:They }
went { time:past, mode:simple, person:I, person:You, person:He, person:She, person:It, person:They }
gone { time:past, mode:participle, person:I, person:You, person:He, person:She, person:It, person:They }
We use a similar technique to map for "be" (namely am, is, are, was, were, and been). For some Languages we need special times and modes, but I think this technique can handle this. Also ie. in German each Noun is mapped arbitrarily to an Article. This technique yould also get used in this case. ie. "the Shild" is translated either with "der Schild" or "das Schild":
Schild { Article:der } // Security-Weapon; male
Schild { Article:das } // Sign; neutrum
MovGP0 10:22, 6 January 2007 (EST)

In OmegaWiki we have started to include part of speech in a way that makes it language dependent. We have a noun in German because someone who KNOWS included the noun for German. Nobody has so far indicated for Russian that it definetly has a noun. When we add genders to German, I know for SURE there are three genders like I know for SURE that French has only two. The choices will be predetermined per language. This is how a database oriented approach differs from the approach you propose.

When you have identified how a languages conjugates its verbs, we can typically infer that a specific conjugated form translates to another language. This means that we can populate the DMs of conjugations automagically. This is functionality that will make the effort of the work people put in OmegaWiki more effective.

This is why we want proper functionality and not a hack. NB the hack is how you can only make things happen in Wiktionary and truly the ingenuity that goes into these is remarkable. Thanks, GerardM 11:18, 7 January 2007 (EST)

IPA transcription[edit]

Hoi, I have written on the blog about IPA transcription. I think it is relatively straightforward to have IPA transcription. The problem is that in order for it to be useful to ALL people, we should adhere to the IPA standard and not use any of the tricks to make it easy on English speaking people. This probably means that much of the IPA out there is not useful for us as a result.

This needs discussing .. :| GerardM 01:11, 8 January 2007 (EST)

With varying English pronunciations worldwide, I am tempted to collect only sounds and transcripts for the variants eng-GB, eng-AU, eng-IN, … etc., possibly not for plain eng. --Purodha Blissenbach 06:28, 8 January 2007 (EST)

Could you give an example of the tricks used for English IPA? I'm wondering if we're doing the same for French... Thanks. Kipcool 08:08, 8 January 2007 (EST)

Generating IPA[edit]

Dvortygirl pointed me to a free program called the Praat, that can generate IPA from sound files. I plan to make it possible to use it in an automated way for generating suggested IPA transcripts, when sound samples are available. --Purodha Blissenbach 06:28, 8 January 2007 (EST)

  • It's called simply Praat, not the Praat :) I know because it is installed on many university computers by default. I'm not too familiar with it myself, but I believe it can convert IPA to speech, too. László 09:30, 9 January 2007 (EST)
    Yeah but we'd probably want to use that as a last resort. IPA to speech is very approximative. --Moyogo 19:25, 11 January 2007 (EST)

Abbreviation[edit]

I think we should introduce abbreviation (eg. "eg.", "i.e.", "z.B.", etc.) and acronym (eg. "IPA", "ESP", etc.) as a new class of word. (see also: german PoS) Thoughts? MovGP0 09:01, 9 January 2007 (EST)

The problem is that an acronym is used in the same way as the phrase it is an acronym for. GerardM 11:45, 9 January 2007 (EST)
But you coul'd provide automatic translations of the acronyms into the long form for doing translations. Also the Acronyms in one Language may get translated directly into the proper Acronym of the other language:
Language tagged as
Text/Phrase Acronym
English one Laptop per Child OLPC
Portuguese um Laptop por Criança ULPC
Spanish una Laptop por Niño ULPN
German ein Laptop pro Kind ELPK
MovGP0 14:01, 9 January 2007 (EST)


  • Also - while I don't want to clearly suggest this as a grammatical property, abbreviations and acronyms are read and pronounced differently, such as:
Language Acronym/Abbreviation mostly read as either of
English i.e. that is
English etc. and so on
et-cetera
Ee-tea-see
English NATO Nato
English UTI Yoo-Tee-I
English aka ai-kai-ai
also known as
alias
German alias
auch bekannt als
ebenfalls bekannt als
auch bekannt unter dem Namen
aka
German BRAGebO Bragebo
Bundesrechtsanwaltsgebührenordnung
Bundesgebührenordnung für Rechtsanwälte
German BAföG Bafök
Bundesausbildungsförderungsgesetz
Bundesgesetz über individuelle Förderung der Ausbildung
German MDStV Em-de-es-te-vau
Mediendienstestaatsvertrag
Staatsvertrag über Mediendienste
I believe, we should note such properties properly. While having no example handy, I'm also pretty confident that, word-like pronunciation vs. spelt-out speaking for some common acronyms or abbreviations varies between languages. --Purodha Blissenbach 07:59, 11 January 2007 (EST)
That's easily solved: just don't check the Identical Meaning checkbox and provide additional translations if needed. MovGP0 18:34, 11 January 2007 (EST)
I don't get that - while of course, you can enter "alias" as a syntrans of "aka" checking the IdenticalMeaning flag does not serve to tell that a reader can say: "alias" as well as: "ay-kay-ay" while looking at "aka". But he cannot say: "be-ah-ef-ö-geh" when he's staring at "BAFöG", he must say: "Bafök". So we need a different indication of speech patterns for abbreviations and acronyms. --Purodha Blissenbach 00:14, 13 January 2007 (EST)
How people pronounce things is irrelevant on an Expression level. At this moment we do not support pronunciations at all. GerardM 08:28, 13 January 2007 (EST)
Not at the moment, sure, but you said, we were getting sound files, IPA, and the like. --Purodha Blissenbach 21:58, 17 January 2007 (EST)

Lingala[edit]

Could somebody merge the languages "lingala" and "Lingala (Latin)"? Thanks --Moyogo 19:24, 11 January 2007 (EST)

Done today --Kipcool 19:06, 17 November 2009 (UTC)

Mandarin[edit]

I've provided the most elementar mandarin PoS. Can somebody use this, so we can mark the type of the mandarin words using the Annotations? MovGP0 12:54, 24 January 2007 (EST)

Piedmontese[edit]

Is the right name for the language in english :) May we have its right name in the UI, please? :) --Bèrto 'd Sèra 17:42, 29 January 2007 (EST)

I am afraid that it is not. Google for it and the difference is glaring. GerardM 03:02, 30 January 2007 (EST)
There are 2 (3?) orthographies, see ethnologue. Kipcool 03:55, 30 January 2007 (EST)
LOL not meaning to open a political confrontation on it, but Piemontese really is an italian word. Wikipedia reports Piedmontese, while also quoting the italian name, and the ethnologue record has possibly been written by italian speakers. From wordnet (which has no reports on "piemontese" whatsoever) "Piedmontese" has:
---start quotation
1. (1) Piedmont -- (the plateau between the coastal plain and the Appalachian Mountains: parts of Virginia and North and South Carolina and Georgia and Alabama)
2. Piedmont, Piemonte -- (the region of northwestern Italy; includes the Po valley)
---end quotation
Piemonte is an italian toponim, the native variant being Piemont.
Now, our planet's climate is surely not going to be finally spoiled just because of a small mispelling, but I'd like to see it either written in its native form or in english :) --Bèrto 'd Sèra 15:22, 30 January 2007 (EST)
From further verifications... let it be Piemontese, no probs, just trying to find out where this thing sprang out from. Anyway, ISO and Ethnologue do say the same (piemontese, that is). English dictionaries usually do not. So it's probably something that happened during the classification :) Possibly someone simply mispelled the entry... see what ISO publishes as a name for the aue code :) --Bèrto 'd Sèra 01:43, 2 February 2007 (EST)

New version of Mediawiki[edit]

Wundervoll! Thanks Erik!

New features or corrected bugs I see are (please add if you see more):

  • random page now works (not only randomizing 5 expressions like before)
  • there is the functionality that you can receive an e-mail if a page you're following is modified (can be disabled in the preferences)
  • nice left/right stuff in the drop down box for languages :-)
  • ...

No Move tab?[edit]

The move tab has disappeared from pages from all namespaces. Is this intentionally or a mistake? HenkvD 14:56, 7 February 2007 (EST)

I think OmegaWiki has no real need to move pages. --Mkill 21:41, 8 February 2007 (EST)
Not for Expression and DM namespaces, but it's useful for the others namespaces. Kipcool 05:43, 9 February 2007 (EST)
I agree. Also, on my web server, where PHP warns for E_ALL, I get this on top of all pages:
Notice: Undefined property: Title::$isMovable in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\wikidata\includes\Namespace.php on line 178
This may or may not be related to this issue, but it sounds like it. László 03:11, 12 February 2007 (EST)

Shtooka[edit]

I have just blogged about a wonderful tool called Shtooka. When you want to record a list of words, you provide it with this list, you specify what language you are pronouncing and you just start recording .. Amazing .. :) GerardM 18:02, 8 February 2007 (EST)

Bot to split multiple expressions?[edit]

OmegaWiki still has a lot of expressions that are combinations of words, like something like Expression:eskuordetze; delegatze. These are inherited from GEMET and other sources, where the same meaning could not be entered with several synonyms in one language. In Omegawiki, we want these split. Couldn't a bot do that? All it would have to do is scan the database for expressions that contain ; , / and split these terms into two expressions under the same DM. The best would be a human-assisted bot that can reduce the work to do this to one mouseclick, something like Flaccus Interwiki-Link-Checker --Mkill 11:23, 9 February 2007 (EST)

An other task for a bot could be the removal of en-us translations that are the same as the en translations, also inherited form GEMET source. HenkvD 14:39, 9 February 2007 (EST)
I don't think it's a bad thing if a term is both in en and en-us. --Mkill 05:01, 11 February 2007 (EST)
It is not bad bad, it is not how we envision that we do things. GerardM 06:04, 11 February 2007 (EST)
As an answer to the original question: yes, that would be a great task for a bot. I believe there has been some work on a general OmegaWiki bot, but I'm sure GerardM has more details if there are any. László 18:10, 11 February 2007 (EST)

Japanese readings and pronunciation[edit]

Hello everybody. Reading the archived beer parlours I noticed that there was a previous discussion about readings for Japanese words. Some people argued that it should be enough with adding the hiragana reading as an extra synonym. This is of course not enough. There were some examples then, but they were a little hard to follow, so I would like to add a concrete problem. As you might know, Japanese have a number of different pronouns (technically they are supposed to be nouns) used depending on the social relationship between speakers. I added a few to the DM for I:

  • 私 (わたくし watakusi) formal, literary
  • 私 (わたし watasi) formal
  • 僕 (ぼく boku) maskuline
  • 俺 (おれ ore) maskulin informal
  • あたし(atasi) feminine
  • 儂 (わし wasi) maskulin, geriatric

As you can see, separating the reading from the kanji will make it impossible to know what goes with what, having a number of kanji words and a number of hiragana words, and their relationship is not even one-to-one. Apparently there will be a pronounciation field in the future which might be possible to adapt, but in the case of Japanese, it is of outmost importance that you can search on the hiragana as well as the kanji.

Searching with pinyin in Chinese could be seen as a similar problem, but I'd say that pinyin is equivalent with serching for Japanese in romaji. And then you have the problems of different transliteration schemes: pinyin, wade-giles; hepburn, kunrei-shiki &c. Any information on what is the current status in this matter would be very appreciated. This needs to be worked out before adding a lot of Japanese to the dictionary. Gon-no-suke 10:51, 11 February 2007 (EST)

Just for the records:
  1. Various transliteration schemes exist also from non-latin scripts to latin script, which depend on the target language, and in part on time in hitory. Several target languages have more than one transliteration scheme from a given source script/language. At least for proper names, imho including them in Omegawiki is unavoidable. Better would be, to include them for all words (Maybe they can be machine generated) Someone looking a translation up for inclusion in a publication, might want to publish the/a transliteration as well.
  2. Similar but less complicated: For many, if not all, local languages of the Rhineland in Europe, there are two or more, in part quite distinct, orthographies. Varying in extent, some 130 or 150 of them have published wordbooks. --Purodha Blissenbach 21:13, 11 February 2007 (EST)
Purodha, bitte. Du musst nicht immer mit Koelsch anfangen wenn wir ueber Japanisch reden. Das hier hat mit Rheinischen Dialekten genau gar nichts zu tun. Wir sind hier doch kein Karnevalsverein. Danke. --Mkill 00:43, 13 February 2007 (EST)
OmegaWiki uses expressions. Where you write "私 (わたくし watakusi)" there are in effect three related expressions. They are related in their meaning. This is how I think this can be satisfactorily be done. GerardM 03:09, 12 February 2007 (EST)
I agree about the three expressions. However, binding then together through a defined meaning is not enough, since they will be mixed with other synonyms. Gon-no-suke 17:07, 12 February 2007 (EST)
No. There is only one expression, which can be written either 私 or わたくし in Japanese, and it is transcribed in the Hepburn-system as "watakushi" and in the Kunrei-System as "watakusi". The problem is rather, that a second expression, わたし, is also written as 私. --Mkill 00:47, 13 February 2007 (EST)
Expression has a precise meaning within OmegaWiki. One expression CANNOT be written in different ways. GerardM 22:13, 13 February 2007 (EST)
I am VERY much not a fan of transliterations. They are extremely ambigue. Where they exist, they exist as the word as used in another language. GerardM 03:10, 12 February 2007 (EST)

Please let me elaborate on the example above. Ignoring the transliterations, there are ten different expressions in the list.

  • わたくし
  • わたし
  • おれ
  • あたし
  • ぼく
  • わし

However, with the current schema there is no way to save the relevant groupings (e.g. 私・わたくし and 私・わたし) in the database. I hate to be the one to ask for fundamental changes at this stage, but maybe there has to be another layer of abstraction between expression and defined meaning, grouping together expression variations. The same problem is found in Korean hangul/hanja. I am not very found of transliterations either, as they are very language-specific. But in the case of Chinese I do see a need to include the pinyin as well. Auto-generation is possible but I fear it will miss some specific variants. Gon-no-suke 18:51, 12 February 2007 (EST)

Do you imply that these 10 expressions all mean the same thing ? GerardM 02:48, 13 February 2007 (EST)
Yes, they all mean I. Perhaps some could be split into different defined meanings, but I am not sure since there is a difference in usage rather than in meaning. Of course a lot of problematic expressions could possibly (with a lot of work) be split into different defined meanings, but some are still left as synonyms. Gon-no-suke 18:39, 13 February 2007 (EST)
@GerardM: You do not understand. What Gon-no-suke is talking about here, and what I requested earlier, is not about transliteration to another language like English or German.
We talk about annotating Japanese script so it can be used by Japanese learners and native speakers. As has been stated, the Japanese script is ambigous as to how to read an expression. It is not enough for OmegaWiki to list a Japanese word with the Kanji alone. 私 can be read わたし and わたくし and the database needs to note which one is meant in a particular entry. Note that the transliteration uses a Japanese script, too (Hiragana).
See it as an annotation, similar to German words annotating the gender of a noun for every term. It is additional information that can not be gained from the written term alone. So what we need is an additional annotation field for Japanese that is called "Reading". In some future version, the dictionary should be able to display the reading as ruby characters (Wikipedia:Ruby character) That would be the perfect solution.
Without the ability to annotate Japanese script with readings, OmegaWiki lacks basic functionality to include Japanese. For reference, you can check wadoku.de, a Japanese-German online dictionary. They have an extra column to display the reading of Japanese terms.
You see, when you want to make a dictionary of every language, you have to deal with the special intricacies of every language. --Mkill 00:41, 13 February 2007 (EST)
I agree with Mkill in principle. My problem with annotations is that for Japanese they have to be searchable and thus expressions. You could of course add these redundantly as well, but apart from the extra work I also worry about Japanese expressions with multiple readings. The expression 経緯 can be read as けいい (longitude and latitude) or いきさつ (prehistory) or たてぬき (weawing term). It is necessary to have a different attribute on 経緯 for each defined meaning. I don't know much about the database design for attributes, but I had imagined that they come attached to a specific expression regardless of the defined meaning. That is why I see this as four expressions grouped into three pairs of kanji-kana according to the defined meaning.
I would also like to point out that in Korean we have the inverse problem. The normal form is in hangul but in the case of sino-korean words there is corresponding hanja (characters of chinese origin) that differ according to the defined meaning. I had a quick look at the Korean wiktionary, and I didn't see any hanja there, but since they are used (to a limited extent) in modern Korean I think they have to be accounted for here. If we use annotations for this, we will have to add another (searchable) field especially for Korean that is incompatible with the "Reading" one proposed by Mkill.
This really is a complicated issue, but at present I think both of these problems could be incorporated if there is a way to create sets of expressions where the corresponding kanji, kana (hangul, hanja) are grouped together for a specific defined meaning. This could even be used for traditional vs simplified chinese and maybe even for pinyin. (Please don't forget that pinyin is a transliteration created for Chinese directly and not a way to write Chinese in another language. The same thing applies to some extent to japanese Kunrei-siki.) People with more knowledge of Vietnamese than I probably have additional comments in this matter. Gon-no-suke 01:42, 13 February 2007 (EST)
When you look for 経緯 you expect to find multiple DefinedMeanings. You expect to find for instance けいい with one and いきさつ with the other. That is something you can already do. In essence, I do not understand what more is needed .. and yes you can add the Romanji too.
You are absolutely right, bad example on my part. However, as I also wrote below, いきさつ and けいい also share one DefinedMeaning. Gon-no-suke 18:43, 13 February 2007 (EST)
Looking back, with the 経緯 part I wanted to say that annotations are not enough since thay are (in my understanding) attached to Expressions, not to pairs of DefinedMeanings and Expressions, which is what is needed. Please inform me if I am wrong. Gon-no-suke 21:49, 13 February 2007 (EST)
Since noone seemed willing to inform me, I downloaded the database and checked myself. I was wrong. Annotations are (presently) added to a syntrans which is a pair of a DefinedMeaning and a Expression. I will continue this discussion below. Gon-no-suke 03:13, 14 February 2007 (EST)
When you look for 経緯 you get them all, when you look for けいい you get only one... GerardM 02:45, 13 February 2007 (EST)
As I showed above for the defined meaning for I, you will get multiple kanji expressions and multiple kana expressions for the same defined meaning, thus it is impossible to know which kanji goes with which kana. Some will be resolved through the defined meanings, but as there are things like synonyms, not all of them will. Please have a look at this example and tell me whether the reading of 鴨 is カモ or アヒル(no cheating please ;-) Gon-no-suke 03:05, 13 February 2007 (EST)
For 経緯, there will be one defined meaning (prehistory) containing the three expressions 経緯, けいい and いきさつ, but no way to know whether 経緯 is read as けいい or いきさつ or both. Gon-no-suke 03:11, 13 February 2007 (EST)
One more for the road: I should probably add two expressions to one of the DMs for agreement. 賛成・さんせい and 同意・どうい. Comment from native speakers are welcome, but as far as I can tell the only difference between them is what collocations they go with. If I add all four expressions you can't tell the individual readings. The same thing might hold for the corresponding Chinese and their respective pinyin: 赞成 ・zancheng and 同意・tongyi (I skipped the tones). Any comments on this issue from Chinese speakers would also be very nice. Gon-no-suke 03:41, 13 February 2007 (EST)
GerardM, I'm sorry, but either you start researching about the Japanese writing system, starting maybe at Wikipedia: Japanese writing system, or just believe us that this is an issue that needs to be dealt with. We need to find a developer with some understanding of the Japanese language that adds the necessary functionality.
Really, there is two people now trying to explain this to you, but you just downright refuse to accept that OmegaWiki has a problem here and needs additional functionality. I'm tired of repeating the same arguments again. No, adding Hiragana readings as synonymous expressions does not work. Okay? It's just as Gon-no-suke wrote: If you have 賛成, 同意, どうい and さんせい under one DM you just can't tell which Hiragana is tied to which Kanji.
So please try to get a grasp what we are talking about here, because I start to get the feeling I'm wasting my time better spent in other projects. --Mkill 21:42, 13 February 2007 (EST)


Is that not exactly talking about spelling variants, respective alternative orthographies, respecive alternative scripts, where there is an identity between expressions? Since identical is not synonymous, there needs to be another way to relate these expressions, than syn/trans alone. --Purodha Blissenbach 16:02, 13 February 2007 (EST)
Purodha, you try to grasp the issue from the viewpoint of writing systems where the letter is tied to some kind of pronounciation (at least historically). In Japanese that is not the case, creating a wide area of ambiguity. So, unless you have studied Japanese, Chinese, historic Vietnamese or Korean, Egyptian Hieroglyphs and similar it will be very hard to explain this to you. --Mkill 21:42, 13 February 2007 (EST)

As Purodha said above, these are in a way identical expressions. If you need any more concrete examples to get my point, have a look at the entry for DefinedMeaning:bathroom_(5916) and see if you can deduce the reading of Expression:厠 from my added hiragana entries. Gon-no-suke 21:49, 13 February 2007 (EST)

I checked DefinedMeaning:bathroom (5916) and it's a mess. The current database simply does not support readings, period. That is why we should just add Japanese words in the form they are usually written in Japanese. We should NOT add Hiragana readings unless the word is written in Hiragana in normal contexts (webpages, newspapers, novels, signs etc.). If we add Hiragana words that are usually written in Kanji, it clogs up the database and the words have to be removed later. --Mkill 21:02, 18 February 2007 (EST)
I was trying to make a point there. I fully agree that the readings should be added in some other way. However, this example shows wat happens if we add it as hiragana directly, as GerardM suggested. My impression was that OmegaWiki is still in alpha (?), and trying out different solutions is supposed to be the preferred way to do things at this stage. Gon-no-suke 23:48, 18 February 2007 (EST)

I just joined OmegaWiki, and I'd like to add my voice to this discussion. I can confirm what Gon-no-suke and Mkill are saying. For Japanese (and simplified and traditional Chinese), the "reading" is an essential piece of information about "a combination of [kanji] characters that make up a word" (i.e. an Expression). In general, it is not possible to derive the reading from an arbitrary kanji Expression. I know that many databases which store kanji strings and need the reading have a second column for the reading. Examples include corporate name and address databases, and kanji input dictionaries for computer input methods. (My background is in software for representing and typesetting Japanese text.) JimDeLaHunt 04:27, 9 June 2007 (EDT)

Part of the underlying issue is that ideographic languages like Japanese have a much more complex mapping from the written language to the spoken language than do alphabetic languages like English. It may help to think of spoken Japanese as being a different language than written Japanese. In Japan there are "漢和辞典", or "Kanji-to-Japanese dictionaries", a measure of the gulf separating the spoken and written forms. The readings are a written form of spoken Japanese. An illustration: consider the English Expression "bow". It can be pronounced as rhyming with "cow" or with "tow", and it has different meanings. Similarly, the Expression "read" can be pronounced like "reed" or "red", and there the meanings are distinct but closely related: present and past forms of the same verb. How does OmegaWiki represent these distinctions? I'm not saying the same mechanism works for kanji readings. It's just an exercise in seeing where English has a gap between spoken and written forms, and different definitions for the same Expression. JimDeLaHunt 04:27, 9 June 2007 (EDT)

GerardM, I appreciate your passion for the OmegaWiki vision. I think that to achieve this vision, it's essential to support readings for ideographic languages. In this thread, I see your statements about "related expressions" and "transliterations" that make me nervous that you don't fully understand the requirement. Could you please bring us up to date about your thinking? JimDeLaHunt 04:27, 9 June 2007 (EDT)

Preliminary Conclusion[edit]

Dowloading the MySQL database and looking at the tables, I was able to understand the current schema. It seems like attributes are connected to syntranses, sets of one DefinedMeaning and one Expression. This means that one of my worries with attributes was unfounded for, and that Mkills suggestion is applicable. My other concern with attributes was that they are not searchable in the same namespace as expressions, which would be a problem for Japanese speakers. I therefore would like to make the following suggestion:

  • Add a new attribute type where the value is another Expression (possibly constrained to the same language). There are already attributes of type translated_content, so this is a similar solution.
  • Allow for adding of orphan expressions into this attribute. I want to add Expression:さんせい as an attribute to Expression:賛成 in combination with the proper DefinedMeaning.
  • Searching for さんせい will find Expression:さんせい. In this case there will be no 'Exact meaning' nor a 'Approximate meaning' (but there could be for other expressions), but a new relation like 'Alternative expression' pointing at Expression:賛成.

This approach could also be used to link together traditional and simplified Chinese if the same language-constraint is relaxed. Personally I see these as alternative orthographies, since both are used (for historical text &c) in mainland China in one specific language. Pinyin and Hanja can of course also be accommondated. I'll leave Koelsch for Purodha to consider. Comments are welcome, and if there are no problems I will add this to Functionality_wanted_.. later. Gon-no-suke 04:17, 14 February 2007 (EST)

Yes, do so. If I recall it right, I made a functionally identical or very similar suggestion, only with different naming. I also suggested - for the further away future - to have a possibility to constraint (label) such relations to certain periods in history, such as to address the unavailability of modern terms, like "computer" in historic texts, and mark spellings which have been changed, went out of use, or were newly introduced. Maybe regional use contraints, such as swiss German vs. standard Germa spelling etc. can be similarly dealt with. --Purodha Blissenbach 19:37, 14 February 2007 (EST)
Well, I don't know for Japanese, but I know much about Databases and something about Chinese. The transliteration is about how to speak, while the expression defines the meaning.
Therefore it makes absolutely no sense to handle tranliterations as a kind of translation. It might be better to write a tool that allows adding tranliteration using ie. either kanji or pinyin and translates this automatically to the other transliteration-systems and—most important—into IPA.
I think further that there should be a toolbar that allows adding special characters for the transliterations by clicking on the symbol using client-side JavaScript rather then the user needs to do copy&paste or changing keyboard layout.
see also: Pinyin ↔ IPA ↔ Zhuyin
MovGP0 11:34, 28 February 2007 (EST)
I don't propose to handle transliterations as translations. A translation is an Expression that appears in the SynTrans table for a DefinedMeaning. If it does not appear in the SynTrans table, it will not be shown on the list. I dont think that pinyin or hiragana readings are translations, but they could be seen as dictionary-specific expressions, so I don't see any problem with keeping them in the Expression table. They will not be head-words (translations or synonyms) in OmegaWiki, unless they fulfill that role somewhere else (as some hiragana expressions do). However, the only proposal I have had from User:GerardM GerardM so far is to add htem (excluding pinyin) as translations - which is exactly what you and I oppose.
In Functionality_wanted_..#Minimal_implementation you (MovGPO) proposed to add pinyin to expressions directly. How do you propose to handle cases where the pinyin changes depending on the meaning? For example Expression:重 in the meaning of "heavy" is zhong4 but in the meaning of "overlapping" it is chong2. As far as I can tell, we need to add the hiragana and pinyin to the translation, that is the SynTrans - an Expression used with a specific DefinedMeaning, and this is my proposal.
For reference, these are the current SynTrans and Expression tables:
mysql> explain uw_syntrans;
+-----------------------+------------+------+-----+---------+-------+
| Field                 | Type       | Null | Key | Default | Extra |
+-----------------------+------------+------+-----+---------+-------+
| syntrans_sid          | int(10)    |      | MUL | 0       |       |
| defined_meaning_id    | int(10)    |      | MUL | 0       |       |
| expression_id         | int(10)    |      | MUL | 0       |       |
| firstuse              | char(14)   |      |     |         |       |
| identical_meaning     | tinyint(1) |      |     | 0       |       |
| add_transaction_id    | int(11)    |      | MUL | 0       |       |
| remove_transaction_id | int(11)    | YES  | MUL | NULL    |       |
+-----------------------+------------+------+-----+---------+-------+

mysql> explain uw_expression_ns;
+-----------------------+------------------+------+-----+---------+-------+
| Field                 | Type             | Null | Key | Default | Extra |
+-----------------------+------------------+------+-----+---------+-------+
| expression_id         | int(10) unsigned |      | MUL | 0       |       |
| spelling              | varchar(255)     |      | MUL |         |       |
| hyphenation           | varchar(255)     |      |     |         |       |
| language_id           | int(10)          |      | MUL | 0       |       |
| add_transaction_id    | int(11)          |      | MUL | 0       |       |
| remove_transaction_id | int(11)          | YES  | MUL | NULL    |       |
+-----------------------+------------------+------+-----+---------+-------+
To support this, we need some development done. When we have a developer and a design on what to do, we will do so. It is not as if we do not want it. It is just that we currently do not have the capacity. GerardM 04:47, 9 June 2007 (EDT)
Gerard, that's great to hear. I'm newly arrived, and I'm a software engineer (though not really in this kind of programming). When I get up to speed, it's possible that I might be of some use. I'll contact you when I think I'm ready to contribute. Thanks for your prompt response, and for your dedication. JimDeLaHunt 13:25, 9 June 2007 (EDT)

Right to Left Pages[edit]

Hi. It there already a function to view pages RTL, for RTL languages such as Hebrew and Arabic? Or is that nor ready yet? Note that my question has to do with the direction of the page itself (and the edit box), not the direction of the displayed text. Dovi 06:44, 12 February 2007 (EST)

Right to left pages is being worked on as part of the Multilingual MediaWiki project. I need to get an update on its status .. :) GerardM 06:59, 12 February 2007 (EST)

New firewall[edit]

Hoi, The statistics we had were really .. off. The problem had to do with the network configuration. This has now been remedied so from today we will get statistics again that make some sense. GerardM 16:29, 15 February 2007 (EST)

And where will we able to see them, if not at http://www.omegawiki.org/stats/?
That is where we will see it .. it is for Erik to make it "visible" again. GerardM 06:33, 16 February 2007 (EST)

Greek expressions with brackets[edit]

While skimming through random pages I noticed that a lot of Greek expressions contain brackets, like Expression:περιοχή περιαστικού (υπερτοπικού) πάρκου. Most of these seem to come from the GEMET database. I don't understand Greek, but my guess is that the brackets denote alternate spellings, expressions or grammatical forms. For a clean database, it would be great to have these terms split into two expressions and the brackets removed. Are there contributors with some understanding of Greek here who can explain why there seem to be so many alternative terms and suggest how to deal with them? --Mkill 03:19, 16 February 2007 (EST)

Wordwise Translation: "region suburban (supralocal) park"; if you see such a think it might be good to remove it and use a online translator like BabelFish to provide two translations instead:
not a very good translation quality indeed, so the only problem that keeps is choosing the right one. MovGP0 08:09, 28 February 2007 (EST)
That is exactly the reason why we need somebody with some ability in the Greek language to fix it. Sure, I can translate it with Babelfish, but I can't tell whether babelfish gives the right answer or garbage. If we add garbage, a native speaker would have to fix it later anyway, so for now it is probably better to mark these and leave them. --Mkill 22:36, 1 March 2007 (EST)

List of themes[edit]

I thought about adding DMs to themes but first I wanted to check whether somebody compiled a list of themes, or whether there is a function in the software that displays a list of expressions used as themes. --Mkill 04:05, 16 February 2007 (EST)

See Help:Topic (no Help:Topics/de yet) or maybe you mean the GEMET themes list (or in German). HenkvD 14:02, 16 February 2007 (EST)
Ahh, thanks, that was what I was looking for. --Mkill 13:00, 18 February 2007 (EST)

Latin?[edit]

I just wanted to add the Latin "lorica hamata" to Expression:chainmail, but Latin was not on the list... please add it! After all, many European languages trace more than half of their vocabulary to that language. And we do have Greek (ancient)... --Mkill 02:30, 21 February 2007 (EST)

We have a problem with Latin because people consider "Equus caballus" Latin. The Latin used in taxonomy does not conform really to it being Latin. We have been considering a "fix" for this but at this stage we do not have it implemented. Thanks, GerardM 03:06, 21 February 2007 (EST)
Well, you would have to include different "Latins" anyway, Classic/Roman Latin, Church Latin and Medieval Latin at minimum. If you would add a language Latin (Roman) or Latin (classic) right now, I think it would be obvious that biological taxonomy does not belong there. By the way what about my suggestion to simply include another language called "scientific terminology" as a catch-all for numbers, physics terminology (E = Energy), chemical formulae (CO2), biological taxonomy, astronomical classification (NGC 1003) etc. ? --Mkill 03:16, 21 February 2007 (EST)
Then we need a ontology too. The current status of this project don't allows this. If you want such a functionality, then you need to merge the Omegawiki and the Semantic Mediawiki Projects. I think this might be a good idea anyway, because Omegawiki could translate semantic relations while semediawiki can provide classifications. But who should do that?
First, its needed to link Expressions to wikipedia/semediawiki pages. Therefore the Expression:CO2 is a translation (in "scientific" language) of Expression:carbon dioxide and annotated as Akronym too (even "Akronym" is not a official PoS yet).
Then the translations get linked to the wikipedia articles. Therefore "sci:CO2" has no linked Wikipedia article, but "sci:CO2" is handled as translation for "en:carbon dioxide" and this is linked to "wp:en:Carbon_dioxide".
The classification
wp:en:carbon dioxide, Attribute:chemical formulare, "CO_2"
is then done within the (semantic) wikipedia. MovGP0 08:40, 28 February 2007 (EST)
I think you go too far, we don't need to include a semantic wiki for this. In Omegawiki, or concern is how to express an idea (described in the DM) in a certain expression. Humans usually use language to express ideas. Individual languages differ in the expressions they use, so we collect how to express a certain idea in different languages.
Note that I define a "language" here as a set of expressions to express an idea, nothing more. The individual signs of sign language, traffic symbols, sports icons, emoticons, even a set of picture with objects on it is a "language" under that definition.
If you take this definition of language, then, in science, we also have a "language". Individual sciences use individual sets of symbols, abbreviations, pseudo-latin terms etc., but if you take these as a whole, they form an international "scientific language". Since each science is concerned with something else (living beings, elements, numbers, stars, physical quantities etc.), it would be obvious which individual science a term would come from. Database relations like "is part of theme: physical quantity" give the necessary ontology that you want. --Mkill 21:51, 28 February 2007 (EST)
The one thing we really want from the Semantic MediaWiki is the logic they use to query their relations. In principle we can model all the relations that they use. The big difference between OmegaWiki and Semantic Wiki is that one relates records the other articles. :) What OmegaWiki does is show the translation in the language of the UI of the DefinedMeaning. GerardM 04:50, 1 March 2007 (EST)
We now have Latin. --Kipcool 09:45, 25 January 2010 (UTC)

New languages[edit]

Please for adding 24 new languages:

  1. Old Tupi language
  2. Yiddish language
  3. Uyghur language
  4. Latin
  5. Scots Gaelic
  6. Old English language
  7. Quechua
  8. Knaanic
  9. Slovio
  10. Aymara language
  11. Akkadian language
  12. Pitjantjatjara language
  13. Old Church Slavonic
  14. Chickasaw language
  15. Cherokee language
  16. Chechen language
  17. Old Norse language
  18. Kaqchikel language
  19. Kurdish language
  20. Tetum language
  21. Tok pisin
  22. Turkmen language
  23. Volapük language
  24. Fula language

and a lot of other languages, which are on wiktionaries.

Pietras1988 11:54, 21 February 2007 (EST)

When someone is interested in a particular language, then it pays to indicate what language it is that should be added. When you look at the list, there are languages in there that are no longer considered languages but macro-languages. When someone wants to add them as editable languages, it makes sense to link to the DM for the language and have the ISO-639-1 and -3 codes added.
For historic languages, it makes sense to have attributes to go with these languages.. for instance when was a particular word last used. It also makes sense to know how it influenced modern offshoots. This list could easily be much longer. It does help when it is clear that some serious effort can be expected for a new language.. the least would be the translation of language names.. GerardM 14:38, 21 February 2007 (EST)
I vote for latin. Many german words have their origin in latin, so this might be a good idea. btw: it should be possible to mark the origin language of a word. Also I'm missing "German (Germany)", because ie. Expression:Tomate or Expression:Sahne does not exist in Austria (even many Austrians use this words). MovGP0 07:53, 28 February 2007 (EST)

Prefixes[edit]

I would like to add a Defined Meaning for Expression:kambo which is the Swahili equivalent to the prefix step- in stepchild, stepmother, &c. Is it correct to add the prefixes Expressioin:step- and Expression:styv- as English and Swedish translations even though they aren't words by themselves? Gon-no-suke 18:09, 21 February 2007 (EST)

Prefixes and suffixes are at this moment something I would like to stay clear off. The reason is that they typically exist in combination with certain words and not with others. As they are very much an attribute of a word, I would like to record them as such. Another issue is that they do not exist on their own. At this moment we only have independent words, we do not do inflections or conjugations yet. It is imho not the moment to start with pre- and suffixes.
I have added the Swahili adjective Expression:-zuri. You need the class prefix (modifying a class 7 ki-noun gives kizuri &c) to create an independent word. However, for a dictionary you need the root form. Any comments on this? Gon-no-suke 02:44, 28 February 2007 (EST)
Omegawiki does not collect "words". It collects expressions. What is expressed by a single word in one language might be a saying, a collocation, a prefix or a suffix in another language. So, the question is not, "do we include this", the question is "does it help a translator if we include this". I say the answer is yes.
Well actually, we collect DefinedMeanings and we associate these with translations and synonyms. An Expression does include all the homonyms that it may have in a language.
Gon-no-suke: I think having Expression:-zuri is bad. This is not an expression, nor a word in the general sense. It’s a root of some part of speech. The words in the general sense are the compositions of that root with obligatory noun class prefixes. --Moyogo 21:33, 12 June 2007 (EDT)
I see what you mean, and I guess that for easy lookup, machine translation and such, limiting Omegawiki to complete words might be important. Am I correct then that you propose to add all possible combinations of class prefixes for every adjective - an increase of one magnitude of entries? And since adding the class prefix limits the meaning, maybe they should have different defined meanings as well? I am not sure if this is the optimal way to deal with agglutinative languages. I recently also wondered what to do with Swahili verbs. As for the verbs entered this far, they are written in the root form (keeping the ku- prefix for monosyllabic verbs) without the root-indicating dash in front: Expression:lala). I am not completely sure about this, but as far as I know the root form is not directly used in the language and should by your (Moyogo) reasoning not be an Expression. Any comments? It is nice though to here from other users with interest in Bantu languages!
As for Omegawiki in general, My gut feeling is that we are creating a dictionary and thus will leave the realm of natural language to some extent. Considerations have to be made for bi-directional lookup, differing demands at different user levels (transliterations), &c, which makes for quite a complex system. For me to actually use dictionary as a language tool you need some basic knowledge of the grammar of your languages in question, and I think it might be a bit too ambitious to bind the grammar into the system. This is just my ramblings though, a discussion (perhaps in a longer thread) would be very valuable for me at least. Gon-no-suke 03:42, 19 June 2007 (EDT)
Better bidirectional support will happen when Multilingual MediaWiki makes its appearance. This software allows for the proper representation of data in a right to left way for languages that require it. This is also when it will become possible to restrict the view to a limited number of languages.. The average user is not interested in more than 5 languages ... maybe even less. GerardM 01:00, 25 June 2007 (EDT)
I was a bit unclear above, by bi-directional lookup I wasn't referring to left-to-right writing, but rather to the fact that any language in a DM can be the target for search by a user. Most normal dictionaries are unidirectional, i.e. the Swedish-Swahili part is separate from the Swahili-Swedish part. Here in OmegaWiki we have to deal with lookup from any language done by users of any level, beginner to native. Gon-no-suke 09:10, 25 June 2007 (EDT)
I certainly agree with Gon-no-suke that with a language like Swahili we need to mention word roots rather than words (in the case of adjectives and verbs). If we restrict ourselves to words, we go against common practice in all Swahili dictionaries. Additionally, you can form hundreds of words from one verb root, and about twelve words from one adjective root. I don't think that we need to mention all of them separately (no normal dictionary does that - of course we could at some point creat redirects from inflected forms to the root). Marcos 12:27, 12 July 2007 (EDT)

Swahili and other "exotic" languages[edit]

But something else: Do you think it is a good idea to start adding Swahili when we have no user with a deeper understanding of that language? I don't think it's a good idea to add words when you have no means of verifying your source. If you're not a native speaker, professional translator or at least an advanced student in a specific language, you have to be very careful when adding words in it. --Mkill 19:52, 21 February 2007 (EST)
I understand your concern, but for these types of projects you can do nothing but hope that people have the good sense not no enter garbage, and if they do trust that someone else will correct it later. My biggest concern is that people will write unclear Defined meanings, which are much harder to correct afterwards, since you have to move a lot of words around and change the exact meaning flag. Professional lexicographers would be preferred, but we have to work with what we got. Good luck with your Korean as well! ;-) Gon-no-suke 23:54, 21 February 2007 (EST)
At this early, pre-alpha stage of the system, is it not important to add a multitude of language entries now to make sure that OmegaWiki covers all possible variation among the world languages? I see a lot of adding of straightforward noun translations between mainly European languages, which is fun and rewarding in its way, but I think it is important that some people focus on translating more vague categories as well. Gon-no-suke 01:55, 22 February 2007 (EST)
They are mainly European, but this is not by design. We are working on for instance right to left support. I am particularly partial to adding Expression:Persian to the lists. GerardM 04:19, 22 February 2007 (EST)
@Gon-no-suke: Looks like we have a completely opposite opinion on this. I would rather like to have a reliable database in the languages I need and use. So I mainly care about German/English/Japanese. This is where I need a reliable, comprehensive and easy-to-use source, because these are the three languages I work with on a daily basis. I don't care what a fried egg is called in Swahili, I don't even know where exactly that language is spoken.
Now, the two, three or four languages that a specific user needs will of course be individually different. But to keep the system going, it is completely sufficient to concentrate on the languages where we actually have native speakers. Once the OmegaWiki database is comprehensive enough that it can actually be used as a tool for a few important language combinations, we can broaden the focus. But before that, I'm so selfish to say that more users working on German/English/Japanese with me would be fine enough. We'll get Swahili the moment we have a user selfish enough to only care about Swahili.
Before OmegaWiki is useful as a tool, we need:
  • a cleaner database (get rid of double expressions, missing DMs, expressions with brackets, wrong capitalizations)
  • more reliable DMs (a prison as a "place where people have limited personal freedom"?)
  • more DM translations (I hate it when I find a DM that's only in one language, and especially when that language isn't English. A bad English translation is still better than a DM that's only in Catalan or Polish)
  • a lot more DMs
  • more same-language synonyms
  • A LOT more annotation functionality (grammar, gender, plural forms, inflected forms, level of speech, common collocations, usage notes ...)
  • functionality for non-European languages (RTL, Japanese readings etc.)
  • more users to check and improve what we already have
And, I'm sorry to say, I can't agree with "you can do nothing but hope that people have the good sense not no enter garbage". When I do a translation I'm paid for, or when I use OmegaWiki for something important like a job application in a foreign language, I cannot rely on "hope", I need a reliable tool. I've already removed two false friends from the database and I'm sure these won't be the last. So, I mean it when I say:
Add words only in languages where you know what you're doing, and make sure to use a reliable source where you get them from. --Mkill 06:43, 22 February 2007 (EST)


Mkill, reading your comments, it is my impression that we don't differ as much in opinion as in priorities. In your list of OmegaWiki shortcomings, there are two separate categories:
  • System -- Japanese readings, RTL, annotations
  • Content -- good DMs, remove cruft
I agree strongly on all your points. We both have argued for a way to deal with Japanese readings. I would rather have this fixed before adding a lot of Japanese expressions without readings, but as I said, this is a matter of priorities. Adding a lot of minor languages at this point is not a linguistic exercise in stamp collecting. I look at it as a way to "debug" the system and find out what functionality is lacking, and if there are problems that overlap between languages, as for example hanja and kana readings. I am not a linguist by profession, but rather a database developer, and that is where my fears and priorities come from. Adding functionality to a humongous database is not always easy.
What I ment with trusting people to add valid data is that I assumed that OmegaWiki will work in the same spirit as Wikipedia, where unknown users can add expression without any qualification. As the Babel templates are self-written, there is no way to judge the entries for languages you don't know, and in the end you have have faith or check for yourself. I really wish for Japanese content on the level of 英辞郎, but for that to happend we need a lot more of (most likely unqualified) users. I use Wikipedia a lot, but I wouldn't trust it when writing a scientific paper. If you think that OmegaWiki is ready to be used in a professional setting, that is your judgement. Gon-no-suke 08:52, 22 February 2007 (EST)

prefixes (back to topic)[edit]

In German this prefix is "Stief-" (Stiefkind, Stiefschwester, Stiefbruder, Stiefvater, Stiefmutter). Rather then translating the prefix it might be better to create a "broader term" relation from stepmother to mother and another "broader term" relation to Expression:kambo. If you would translate "kambo" simply with "step-" then you would also translate stepwise, which has a totally different meaning.
Simply provide the "this is a prefix meaning..." in the description. MovGP0 08:52, 28 February 2007 (EST)
The step- in stepwise would be another DefinedMeaning, unrelated to styv-, step- and Steif-, so i don't think that is a problem. Adding a relation is probably a good idea though, but I am not sure "broader term" is correct, since "kambo" only concerns the relation, not the parent. Gon-no-suke 09:06, 28 February 2007 (EST)
jupp - thaught the same way. I suggest to use a relation called "subexpression". Even this comes with possible inflection-problems, it makes it also possible ie. to link an expression to the single words a phrase consits. MovGP0 11:04, 28 February 2007 (EST)
"subexpression" does not work as of yet. Remember that currently, relations exclusively link DMs, not individual syntranses. Let me explain it with an example:
Expression:fried egg contains the subexpressions "to fry" and "egg".
The German translation Expression:Spiegelei contains "Spiegel" (eng: mirror) and "egg".
Expression:目玉焼き (Japanese) contains 目 (eye) 玉 (gem) 焼く (to fry)
So, if you would link "Spiegelei" with "Spiegel" in the current database, you would also link "fried egg" with "mirror" and 目玉焼き with 鏡, terms that are clearly unrelated in English and Japanese.
So, for "subexpressions", or, as I would call it, "collocation parts", we need new functionality that allows us to connect one DM/syntrans pair to another DM/syntrans pair. --Mkill 21:29, 28 February 2007 (EST)

Wiktionary[edit]

I suggest get the words from Wiktionary and include the translations in it, in an usefull way for Machine translation.--Mac 08:44, 4 March 2007 (EST)

As you may imagine, if this was so straight-forward and easy it would have already been done. I guess you are not aware this project actually started as a Wiktionary, with the explicit target to adress a few of Wiktionary's shortcomings, mainly lack of structure and lack of a multilingual interface.
(Dear Gerard, dear Sabine, while we are at it, please include more pages with information about OmegaWiki here or place better visible links to them)
If you browse through OmegaWiki and compare to Wiktionary, you'll notice that many of Wiktionary's entries won't help here. Definitions are too short or missing, translations are too few, and the format might be garbled and hard to read by bot.
To make a long story short, yes, OmegaWiki could greatly benefit from importing more word databases, but no, Wiktionary is not the right source. --Mkill 09:45, 4 March 2007 (EST)
Initially OmegaWiki was thought to be a place where to include all contents of all wiktionaries. Many wiktionary entries are problematic because of the way they are structured or better not structured. Therefore we sometimes take words + translations from a wiktionary page (single words cannot be copyrighted - only complete collections of them). And even being it possible to get all of these entries over here: we did not proceed in importing up to now.
The question concerning Machine Translation and OmegaWiki is quite complex. There is only one good machine translation tool around to my experience: Apertium. It is programmed only for one language pair at a time and gives really astonishing results when it for example comes to Spanish-Catalan. Spanish-Portuguese also is told to be working well. English-Spanish and vice versa still needs quite a lot of work. OmegaWiki will be able, once we have inflections, to provide databases for Apertium. This means that working together makes sense. Machine translation is not as simple as many believe it to be - there are many issues to it when you want to get a quality text out of the translation.
As to adding word databases: yes, it would make sense since it could be a starting point for people to work on.
Ciao :-) --Sabine 10:35, 4 March 2007 (EST)
But I meant word databases that already contain some relational data. Just raw word lists should be copied as normal wiki-pages with the words linked (like the Basic English list). Anything that's directly added to the database should at least include a definition. I've tried to retroactively define a few of our undefined DMs, and it's a pain in the *** to find something that matches at least the translations in the languages you understand. and we still haven't fixed half of the corrupted entries from the GEMET import. --Mkill 11:26, 4 March 2007 (EST)
The import of the GEMET content was done correctly. What we do is insist on conventions that are different from the ones used by EIONET. This makes the information more useful for instance for datamining. GerardM 17:37, 4 March 2007 (EST)
Certain problems could have been avoided by detecting and splitting multiple expressions at the time of import. --Mkill 01:52, 5 March 2007 (EST)

Expression:alsjeblieft[edit]

Can one of our Dutch speakers please have a look at Expression:alsjeblieft? There are two DMs with both DM and syntrans in Dutch only. Even with German and English it's hard to guess what's meant.

"Een informele uitdrukking van beleefdheid bij het aanreiken van iets."

-> An informal expression (?) of popularity (?) (??? WTH is an iets?)

Btw., I think the DM needs to be rewritten anyway. "Formal" or "Informal" should not be defined in the DM, we need extra functionality (level of speech) for that. As of now, expressions like, for example, "to destroy with an atomic bomb" and "to nuke" are equal for our purposes. --Mkill 11:14, 4 March 2007 (EST)

done
The informal way is alsjeblieft (cf. French 'tu') - The formal way is alstublieft (French 'vous').
The 'fun' is it's used as well for giving something and added to a question if you ask something.

Patio 02:31, 7 March 2007 (EST)

stylistic level[edit]

To start a discussion on adding stylistic level functionality, I've started a new page, see stylistic level. --Mkill 00:55, 7 March 2007 (EST)

similar Definedmeanings.[edit]

These two... Definedmeaning:(339) and Definedmeaning:(6018) are very similar. Are these in other languages pretty different? Expression:bevanda (in italian). Thank you --Gaetanogambilonghi 07:01, 7 March 2007 (EST)

The best way to link to the DM's is DefinedMeaning:beverage (339) and DefinedMeaning:drink (6018). HenkvD 14:19, 7 March 2007 (EST)
This is a tough one. If you look at the definitions, "Any one of various liquids for drinking, usually excluding water" and "A liquid that can be consumed through the mouth", yes, they are the same. The tricky thing here can be understood if you compare "two drinks" with "two beverages"
"Two beers" equal two drinks
"Beer and wine" equal two beverages
"A drink" is a drinkable liquid in the quantity of one glass, while "a beverage" is the general term for human-drinkable liquids. It basicly means that in DefinedMeaning:drink (6018) the main expression and the definition don't match. --Mkill 17:21, 7 March 2007 (EST)
And so... what can we do in these cases? --Gaetanogambilonghi 05:38, 8 March 2007 (EST)
Right now, you have to merge them by hand. Add all Expressions and relations from one DM to the other, using copy and paste. Then, either add the definitions as alternate definitions, or copy them to the talk page for later reference. Then, edit the DM you want to remove, and remove all entries from it. Then, hit the delete button.
Dear developers, if you read this, for this years Christmas give us a merge function so we can do all this with one or two clicks. Please?
PS: Merge done. --Mkill 07:32, 8 March 2007 (EST)

European countries[edit]

After I saw DefinedMeaning:Ukraine (8331), defined as "A country in Europe." it got me thinking. Is this a good definition? Doesn't this definition apply to some 30+ countries? Shouldn't definitions be clear without ambiguity? There should be something that makes clear that this DM only applies to the Ukraine and not to France or Sweden. A simple solution would be to change the DM to "A country in Eastern Europe, with capital Kiev."

I'm writing this here because I need your help in changing the definition translations, and checking the other country entries for similar problems.

By the way, for "A country in Europe", look at DefinedMeaning:European country (469022). --Mkill 12:01, 8 March 2007 (EST)

Besides, I think, it would be useful to mention the form of governement, like "A small princedom in Europe that borders only on France" in DefinedMeaning:Monaco (8078). --Mg 13:27, 10 March 2007 (EST)
For countries, I am in favor of definitions like Expression:France, with something more accurate than just "in Europe", and a list of countries with common borders. Kipcool 14:10, 10 March 2007 (EST)
Yes, that is a very good idea. --Mg 17:34, 10 March 2007 (EST)
But don't make it too complicated, because the definitions still need to be translated and the more words you need to translate the more work it is. The important thing for our dictionary is, that there is only one country that matches the definition, whether you do that with the capital, neighboring countries or government type is merely a question of taste.
While we are at it: Many countries will have at least two names in foreign languages, an abbreviated name that is commonly used and a full name that is used in diplomatic protocol. Sometimes, there is also an acronym and a nickname. See DefinedMeaning:United Kingdom (8302) for an example. A country entry won't be complete unless it includes the common variants. --Mkill 12:13, 11 March 2007 (EDT)

Downtime and better dumps[edit]

Hoi,
This night the system has been unavailable for some time. This was to fix the problem with our data not being in the UTF-8 when restoring a dump to local machines. This has been fixed now thanks to Leftmost. GerardM 03:16, 12 March 2007 (EDT)

Language menu on Linux Debian[edit]

Hi, i'm trying to insert a new translation for an expression, but when I try to open the language menu, it doesn't function... the windows opens, but when I start to write (Italia...) to find Italiano, I don't get anything. It doesn't function.

I'm on Linux Debian, Mozilla Firefox...

any hint?

I have the same configuration, but it works with me. Can you check that the javascript is fully activated? Kipcool 06:16, 12 March 2007 (EDT)
I'm at the university... How should I check that javascript ist FULLY activated? I know that javascript is activated, but I don't understand what "fully" want mean... :) Dennis 09:26, 19 March 2007 (EDT)
Well, in firefox, there are several options in the preferences: "activate java", "activate javascript" (both are checked on my computer), and then an advanced button (nothing is checked in there on my computer). What version of firefox do you have? Kipcool 07:27, 1 April 2007 (EDT)

Lost data[edit]

Hi, This morning Omegawiki didn't know about User:Ascánder so I had to register him again (Please see Special:Log). Does anyone could please help me to regain edit permissions on meanings? Thanks. --Ascánder 07:32, 12 March 2007 (EDT)

It has to do with the UTF-8 change. On logs, my user name appears as Ascánder.--Ascánder 07:44, 12 March 2007 (EDT)

Yes, I have experienced the same as Ascánder today. --Möchtegern 11:53, 12 March 2007 (EDT)

I apologize for this, guys. I forgot to take into account that some usernames may have accented characters. I will write a script up that will fix these usernames and remove the new accounts. This should be done soon. --Leftmostcat 12:31, 12 March 2007 (EDT)
The problem should be fixed. If you read this message and have an accented character or non-Latin alphabet name, please test logging into your account and make sure it works. Let me know as soon as possible if not, and feel free to leave messages on my talk page. Thanks for your patience, and again I apologize for the problems I've caused. --Leftmostcat 13:23, 12 March 2007 (EDT)
It seems to be fixed now. Thanks a lot. --Ascánder 16:20, 12 March 2007 (EDT)

Self-related[edit]

I wonder why nobody created DefinedMeaning:OmegaWiki (477539) before... well, here it is. Translations welcome! --Mkill 10:58, 15 March 2007 (EDT)

Interjections[edit]

Are there any rules whether to set notes of exclamation or not behind interjections? See Expression:Guten Tag! and Expression:guten Tag. --Mg 11:16, 16 March 2007 (EDT)

My suggestion would be to add both under the same DM as synonyms.
The cleanest solution would be the interjection as an expression, without punctuation mark and capitalization (guten Tag) in the Expression namespace, and a connected entry as example sentence (Guten Tag!). But I don't know how easy it would be to enforce that kind of policy. Also, I don't think example sentences are searchable yet. --Mkill 11:50, 16 March 2007 (EDT)

Google Summer of Code[edit]

Sadly we have not been selected to host GSOC projects. We have spend serious time to define some nice projects. In the end we did not get it; there were already so many organisations that wanted to participate. It was suggested to collaborate with the WMF.. it was even suggested that we could be introduced. :) GerardM 08:53, 17 March 2007 (EDT)

Sure, the WMF can give money and manpower, bring them in! --Mkill 11:28, 17 March 2007 (EDT)
Somehow I do not think it works that way .. GerardM 05:20, 19 March 2007 (EDT)

Toki Pona[edit]

I think it would be useful to introduce Toki Pona into OmegaWiki. I know that it is a very very small constructed language (ca. 20-30 speakers), but on the mainpage is written that OmegaWiki is a resource in every language. What are your opinions? --Mg 16:09, 20 March 2007 (EDT)

Why not? As we say in Dutch: Mijn zegen heb je Patio 06:45, 22 March 2007 (EDT)
In OmegaWiki we support languages that have an ISO-639 code. If Toki Pona does have such a code, than it is no problem. GerardM 09:56, 22 March 2007 (EDT)
Hm, if I interpret the informations in the English Wikipedia right, Toki Pona hasn't really an ISO-Code. --Mg 13:00, 22 March 2007 (EDT)
Yes, until now Toki Pona doesn't have an ISO-639 code. But since it is spoken more than some of the constructed languages that already have a code, it shouldn't be to difficult to get it a code. There was some discussion on the Toki Pona mailing list about this, and I will bring up the issue again there. Marcos 12:27, 3 April 2007 (EDT)

New functionality ..[edit]

Some new functionality has gone on line. Content in lists will now be sorted based on what is in the first column .. typically stuff like the names of the languages. When you do not see it, do a CNTRL F5 to do a refresh.

Another improvement are some indexes that are now functioning properly providing a better performance..

) GerardM 16:48, 22 March 2007 (EDT)
Great! --Mkill 22:31, 22 March 2007 (EDT)

BugZilla[edit]

Via BugZilla you can report software bugs. How to do that in 13 languages:

  1. Česky
  2. Dansk
  3. Deutsch
  4. English
  5. Français
  6. Italiano
  7. Magyar
  8. Nederlands
  9. Polski
  10. Português
  11. Русский
  12. 简体中文
  13. 繁體中文


Maybe some of you can add their language?

Updated Patio 06:21, 21 June 2007 (EDT)

counting DMs[edit]

Is there any facility to count the DefindMeanings like {{NUMBEROFPAGES}}. --Mg 17:55, 23 March 2007 (EDT)

Not yet. If you want, you can see the number of DMs in my statistic page. Kipcool 07:29, 1 April 2007 (EDT)

More new functionality; stats - words per language[edit]

We now have words per language. This functionality was written by Zdenek Broz, it was integrated by Kim. :) GerardM 07:13, 24 March 2007 (EDT)

That's a cool feature. But this brings me to the idea to have a tool which shows you a branch (one dozend or so) of words which haven't got translated into all the languages you speak. This may speed things up. ie. the user might get represented a Table like the following:
English              Deutsch
----------------------------------------
House                [          ][a][x]
[          ][a][x]   Floh
Light                [          ][a][x]
...
In the given Example "House" wasn't translated into German; "Floh" wasn't translated into English; etc.
With this technique (or something like this) a user can provide Translations more effective. The [a] stands for the Annotation-Link where [x] stands for the "identical meaning"-Checkbox. This also gives rare languages a boost, because German/English are well translated and therefore there is not so much to translate between this two.
MovGP0 15:59, 25 March 2007 (EDT)
When we delete a word (an expression), it is still counted in the stats - words per language. So, the stats are not really exact. Kipcool 08:04, 1 April 2007 (EDT)

Could we please get Spanish back???[edit]

The language is called Spanish, pretty much everywhere except when people have a political agenda to push Spain's regional languages. Now, while I have absolutely nothing against Catalan and Aragonese and Basque, Castilian is still the standard dialect and the language everybody refers to when he uses the expression "Spanish". Also, don't forget the huge *Spanish*-speaking population of Latin America. Now, explain to them they are speaking "Castilian"... good luck. Last time I checked, the official EU language was called "Spanish", too.

On a side note, replacing Chinese with Mandarin and Cantonese with Yue was equally "smart". What's next? Good bye German, hello Hannoveranian? (That's the area where the German standard dialect is spoken)

Now, I know we have lots of people here pushing regional languages, and I don't mind that, but please remember that there are certain standard and prestige dialects and official languages and we should call them by their name here. Especially since these are the languages meant when a dictionary says English-Chinese or German-Spanish. So please, give us back Spanish, or rather, Spanish (Spain), Spanish (Argentina), Spanish (Mexico), Spanish (Chile)...

As for Chinese, we actually need Chinese (simplified, PRC), Chinese (simplified, Singapur), Chinese (traditional, Taiwan), Chinese (traditional, Hong Kong) and Cantonese (Hong Kong) --Mkill 12:48, 27 March 2007 (EDT)

I agree with you that Spanish (or its correspondent) should be the name of the language in every language different from Spanish as it's the most frequently used. For the name of the language in Spanish itself, it's a little more complicated. I'm from Latin America and I call it castellano in Spanish as most of latinamericans do. It's the name used in most of the legal papers (including constitutions) of most of the Spanish talking countries including Spain. The official grammar text of the language is entitled “Gramática de la lengua castellana”. However, Spaniards talking Spanish prefer to call it español while Spaniards talking other languages call it only Castillan. Even Spanish Wikipedia, originally called “Wikipedia en castellano” had to be renamed after a split of the project. Personally, I don't care about the name to be used in Spanish, as is the case for most of non Spaniard Spanish talking people.
--Ascánder 14:34, 27 March 2007 (EDT)
Ok, so it should be "castellano" when Spanish is the language of the user interface, and "Spanish" in English, "Spanisch" in German, スペイン語 in Japanese etc. --Mkill 02:41, 2 April 2007 (EDT)
Traditional versus simplified is about script. Chinese is an amalgamation of languages that when spoken are mutually exclusive. Chinese is not one language as you imply. GerardM 05:25, 30 March 2007 (EDT)
I am fully aware of that. But there is a common written language, based on the modern northern Chinese dialects, that is usually refered to when you use the term "Chinese". Above that, the speakers of the different Chinese languages / dialects are able to communicate using the Chinese writing system. Since OmegaWiki is obviously using written language as a means to put down words, it is possible to collect words of the Chinese written language that is shared between the variants. OmegaWiki is about script. In fact, until we finally get the much-needed functionality to add Pinyin, there will be (almost) no differences between these dialects because the characters will be the same. What we do need to consider are the differences in the official written languages used in different political entities, i.e. Chinese (simplified, PRC), Chinese (simplified, Singapur), Chinese (traditional, Taiwan), Chinese (traditional, Hong Kong). These are the variants of Chinese that the Chinese Wikipedia uses (in case you didn't notice yet that Chinese Wikipedia has every article in 4 variants). --Mkill 02:41, 2 April 2007 (EDT)
Why not having both "Spanish" (or "Spanish (Castillan)" ) and "Castillan" in the drop-down box, both pointing to the same language? I guess most people (me for example) will search for Spanish, and not for Castillan. If that is done (that needs a little bit of coding I guess), I'd like to have also "Chinese (simplified mandarin)" and the likes so that people can find it easily (Where I studied it, it was more often called "chinois" than "mandarin"). Kipcool 17:28, 30 March 2007 (EDT)
Where I studied it, it is called "Chinesisch", and "Mandarin" is a Qing government official. --Mkill 02:41, 2 April 2007 (EDT)

Venetian is not Venetan[edit]

Reference: Venetan on Encyclopædia Britannica:

Venetian is the variant of the Venetan language spoken in Venice. Anyway I see that most expressions related to DefinedMeaning:Venetian (365386) seem to translate "Venetian" instead of "Venetan", maybe because of the wrong hint of the DM title.

Can any bureaucrat change that title into Venetan? Thank you in advance.

--Achillu 03:26, 30 March 2007 (EDT)

The reference for language we adhere to is Ethnologue. It is nice what the Brittanica writes, it is however not our standard. When we get to that stage we will be using the ISO-639-6.
You have exactly the same kind of edit rights that a bureaucrat has. GerardM 05:29, 30 March 2007 (EDT)
Just a short note: I asked a discussion group that deals with Venetian to help us with this. Anyway: the standard uses Venetian and so we are using it here as well. Thanks for your understanding. --Sabine 06:11, 30 March 2007 (EDT)
I am really sorry, anyway I am sure that the correct term is "Venetan" and not "Venetian", and it is not only Encyclopædia Britannica that claims that. I did not know of this mistake by Ethnologue, and it is really a pity that sticking to a standard is leading this project to have this mispell. I hope that this standard will very soon be more flexible in order to have the correct word "Venetan" as the English name for my native language.
Please note that saying "Venetian" instead of "Venetan" is exactly the same that saying "Hannoveranian" instead of "German", and here Mkill says that this is NOT desirable. I hope you understand, too^^
--Achillu 09:07, 30 March 2007 (EDT)
Please read the Ethnologue article .. http://www.ethnologue.com/show_language.asp?code=vec it has Veneto and Venet as alternative names. This means how it is "wrong" is a bit more nuanced. GerardM 09:18, 30 March 2007 (EDT)
I did not and I do not want to mess anything up here and I am very sorry of what I did last night. I am a computer programmer and I know how it is important to stick to standards! While this will be our standard I'll keep on write "Venetian" wherever this is the official name of my native language here on Omegawiki.
Mine was just a hope (I have a dream): if the source of our standard has a typographic mistake (aka typo) should we expand the typo to the whole project? Or should we make our policy flexible enough to allow corrections of those typos? I was just writing about this.
--Achillu 08:45, 2 April 2007 (EDT)
With Neapolitan we have a situation that may be similar. This language may seem to be associated with the city while in actual fact it is not. What is important is the definition.. That is what DEFINES what we are talking about, in the end you can have a Venetian dialect within the Venetian language.. GerardM 12:03, 2 April 2007 (EDT)

Time Out[edit]

Some expressions need quite some some to edit e.g. do
See the talk page

What may cause/solve this?
I use Firefox on Windows XP (SP2)

Patio 01:33, 1 April 2007 (EDT)

I have the same (a dialog box asking to stop the script)
As far as I know, the slowness of editing appeared for words with many translation, when the java script that sorts translations automatically was introduced. Maybe this script is not optimal? Kipcool 05:36, 1 April 2007 (EDT)
This problem existed prior to the introduction of this script.. The problem is that the rendering of a page takes a long time .. just save a page like do or water and marvel at the size of it.. This has little to do with the sorting I am afraid .. GerardM 12:06, 2 April 2007 (EDT)
I think this is a major issure. The speed of omegawiki is currently no fun. Therefore you might want to make testings for the scalability and refactor parts of the code. A good and free book about might be Improving .NET Application Performance and Scalability. Even this is written for .NET Developers (so its meant for peoples using PHP.NET rather than PHP; but I don't know a similar free resource for PHP) it introduces general principes for testing and designing scalable applications.
see also: Functionality wanted ..#Adding more than one translation at once
MovGP0 17:25, 4 April 2007 (EDT)
Other solutions:
  • use shorter variable names than "id="add-defined-meaning-369665-definition-translated-text-language-suggest-previous"" they take at least half of the page size (if not more).
  • use Ajax
Alas, no developer is reading this. Kipcool 08:28, 5 April 2007 (EDT)
We know where we have a problem.. This is in the http code.. it gets just too big when there are many components on the page. There are two solutions on the horizon; the latest is that it will be ready by the end of the month. This will allow people to select the languages that they are interested in.
We also have an idea what is needed to get the http optimized.. it just needs doing .. GerardM 08:50, 5 April 2007 (EDT)
AJAX and XSLT based Infrastructure
AJAX can also work around the size of the HTML-source. Because the site isn't reloaded, but only the new data is sent back to the server using a fire-and-forget technique (stateless sentback). This will allow that ideally exaclty no data is transfered from the server to the client during sentback and page refresh. But a simple Webservice (the most complex it checking the user credencials) is needed to do this.
Also Kipcool is right. The ID's are most of the page, so reducing them will reduce broadband. I've tried to edit Expression:account - the file had 2.16 MB !!!
Because the structure of the file is very regular, I suggest to create that regular stuff on the client using XSLT, which allows the server to deliver small XML-Files instead.
But also GeradM is right, the best idea has no sence if there is no coder that implements it. (particulary I won't - at least because I speak no PHP)
MovGP0 10:43, 7 April 2007 (EDT)

I've been using Firefox 2.0 on the Mac, and I haven't noticed any performance issues until the "client-side table sorting" was introduced. Firefox is known to be slow with large tables, and sorting the tables on entries like commerce is using up 200% CPU (that is, 100% of both CPUs on my system) for about 30 seconds. I'm certain it's the sorting code, because the page loads fine until the sorting kicks in: before the hang, the tables are not sorted but everything else is loaded; after the hang, everything's sorted. – Minh Nguyễn (talk, contribs) 00:33, 17 April 2007 (EDT)

Interesting, I had these troubles also before the sorting came - on Firefox 1.5, 2.0, 3.0b, and IE 7. I can watch how one-by-one entry is downloaded and presented shown the browser. After that is finished (taking about 10-30 Secs) the sorting-script starts and finishes within some Millisecs.
An interesting minor bug is, that when you write an entry when the sorting hasn't started the new entry also got sorted instead of keeping below.
MovGP0 14:21, 22 April 2007 (EDT)

Bavarian exists twice[edit]

I noticed that we have the language "Bavarian" twice. According to the new words per language features, there are a handful of entries in each. This should be fixed. "Lingala" and "Lingala (Latin)" need a merge, too, I think. --Mkill 12:08, 2 April 2007 (EDT)

Expression:Bavarian is the only Bavarian I can find. GerardM 13:18, 3 April 2007 (EDT)
Try typing Bav into the language selection box. --Mkill 09:00, 4 April 2007 (EDT)
I looked at it and at the English preferences there are indeed two languages called Bavarian. I added them both on my DefinedMeaning:HenkvD/test (161300). On English they both look like Bavarian. On German preferences it shows as 1.Bairisch and 2.Bavarian, on Dutch preferences as 1.Beiers and 2.Bavarian. But I can only see one DM: DefinedMeaning:Bavarian (156471).... HenkvD 15:19, 4 April 2007 (EDT)

How to deal with multiple scriptings?[edit]

Some spoken languages (like Norwegian) may have multiple scriptings; Norwegian is a "lucky language" because it has two dedicated ISO codes, one for bokmål scripting and one for nynorsk scripting.

Venet(i)an has two scriptings, too, but unfortunately it has only one ISO code. How to deal with this? I hope there is an official annotation style that can help.

Thank you in advance for answering. --Achillu 09:42, 4 April 2007 (EDT)

Hoi, we are preparing the roll-out for the ISO-CD-639-6 data. When this allows for multiple variations in a language, we will allow for it. When a specific linguistic entity is missing, you can provide us with the necessary information to get it an ISO-CD-639-6 mentioning. This will be the precursor for a full status in OmegaWiki as well. GerardM 09:04, 5 April 2007 (EDT)
Sorry, I do not understand what should I do in practice? Should I choose arbitrarily one script and stick to that, or should I keep on adding Expressions in both scripts and tracking somewhere which Expression is in which script?
Is there any Annotation that could help?
--Achillu 10:34, 5 April 2007 (EDT)
According to the Wikipedia page there is a variety of spellings for Venetan/Venetian, maybe you can explain further what two spellings you refer to?
Since you are the one user so far who is interested in the Venetan language, probably the best would be if you select one spelling system as "OmegaWiki official" and create a guideline on Portal:vec. Should the need for a/the second spelling variant arise, we could talk about that later. If, on the other hand, one day one spelling variant is widely accepted as the right/official one, we should switch to that one. --Mkill 11:55, 5 April 2007 (EDT)
I have checked the ISO-CD-639-6 data; it defines the following as spoken variations of "Venetian Spoken": Bisiacco - Veneto-Giuliano - Feltrino–Bellunese - Trevigiano - Veneziano-U - Veneziano-Della-Laguna - Veneziano-Rural - Vicentino-Padovano - Veronese - Rovigo. For your understanding "Venetian Spoken" is a step lower than Venetian (vec) in the ISO-639-6 hierarchy. Thanks, GerardM 14:35, 5 April 2007 (EDT)
Sorry, I failed to explain.
This issue is about scripting variants and not about spoken variants.
The same word in Venet(i)an can be written in two different ways: there is a "classic" script mostly based on Reinassance orthography, used in the whole Venet(i)an literature up to WWII (this includes the most famous Venet(i)an writers such as Carlo Goldoni); recently a "unified" script has been developed and this script has been widely used especially on the Internet, including Wikipedia in Venet(i)an.
"classic" Venetan : "unified" Venetan = bokmål Norwegian : nynorsk Norwegian
I hope this is clearer now: the same word "/vene'θjan/" may be written "venezian" (classic) or "venezsian" (unified).
If we choose to have only the "classic" Venetan script then we risk to not to have the live Venetan; on the other hand if we choose to have only the "unified" Venetan script then we risk to not to have the literature (and there are still Venetan sites on the Internet using the "classic" script).
I really hope that there is an "Annotation" that can help, because choosing only one script as the OmegaWiki standard is indeed arbitrary, in my point of view.
--Achillu 04:29, 6 April 2007 (EDT)
As I see it, OmegaWiki should concentrate on contemporary languages, at least for now. With the few contributors we have at the moment, there must be some limitations on the scope of the project. We can add classical languages / scripts / orthographies later.
So, "Venet(i)an" should be the modern unified script, with the option of adding Venet(i)an (classic) at a later date. --Mkill 12:28, 9 April 2007 (EDT)
This can only be done if we agree that we are talking about. We do not do this and it is ESSENTIAL that we do. GerardM 12:51, 9 April 2007 (EDT)
Please I was only asking if there is any annotation or other that can deal with multiple scriptings, I am so sorry to having started something else I did not want to start at all!
Asking me to choose one script is arbitrary because I am not a linguist nor a doctor in Venetan literature, I am just a Venetan native speaker. On the other hand I want to explain that asking anyone to conform to unified script is exactly the same thing to ask Norwegians to conform to nynorsk, including those who usually write bokmål.
I still do not understand if there is or there is not any annotation that can help me. This does not mean that any of you is not understanding what I am asking, this only means that I am not understanding what you are answering to my question (so maybe I should demote my "babel" to en-2 or I should read Omegawiki documentation more carefully in order to understand).
Truly sorry, --Achillu 08:55, 11 April 2007 (EDT)
You provide more information. What I did was also provide more information. The information is factual. As we are working on getting the information life, you have now some advance information about the state of play. GerardM 05:19, 6 April 2007 (EDT)
Gerard, please improve your "get-what-people-are-actually-talking-about"-skills. For some reason, you regularly give answers that show you didn't grasp the issue at hand. When somebody is talking about written orthography conventions, you don't help by listing regional variants in the spoken language. I remember similar problems when we tried to explain the difficulties that OmegaWiki has with Japanese, and I think you still didn't get it. How about reading what others say more carefully. --Mkill 12:20, 9 April 2007 (EDT)
I do get what is being said. What I have done is indicate how according to the standards the different options will be for Venetian under the ISO-639-6. OmegaWiki provides particular functionality. It is still limited and I am aware of it. You can however not wish these existing limitations away. GerardM 12:49, 9 April 2007 (EDT)

Internationalization Tag Set (ITS)[edit]

Hi,
just wanted to inform you that the W3C has created a new recommendation for tagging XML- and xHTML-Files for translations. I think that might be interesting, so here is the link: http://www.w3.org/TR/its/

MovGP0 11:17, 4 April 2007 (EDT)

Skins - use Monobook[edit]

The only skin that works for OmegaWiki is "Mononbook". Much of the special functionality is hidden in the skin and this is what makes it work. GerardM 06:28, 8 April 2007 (EDT)

Checkuser[edit]

Does anybody have the checkuser rights? (or is it possible to give them to somebody?) I'm not really happy with the new accounts being created. Thanks Kipcool 05:18, 13 April 2007 (EDT)

At this moment nobody does do CheckUser .. so far we have not needed it. As to the new accounts .. they stink. GerardM 06:09, 13 April 2007 (EDT)
Yes, sooner or later we need a CheckUsers I think...and the new accounts seem to like my User talk... :( --Mg 05:53, 15 April 2007 (EDT)
We are not alone... [1]. Kipcool 05:51, 16 April 2007 (EDT)
And a link on how to install Captcha for the people who have access to the server (pleaaaaaaaaase). Kipcool 06:01, 16 April 2007 (EDT)
We now have captcha in place .. :) GerardM 15:23, 17 April 2007 (EDT)

Statistics[edit]

Since the statistics in [2] are a bit erroneous (the deleted expressions still appear in the count), I created another page of statistics: User:Kipcool/stats. In that page also appears the number of DMs in each language. I sorted the languages according to that number. It is not because I am French, but because it makes more sense to compare this number than the number of expressions, which varies depending on the language. Ideally, it is equal for all languages to the total number of DMs: 15640.

This page is not generated in realtime, it is generated from dumps that I download manually. I plan to update it weekly. Kipcool 04:13, 22 April 2007 (EDT)

Discussing definitions[edit]

I find that discussion pages for expression/Definedmeanings are not very visible, and you can see them or not according to if you edit DM pages, or expression pages. It is also not easy to discuss 2 DMs at the same time.

So, I've created Meta:Questions about words as a solution. Tell me what you think about it (the name, the sections, is it useful or stupid, should it be separated into several pages, ...). Thanks. Kipcool 04:19, 22 April 2007 (EDT)

Good idea and--most important--the users seem to adapt it. MovGP0 16:09, 22 April 2007 (EDT)
For this we need the functionality that is defined in Liquid Threads.. (see Meta). We are getting this back under development.. we have the money and we have the necessary cooperation. GerardM 06:21, 23 April 2007 (EDT)

EuroMatrix Translation Marathon[edit]

The EuroMatrix Project started a Machine Translation Marathon from April 16 to April 20 for finding the best translation-programs for the 23 official office languages of the European Union.

I think this project is currently developing in a wrong line, because they are trying to translate language-pairs. The problem here is that there are over 500 possible languages pairs and for rare language-pairs (ie. letti ⇔ maltese) they won't get good results. In such cases they might need to translate using an intermediate language like ie. english. The problem with that is, that which each translation the result gets more worse, because the error is multipying with each translation.

The solution provided by omegawiki using DefinedMeanings is more better in that sense, because this results in no loss of information during translation. An ideal translation engine will need to analyse the words to gather the possible meanings, gather information about the gramatical PoS, guess the true meaning from the context of neighbour sentences, and asking the user for the correct meaning when its not sure - ideally before and after translation.

Defined Meanings are currently collected from machines that are doing a statistical analysis of large texts and their translations. I think its better to let human do this job (at least for the beginning), because they handled which far more textsamples during their life and also know the true meaning behind words, because of constant interaction with the real world.

Anyway, the Marathon seems to be about existing translation engines and not about ideal ones. Also till now the peoples from this project haven't pronounced interest on Omegawiki. So the result of this Marathon might just be very informative about the existing products.

Stay tuned about this. MovGP0 15:26, 22 April 2007 (EDT)

Great. When you have an article that is translated in say four languages, you already have a concept cloud in five articles that can be compared. As long as there are no homonyms, it seems to be obvious what meaning there is to choose. It is also extremely likely that concepts in the definition match concepts in the article. When this is the case, it is even more safe to consider two expressions to be the translation in another language and allow for the likely matching in a DM in another language. GerardM 06:33, 23 April 2007 (EDT)
Yeah. But Translations can be often tricky - specially when you are taking cultural differences into account. I thought about the filmtitle The hitchhikers guide to the galaxy. In german this would be Der Anhalterführer zur Galaxis but it got translated to Per Anhalter durch die Galaxis - backtranslated to englisch by hitchhiking trough the galaxy, where hitchhiking is used as noun. This was done, because nobody is using the word Anhalterführer, even it would be a correct german word (in german you can built new words by combining existing ones).
Just think about guide. A guide is some kind of written instruction - a map or a manual. In German this gets translated to Führer (a (Tourists-)Map) or Anleitung/Anweisung (Manual). But guide is something more general than this, so if you want to translate guide you need more information. Interesingly when you translate the word Führer back to english than it don't means only a map, but also Leader (and is strongly correlated with Adolf H. - the crazy person from WWII), so you should use Touristenführer (Touristsguide) or Touristenkarte (Touritsmap) instead (except for jokes).
Such problems need a statistical approach for translation, so you need to guess the right solution. Often translation comes along with improvisation, because when something can't get translated (ie. when there is no proper word to describe the same) you need to extract the meaning and say it with your own words.
An example is the way I learn english: if there is a new word I don't know, I mostly don't even try to translate it into german. Instead, I use a statistical approach and try to guess the meaning of the unknown word by understanding the context where the word got used within. This is a very good aproach to translate unknown words, even when there is no translation. The same is with phrases: they only make sense in a specific context and mostly don't have a proper translation. This means, that when you want to translate phrases, you can't use other phrases, but you need to describe what was meant with the phrase, which is mostly done with freetext.
The same with grammar analysing software: when there is just a small comma-error or typing mistake, or false double-negotiations, then in most cases a human won't have any troubles to understand the text, while a computer based on grammar analysis has.
This means, that even when we have a perfect wordbook that provides very proper and complete translations, and perfect grammar analysis, you won't get very good translations. You will ever need an additional statistical approach for proper translations. I think that is why translation is a complex task.
MovGP0 08:03, 24 April 2007 (EDT)
Translation has always been a complex task. Luckily in essence OmegaWiki does not aim to translate and thereby makes it less complicated for within this project. GerardM 02:00, 25 April 2007 (EDT)
We are the opposite of the tax: We can't make it more easy, but more sweet. Patio 03:24, 30 April 2007 (EDT)

Special:Shortpages for Expressions[edit]

I think it would be useful to make Special:Shortpages useful for the Expression namespace, because there are many empty Expressions which must be deleted and with this page we could find them better. Would that be doable? --Mg 12:13, 30 April 2007 (EDT)

Yes it does, but it takes a developer to write this. GerardM 00:38, 8 May 2007 (EDT) PS this is your opportunity :)

ISO-639-6[edit]

The ISO 639-6 data provides the names of linguistic entities. These linguistic entities can be anything from a language family to a spoken dialect. We will want to include all kind of attributes to annotate these. This is the first part of this collection, there will be in the end some 25.000 DefinedMeanings all with relations up and down.

Within the ISO-639-6 names the names are unique. It is therefore that these names should not be changed. People will be encouraged to provide information to additional linguistic entities, we know that 25.000 is a start. These additional linguistic entities will be assessed and may become part of the ISO-639-6 when the information given is compelling. GerardM 00:36, 8 May 2007 (EDT)

Are we authorised to put real definitions in there, or should the definition stay as "ISO 639-6 entity"? Kipcool 08:06, 8 May 2007 (EDT)
The current definitions are there because there has to be something .. Yes, you can add definitions :) GerardM 02:50, 9 May 2007 (EDT)
There are some errors in the language names though. For example, I'm pretty sure this (DefinedMeaning:Lonic (558961)) is Ionic, not Lonic. --Tosca 11:31, 9 May 2007 (EDT)
Its written lowercase in English but uppercase in German, so I've corrected both Entries.
Note: in German and many Programming Languages all Subjects and Objects are written uppercase, while Relations and Properties are written lowercase (this sentences are a Example) - in English it isn't.
MovGP0 17:17, 15 May 2007 (EDT)
There is no such language as "Lonisch" in German. --Tosca 17:38, 15 May 2007 (EDT)
I am sure that you are right .. it should be Ionisch.. GerardM 01:31, 16 May 2007 (EDT)
To MovGP0 : Tosca means Ionic with a iiiiiiiiiii upppercase, not lonic with a LLLLLLLLLLL lowercase. All language names are of course uppercase in English. I'm correctiong lonic to Ionic accordingly. Kipcool 05:13, 16 May 2007 (EDT)

language Select[edit]

Could anyone make Language select available in this wiki? I think it would be very useful. --Mg 10:20, 9 May 2007 (EDT)

If I understood well, Multilingual Mediawiki is coming soon and will be even more powerful (and adapted to Wikidata). Kipcool 11:02, 9 May 2007 (EDT)

Hyphenation[edit]

A tiny bug prevented a new annotation to show up. This has been fixed and now it is possible to add hyphenation as an annotation.

There will be some more annotations; Sabine is keen to have the Apertium XML dat supported. This data provides information on the part of speech and the conjugation/inflection of a word. Adding new types of annotation is something that needs to be done after enough discussion. OmegaWiki is a database ... Thanks, 02:00, 20 May 2007 (EDT)

Adding new Hebrew language[edit]

In Hebrew each word can be written in two distinct ways: with or without Niqqud. The current rule accepted of writing Hebrew words is to write each word with and without Niqqud as synonyms. But the fact remains that they aren't two different words, the are two different ways of typing the same word.

What I suggest is making a new language called "Hebrew (Niqqud)" or something of that sort. This will decrease confusion between niqqud and non-niqqud words. This will also be benifited in the future when programs built upon the omegawiki database will want to search words in Hebrew with or without Niqqud.

Please consider my suggestion or any other means of seperating between niqqud and non-niqqud words in Hebrew.

Thanks in advance. --Dirk gently 16:55, 20 May 2007 (EDT)

Portuguese sort order[edit]

In an expression, the synonyms appear sorted by their language in the user's UI language. In Portuguese, we have accentuated characters and their sort order is the same as their non-accentuated counterparts. I happen to see the translation for Arabic (árabe) at the bottom of the list, right after the new synonym box, and not among the first languages (starting with a) as it would be expected. This is not an important issue but if it's not a difficult one, I'd like to see it fixed at some point. Regards, Malafaya 06:42, 22 May 2007 (EDT)

The sort order is only based on the first column and it makes use of the sorting order that is implicit in the software. Changing this is non trivial and is likely to be expensive in performance. GerardM 04:53, 24 May 2007 (EDT)
Gerard, I think this request is entirely legitimate, and more demanding sorting requests will appear in the future. Is it a goal for OmegaWiki to be able to present a comfortable experience for a native Portugese speaker to look up Portuguese language definitions of Portugese words, and for a native Swedish speaker to look up Swedish language definitions of Swedish words, and so on? If so, then it is a requirement that lists be sorted according to Portuguese, and Swedish, and many conventions — and the orderings are different. It will be necessary to find a way to make the sort order a user preference setting, and get acceptable performance anyhow. I guarantee you that no matter what sorting order is "implicit in the software", it will be wrong for some users who want OmegaWiki to conform to their native language dictionary conventions. Further, I can guarantee that some of the sorting orders won't be in character code order, they will require other data fields and/or the full power of the Unicode Collation Algorithm. If changing it is non-trivial, I suggest it's worth adding "sort order selected at runtime, using Unicode Collation Algorithm" to the task list now. JimDeLaHunt 00:40, 25 June 2007 (EDT)
If there is one way in which we are going to implement this, then it will be by using the CLDR methodology. However, we will only implement it when it either is programmed by someone who does it because it tickles his fancy or when we have the basic functionality that is still missing.
Certainly we want to have the best functionality. But there are too few developer resources as it is and this IS a complicated business because the information for many locales has not been officially established for many languages. GerardM 00:53, 25 June 2007 (EDT)

PHP[edit]

Hoi, we are programming at the moment on OmegaWiki functionality. It turns out that you will need PHP 5.2 in order to run the latest software.. It will be announced when we start to have new functionality on line. GerardM 04:44, 24 May 2007 (EDT)

New functionality... Sounds cool! Malafaya 06:25, 24 May 2007 (EDT)

Semantic Relations, for example america->continent[edit]

Which is the place to discuss semantic relations ?

For example: in my opinion the most of relations to continent are wrong. "america" is an instance of "continent", "continent" is not a hypernym to "america". Which are the people taking care of semantic relations here ? --Toka 03:24, 28 May 2007 (EDT)

At this moment we do not really support semantic relations; that is we have a set of relationtypes inherited from the GEMET import and they are used for whatever. The support that we are seeking is to have both collection and domain specific support.
Given that this is a wiki, you can remove the hypernym relation between America and continent. When you think of it, America is not a continent, North America is. GerardM 03:40, 28 May 2007 (EDT)


At the moment it seems that it is not possible to edit relations other then removing and adding a new one. Are the possible relations marked in some wiki-way or hardwired into omegawiki ?

I do not understand your comment "we are seeking is to have both collection and domain specific support".

Linking to Talk pages[edit]

On the Talk page for DefinedMeaning:Colorado I wanted to link to the Talk page for DefinedMeaning:Arkansas. I couldn't figure out how to do it. (Everything I tried seemed to create a new page.)

For that matter, I wasn't able to link properly to the DefinedMeaning page either. Can someone point me to a place where this is explained, with examples?

Thanks. Rsperberg 09:49, 29 May 2007 (EDT)

The links DefinedMeaning:Arkansas (337982) and DefinedMeaning talk:Arkansas (337982) work. For defined meanings you need the number, the name is not relevant. To find the number click on the name (Arkansas:) left to the definition on the expression page, in this case Expression:Arkansas. Another possibility is to use Special:Datasearch.
I did not find a place where it is explained except Functionality wanted ..#Directly linking DMs / entering DMs in the address bar. --Ortografix 14:36, 29 May 2007 (EDT)
If I'm understanding you, I can simply copy and paste the heading from the page and not worry about the URI in the address bar. Thanks! --Rsperberg 14:47, 29 May 2007 (EDT)

Not receiving confirmation email?[edit]

Hi, folks! I'm a new OmegaWiki participant with a freshly-created user account. I've yet to receive a confirmation message. I've tried two different email addresses, both of which get email all the time from other addresses. I've clicked the link that causes another confirmation to get sent. It's been several days, so if it's a deliver problem it's a long-lasting problem. My concern is that OmegaWiki isn't sending emails at all. Has anyone had the same problem? conversely, are there people who have received a confirmation email in the last few days? Any suggestions for how to proceed? Thanks, JimDeLaHunt 02:31, 11 June 2007 (EDT)

Hmmm ... that is strange - the other day I got a note that my talk page was changed - so that worked. Now I will go and see if I can send you an e-mail through the system. Ciao! --Sabine 02:33, 11 June 2007 (EDT)
Ok, it does not work since verification of your mail is required. Did anybody else experience the same problems? --Sabine 02:34, 11 June 2007 (EDT)
Hi, I've just tried, and I received the confirmation e-mail immediatly (within a few seconds). The e-mail originates from moeller, scireview.de. Have you checked in your spam box? Kipcool 04:39, 11 June 2007 (EDT)

Thank you for your responses! I switched to an email address at GMail, and I received the confirmation message immediately — but it arrived directly in GMail's spam folder! I looked carefully through my other spam folders, but I didn't find the message there. I don't normally have my spam filters delete mail immediately, so I should have been able to find it. For now, I'll use the GMail address for my OmegaWiki contact point. Still, I'd prefer to solve the problem and use my primary mail address instead. JimDeLaHunt

Why did GMail consider the message spam? Here are some headers.

Return-Path: <daemon@localhost.localdomain>
Received: from localhost.localdomain ([69.64.173.238])
       by mx.google.com with ESMTP id b12si7376826ana.2007.06.11.13.03.27;
       Mon, 11 Jun 2007 13:03:27 -0700 (PDT)
Received-SPF: neutral (google.com: 69.64.173.238 is neither permitted nor denied by domain of daemon@localhost.localdomain)
Received: from daemon by localhost.localdomain with local (Exim 4.50)
	id 1Hxq21-0004Ce-Ls
	for [Jim's address elided]@gmail.com; Mon, 11 Jun 2007 15:58:29 -0400
To: JimDeLaHunt < [Jim's address elided]@gmail.com>
Subject: OmegaWiki e-mail address confirmation
X-Mailer: MediaWiki mailer
From: moeller [at mark removed to slow down spam scrapers] scireview.de
Message-Id: <E1Hxq21-0004Ce-Ls@localhost.localdomain>
Date: Mon, 11 Jun 2007 15:58:29 -0400

The thing that jumps out at me is the from localhost.localdomain designator. Maybe it would be better if that was omegawiki.org . Also it would probably help if OmegaWiki could designate the sending IP address for Sender Policy Framework (SPF) purposes. JimDeLaHunt 16:22, 11 June 2007 (EDT)

Update: mail comes through fine to my yahoo.com and gmail.com email address, it does not arrive at email addresses hosted by Verio and DreamHost (nor can I find it in spam filters, and I'm pretty sure I know where to look). I think something is definitely wrong, but I can't diagnose what it is. I'm happy to help someone knowledgeable diagnose the problem. In the meantime, I have a workaround: use GMail. JimDeLaHunt 02:35, 13 June 2007 (EDT)

DefinedMeaning:ett (5430)[edit]

Could someone please translate the definition of DefinedMeaning:ett (5430)? This DM is in the GEMET collection and nobody who doesn't know Swedish can translate it :). Thanks, Malafaya 12:32, 21 June 2007 (EDT)

It is probably the same as DefinedMeaning:a (5625), see wikt:sv:ett. HenkvD 13:49, 21 June 2007 (EDT)
I translated the DM, but it should probably be merged with DefinedMeaning:a (5625), so I added the two Swedish indefinite articles to that DM as well. How are we supposed to deal with terms like this? Adding a lot of grammar-specific DMs doesn't feel like a very good solution lexicographically. Gon-no-suke 17:23, 21 June 2007 (EDT)

InterActive Terminology for Europe (IATE)[edit]

Hoi,
Yesterday the IATE Database got online. It contains mostly terms (words and wordings) for politics, economics and administration in all 23 official languages of the EU. The database is in internal use since 2005 and now its public.

The database currently contains about 8 700 000 words, 500 000 acronyms, and 100 000 partial sentences.

Unfortunately it is not allowed to copy the data from the site. Maybe we can talk with them, but I guess this is a political issue. At least they will keep an eye of the database because they pay about 627 000 Euro per Anno.

see also: IATE Search form

MovGP0 11:13, 29 June 2007 (EDT)

I have been talking with people about permission to use the IATE data in OmegaWiki. It is not so much political as well financial. Companies who were contracted to do this work seem to have got the copyright ... GerardM 14:07, 29 June 2007 (EDT)