International Beer Parlour/Archive7

From OmegaWiki

Jump to: navigation, search

Archive 25-06-2006
Archive 28-07-2006
Archive 29-08-2006
Archive 25-09-2006
Archive 23-10-2006
Archive 09-01-2007 (About Language lists)
Archive 06-09-2007

Contents

[edit] Collections

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)

[edit] lld

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)

[edit] Credits...

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)

[edit] Italian's Interface

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)

[edit] The importance of an order and something more

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)

[edit] about "Annotation"

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)


[edit] Translator page

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)


[edit] Preventing orphans and double DM's

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)


[edit] Insect room and Bugzilla

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

[edit] Special:Statistics

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)

[edit] Sidebar link to MainPage

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)

[edit] How to edit this message?

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)

[edit] Bots on OmegaWiki

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)

[edit] Shortcuts

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)

[edit] Seasons greetings ..

:-) Knopfkind 06:41, 23 December 2006 (EST)
:-) 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)

[edit] Part of speech

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)

[edit] facilitating translation of critical documents

  • 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)



[edit] Translations without creation of a new expression?

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)

[edit] Previews

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)

[edit] Relations Question

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)

[edit] Handling transisivity

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)

[edit] IPA transcription

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)

[edit] Generating IPA

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)

[edit] Abbreviation

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)

[edit] Lingala

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

[edit] Mandarin

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)

[edit] Piedmontese

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)

[edit] New version of Mediawiki

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 :-)
  • ...

[edit] No Move tab?

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)

[edit] Shtooka

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)

[edit] Bot to split multiple expressions?

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)

[edit] Japanese readings and pronunciation

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)

[edit] Preliminary Conclusion

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)

[edit] Right to Left Pages

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)

[edit] New firewall

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)

[edit] Greek expressions with brackets

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)

[edit] List of themes

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 Topics (no Topics/deu 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)

[edit] Latin?

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)

[edit] New languages

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)

[edit] Prefixes

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)

[edit] Swahili and other "exotic" languages

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