Functionality wanted ..

From OmegaWiki

(Redirected from FW)
Jump to: navigation, search
Shortcut:
FW

Create a new section for new functionality.

Implemented requested functionality is moved to:Functionality wanted ../Archive 1

Contents

[edit] Domain functionality

Many relation types are only relevant within a certain domain; the jaguar can be a predator because it is an animal. This means that we have to have the notion of a domain.

[edit] Counting characters of words

The idea of OmegaWiki is that it will be useful to as many people as possible. Different communities bring different strengths to WZ but also weaknesses. Professional translators are interested in finding/adding translations; they are not really interested in adding definitions. People who do puzzles are very much interested in definitions and relations. (cat six characters starting with a “j”). The number of characters of an Expression that does not include a space, is easy to calculate. By providing query options for finding cats sorted by number of characters, you add a hole new group of people with an interest in WZ.

[edit] Benefit

More translations, and more linking to all kinds of relations. (remember, categories ARE relations)

[edit] Selecting several 'display languages'

A 'display language' has to be a language plus, where applicable, a variety selector, such as a geographic region or a specific script. Allowing a user to specify a set of such selectors in his preferences or via URL, independent of his interface language, selection should greatly improve usability for some tasks over having only the interface language.

[edit] Benefit

Reduces the number of routinely performed consecutive lookups. Increases the amount of useful information visible on one page for certain kinds of uses.

Allowing e.g. a serbian contributor to simultanously see cyrillic and latin script data at a time lets him quicker fill in missing data. In ethymology lookups, it's often necessary to review current and historic language data routinely. A translator working bidirectional may wish not to respecify his target language all the time.

It is desirable to separate interface language and target language for may tasks.

Technical supervision is easier, if there is a way to have all information of all languages available on one page rather than having to dig through thousands of specific pages. --Purodha Blissenbach 19:52, 18 July 2006 (CEST)

[edit] Varieties

In addition the expression in "English (United Kingdom)" or "English (United States)" should be displayed automatically when the interface language is "English" and there is no English expression.

Example: The page Expression:Sulfid now looks like that:
+– сулфид: Any compound that includes one or more sulfur atoms with a more electroposi...

--Ortografix 13:46, 14 August 2007 (EDT)

[edit] Transitivity and reflexivity of Relations

Currently a Relation is seen as going only from A to B, no matter what the type of the Relation is. That is, if a is related to b then the opposite b is related to a does not automatically hold, but has to be entered separately.

It is highly desirable to be able to specify a type of the relationship; f ex related to would be a reflexive relationship, so that adding it between a and b would make it visible from both a and b. Other relationships (f ex broader term would not be reflexive, but transitive, so that if a is a broader term than b, and b is a broader term than c, then it holds that a is a broader term than c

[edit] Benefit

It would greatly minimize editor work load if not Relations of this type need to be added on several places. --Sannab 10:22, 19 July 2006 (CEST)

See also previous entry #narrower terms / broader terms. HenkvD 16:33, 19 July 2006 (CEST)

[edit] Discussion from Insect room

narrower terms / broader terms

I added narrower term iron on metal, which is shown correctly on there. I expected on iron to show metal as a broader term, but that is not the case. Is this a bug, am I impatient or am I expecting too much? HenkvD 21:55, 1 June 2006 (CEST)

This was not considered in the software. The point is that not all relations are two way. This has to be considered on the RelationType level. It is not a bug, you are impatient as we all are .. :) GerardM 12:13, 3 June 2006 (CEST)
I've been discussing this with Peter-Jan. There are different implementation strategies -- we can add the relations redundantly, or we can treat certain relations as working in both directions on the database level. In the case of the former strategy, the software still needs to be aware that relation B is the inverse relation of A -- otherwise any future rollback capability will only roll back one side of the addition. For now, please add them from both pages, but I hope we'll have a solution ready soon.--Erik 00:07, 14 June 2006 (CEST)
As far as i can see this are the relations
  • broader terms <--> narrower terms
  • related terms <--> related terms
HenkvD 08:56, 14 June 2006 (CEST)
This relations are different:
  • (Relation:broader term, owl:inverseOf, Relation:broader term)
  • (Relation:related term, rdf:type, owl:SymmetricProperty)
but as you can see, OWL has a solution. The only thing that is missing is the programmer that is implementing this logic. MovGP0 11:48, 28 February 2007 (EST)

[edit] Presentation

I would add that ideally, most Relations and Incoming Relations should be presented in one section, by reversing the relation.

The reason for this is that it is extremely disturbing for a newcomer to read: 

Expression: ship
Relations: hypernym: vehicule
Incoming relation: tanker: hypernym

Most people have never learnt the concept of oriented graph during their life (especially writers or translators, I guess) so what they will understand here is that both vehicule and tanker are hypernym of ship and that for some reason which they don't want to mess with, they are presented separately . Ideally, all relations should be expressed taking the entry as the base. 

hyponym of vehicule.
hypernym of tanker.
part of theme navigation (and navigation "is one of the theme of ship", if we want to express that).

Just my two cents... I know that the writing guide speaks a bit about oriented relations, but most readers won't ever read that page or pay attention to this part. Eden 15:30, 12 April 2007 (EDT)

[edit] Entries 100% identical between languages

Many proper names (of geographic entities, persons, offices, organizations) are 100% identical over most or all languages. A 'redirect', an 'identical with Language: ISO-code'-flag, or a copy function …

[edit] Benefit

… could save considerable editing effort.

Is this really a good idea? It tempts editors to just assume the name is the same in different languages without actually checking. --Mkill 17:04, 30 July 2006 (CEST) Confer Expression:Beijing or Expression:Berlin for examples (or any other city). There are more subtle differences than you think. --Mkill 02:16, 5 August 2006 (CEST)

[edit] "Dirty" mark on related Expressions when DefinedMeaning is altered

Moved here from Insect room--Sannab 16:36, 21 July 2006 (CEST)

It would be very useful if there was a flag that would automatically be set to 'dirty' or 'needs verification' on Relations between Expressions and DefinedMeanings if the DefinedMeaning was in any way altered. Without such a mark, ensuring the quality of the related Expressions seems to me basically impossible.--Sannab 09:48, 3 May 2006 (CEST)

It should be part of a QA drive; when certain things are changed to a DefinedMeaning, the content needs validation.

[edit] Relation weight, Attribute weight

At times relations are of different strength; e.g. an expression may be 'central' or vital to a domain, while another one, although generally in the domain, is seldom used and is weakly bound. If such an expression is also in another domain, where it has another DefinedMeaning but probably itentical grammatical properties, it might be helpful to attach a weight factor to the binding of the expression to either domain.

[edit] Samples of possible uses

So a translator e.g. has some beforehand indication of the probability of one domain over the other, or (s)he can work on ambigous passages of text from the most uncertain (i.e. the most decisive, most discriminating) ones downward, thus possibly saving an amount of research on expressions that are not likely to give clues about the domain.

Some type of comedy uses sudden unexpected domain context switches, that makes it funny. "Good morning sir, what is your profession? - I am a psychiatrist. - Oh, I see. How am I today?", or "My cock popped out of my pants again … and hopped back over in the chicken shack" If we can relate the likelihood of double bound expressions (in two domains) to the aquaintance of an audience with either domain, we can tell how many in the audience will likely understand the joke using them. We can even take the reverse algorthim to construct new artificial expressions of the type "Alfons, der viertel-vor-zwölfte" or the "bottle of good old british spinster insective" with some likelihood to be funny.

This is to complex to use. Even Humans can't always translate jokes while keeping them funny. In synchonizing films human don't even try a 1:1 translation, but instead write jokes of their own for the target-language. I don't think that its worth the effort to teach AI thinks like humor (at least not on the current development stage of AI-Systems). MovGP0 12:03, 28 February 2007 (EST)

[edit] Adding more than one translation at once

It would be nice if clicking on the green plus button in the Edit window would open more edit boxes to add translations. At the moment, it takes one save each time to add translations, making the creation of new entries like Expression:Germany, where translations to every available language can just be copied from the WP article, a pain in the a**. --Mkill 17:39, 30 July 2006 (CEST)

I agree, this would be a real time saver. We could klick something multiple times; or have a number pulldown next to the "+", similar to the language selection "+ add new language" (preferred), so as to open multiple fields for adding syn/trans. -- Purodha Blissenbach 21:00, 31 July 2006 (CEST)
Some versions earlier it was possible to add several translations at once (by adding a new line), so I think it will come back sooner or later. --Tosca 21:20, 31 July 2006 (CEST)
This is a main-issue. The roundtrips to the database each time costs lots of time and processing resources making it ineffective. I don't even need AJAX for this, just some client-only JavaScript for adding new rows and send back the translations and annotations all at once.
Currently, when providing translations, I'm 70% of my time waiting for the page-refresh. So, I hope this comes back very soon. MovGP0 12:08, 28 February 2007 (EST)

[edit] Language filter for Special:Allpages

It would be very nice if I could reduce the pages displayed by Special:Allpages to one select language, for example, all German words and all pages in German. That would make finding a specific word or checking for broken expressions in one language so much more easier. --Mkill 02:18, 5 August 2006 (CEST)

[edit] Grammar functionality

[edit] Parts of speech indications

Not very urgent, but crucial to the good functioning of DefinedMeanings, some indication of which part of speech is described is necessary. Probably a matter more complicated than expected, I guess, because not all languages can be treated as if they all make the same clear distinctions. — Vildricianus 18:53, 21 July 2006 (CEST)

I think what this request aims at is the ability to add additional grammar information, such as word type and gender. I consider this a basic feature that no dictionary can go without. It's most basic benefit would be to help clean up a lot of unclear definitions. For example, it would help to split the DMs in the English entry of Expression:alarm between the verb to alarm and the noun alarm. While these are identical expressions in English, they are not in most (non-isolating) other languages. Confer German Expression:Alarm, Expression:alarmieren (verbalization) and Expression:Alarmierung (substantivation of verbalization).

The complicated thing about Grammar information is, that it needs to be implemented for each language separately. I would suggest to implement English grammar only first, test it, and when it runs properly add grammar of other languages one by one. --Mkill 02:14, 5 August 2006 (CEST)

Once the techical means exist to define grammatical properties and relations, there is no need to wait for English. All languages grammars can be entered simultanously, they are independent of each other. Persons doing the work are (mainly) in disjunct groups, too. -- Purodha Blissenbach 01:36, 6 August 2006 (CEST)

[edit] advanced grammar functionality

Once OmegaWiki knows, what kind of word the expression in a specific language of a given DM is, it should offer a fixed set of fields to enter inflected forms. Depending on word type and language, the number of these is somewhere between zero and over a dozen. For english nouns, there will be the field "plural" and two checkboxes: "no plural" (Expression:milk) and "plural noun" (Expression:scissors).

The benefit of this is, that this will automaticly create an entry under the plural: If you enter the plural in Expression:dog unter the DM "common four-legged animal...", it will automaticly create Expression:dogs with the entry "Plural of dog (A common four-legged animal...".

The same with verbs: Once you entered the past participle in Expression:be, it will create an entry under Expression:been. --Mkill 11:31, 5 August 2006 (CEST)

A DM "Plural of dog (A common four-legged animal…" is imho nonsens. All inflected forms will link to the same DM+language as their base form, and they have a relation to it which names the inflection, i.e. (with the relation written in parentheses):
  • DM("four-legged…"):eng:dog → (nom.pl.) → DM("four-legged…"):eng:dogs,
  • DM("four-legged…"):eng:dogs → (nom.sg.) → DM("four-legged…"):eng:dog,
I think -- Purodha Blissenbach 01:31, 6 August 2006 (CEST)
Exactly what I suggested! (but the DM's in your example don't need to be separate, it can be one DM with two expressions: singular and plural (other languages with more complicated inflections, like German, will list even more expressions)) --Mkill 11:20, 6 August 2006 (CEST)
I started thinking along these lines a while ago, I have started to formulate it (but far from ready...) at User:Sannab/Inflectional groups. Also, to keep terminology straight, I think it has been stated clearly that all forms of the same word will be linked to the same Definition, but however that the combination of each Expression (here:word form) with that Definition will be considered a separate DM. That is Definitions will be reusable just as Expressions are now.--Sannab 11:34, 6 August 2006 (CEST)

[edit] second thought

Ok, I thought about this again and I think I get where the problem is: "inflection groups" (to use Sannabs term) and DM's don't match well.

A DM takes an expression in any language, links a definition to it and translates them to other languages. So far, so good.

Inflections need a different structure: Take one word from one language and list it's forms in different tenses, cases, numbers, whatever applies.

Problem 1: A word word have one inflection but several DM's attached to it. In the case of homonyms, several inflection groups will appear under one lemma, and DM's and inflection groups will need to be tied to each other in some way.

Problem 2: A DM is, at the core, one word in one language, and everything else is a translation or a synonym. It can't be used to store inflection information in those translations and synonyms, because these aren't inherent unchangeable parts of the DM.

So, what it boils down to is, that inflection information and DM's need to be separate structures. A DM is used to store an expression with it's synonyms and translations. An inflection group is used to store a word and it's inflected forms.

These need to be tied together in a way that under a lemma, you would find the following structure:

Example: alarm

  • English
  • alarm (noun)
  • inflections
  1. DM 1
  2. DM 2
  3. ...
  • alarm (verb)
  • inflections
  1. DM 1
  2. DM 2
  3. ...

Example 2: alarmed

  • English
  • past participle of: alarm (verb)

Note that when you fill in the entries for the inflections of alarm (verb), the entry above under "alarmed" would be created by the software.

What needs to be done to create this structure is to change the understanding of what is an "expression" of a DM. As of yet, the expressions are mere strings with a language tag attached. DM's need to be made smarter, they need to know whether the entry "alarm" under English is supposed to be the verb or the noun alarm. --Mkill 16:44, 6 August 2006 (CEST)

A problem that still needs to be addressed under this model are homonyms of the same word type, but with different inflections. In German, there are some of these (die Band vs. das Band, der Modul vs. das Modul). In German, these can be disambiguated by gender. But there could be cases in other languages that are a little more tricky. --Mkill 16:47, 6 August 2006 (CEST)

Yes, e.g. in Swedish "man" (with three different noun senses) all has the same gender but different plural. \Mike 12:17, 12 August 2006 (CEST)
There are several words like this in English: "hang" (verb) and "fish" (noun) come to mind. But they are obviously by far the exception, probably in any language. The solution I see is something like multiple inheritance: inflection groups normally associate with word/part of speech pairs and inherit down to DM but can also be overrided with a local DM value...--Homunq 19:52, 16 November 2006 (CET)

[edit] Different meaning of the same word vs. entirely different word

It would be great if we had some way to indicate whether two different DMs under the same lemma describe different meanings for one word or different words altogether. This distinction is necessary once we have grammar functionality: While DM's which indicate different meanings of one word would have the same grammar, different words which only share the same spelling would not. Example: German "das Band" vs. "die Band", English "to walk" vs. "a walk". --Mkill 11:31, 5 August 2006 (CEST)


I believe the entire idea is mistaken. Grammar attributes cannot be linked to DMs, they're only available any DM+language+expression (i.e. what you call 'word') so we have (re-using a recent example), simplified:
DM (short) language expression syntacto-grammatical info (excerpt) example sentence
Emanation eng birth linked-by-genitive → the-object-emanatingthe birth of a star
Childbirth eng birth linked-by-genitive → childthe birth of Don Niclas by Regina Niclas
Childbirth deu Geburt linked-by-genitive → childdie Geburt des Don Niclas durch Regina Niclas
Childbirth eng delivery linked-by-genitive → child the delivery of her son Don Niclas by Regina Niclas
Childbirth deu Niederkunft linked-by-genitive → motherdie Niederkunft der Regina Niclas mit ihrem Sohn Don Niclas
Here you can see, how you can translate eng:birth ←→ deu:Geburt, and eng:delivery ←→ deu:Niederkunft; but you could also do crosswise — in any case you've got to get the grammar right. While a human translator would usually not think much about the adjustments (they might, if not at all fluent), we have to consider and document them. At times, grammar is sufficient to exclude specific DefinedMeanings in many langages — your sample words are of that kind.
 
What if we have identical DM+language+expression and yet different grammar or syntax going with them? This is more common than one might think at 1st sight. E.g. a verb may have transitive and intransitive forms sharing a DefinedMeaning; if so, two sets of syntacto-grammatical properties will be linked to one key DM+language+expression, it is then up to the user to decide which of them she is analysing, or which he must (or wants to) use as a translation or synonyme. -- Purodha Blissenbach 01:12, 6 August 2006 (CEST)

While it's of course possible to limit grammar to DM+language+expression, this will generate a lot of redundant data and it's just not the way languages work. I think that's the main point: the structure of OmegaWiki will have to follow the structure of languages, or it won't work.

But first, to make it clearer, I think we talk about two different things: inflection and usage (syntactical information).

Let's start with inflection and look at an example: Expression:be. Currently, it lists 5 DMs. Note that all 5 DMs cover the same word: the English verb "to be". Entering information about inflection (1st person singular: am; present participle: being / past participle: been and so on) in all five DM's is possible, yes. It's just not a clever way to do it. It's much simpler to link all 5 DMs as "same word in English" and have the information about inflection stored once.

The other field is usage: Yes, syntactical information like linked-by-genitive is in fact closely linked to DM and the example Expression:be shows this very clearly. Three of them indicate usage as a normal verb, two of them usage as an auxilliary verb. --Mkill 11:19, 6 August 2006 (CEST)

Yes, we talk about both inflection and (syntactical) use at the same time. From a formal standpoint of view they're interrelated, and can be at our current level of generallity be collectively talked on. More specifically, these are of course language dependant and exist only in some languages as separable concepts of either grammar or syntax.
There is no redundant data, if these are linked to DM+lang+expr, where would the redundance be? (Wiktionaries currently do replicate the grammatical forms very often unless templates are used, but where would WZ?)
I did not in any way imply how the 5 DM+(eng:"be") were to be linked to their grammatical info, and I do not care. If there is only one set of inflections applying to all of them, then sure it would be economical to have in the end only 1 data base record describing them (and I am in favour of only having one in this case)
Forget the idea of defining something as "same word in English" - expressions may have 'all properties in common', that is all there is to it.
As to usage / syntac vs. grammar: call me a mathematical linguist in this field. There is no real distinction between them generally. In Latin or in English you can say there is a Grammar describing inflections of word, and there is a Syntax describing how words are arranges into sentences. Yet as letters form words, so do words make sentences, sentences make paragraphs, etc. It is one principle iterated. The mathematical concept of gammar can be applied on every level. -- Purodha Blissenbach 20:39, 7 August 2006 (CEST)

[edit] biological taxonomy

We have already a few entries on species. At the moment, the expressions are rather garbled. Example: Expression:chiropteran. To clean this up, it would be nice to have a means of adding the scientific names of species, families, and so on.

Expression:Chiroptera will be the same in every language, even those who do not use Latin script, like Japanese and Chinese.

I beg to differ. Expression:Chiroptera is 翼手目 in Japanese. Other taxons use katakana version of the binominal name. Gon-no-suke 03:45, 14 February 2007 (EST)
翼手目 is the Japanese name of the order, like Fledertiere in German. Still, Japanese sources always list the scientific name in Latin script, Wikipedia:コウモリ. It clearly says "Chiroptera" and not チロプテラ in Katakana (transcribing biologic taxonomy into katakana would be too confusing anyway).

So, what I wanted to say is, the scientific terminology is independent of individual languages and can be considered a language of its own. And it should be handled this way in Omegawiki. --Mkill 04:27, 16 February 2007 (EST)

Please look again. It says 翼手目 for the scientific name, and next to it there is a interwiki link to the English wikipedia at Wikipedia:Chiroptera. This is an English expression, not a Japanese one. Japanese scientific texts often list the English version of scientific expressions for more clarity. Since the scientific name is 翼手目 there is of course no need for an expression like チロプテラ in this case. For examples of transliterated latin taxonomy, check out the Wikipedia:アメーバ page. There are some latin names, but those are probably there as it is a bother or not clear how to transcribe into katakana. And yes, it is confusing... Gon-no-suke 09:32, 16 February 2007 (EST)

The idea is to add "scientific name" or something like that to the list of languages. Maybe this can be used for other purposes, too: Numbers, chemical formulae ... --Mkill 11:50, 6 August 2006 (CEST)

[edit] collocations

Another feature request... well, it can't hurt to collect them all, even if they will see implementation much much later...

What are collocations? A collocation is a combination of two or more words. For example, if you have "nuclear" and "accident", "nuclear accident" is a collocation of the two. We already have a lot of these in the database, including the example I just gave: Expression:nuclear accident. But so far, the database does not know that this expression is in fact a collocation. Adding this feature would help to create a better network between expressions.

So, collocations link an expression+language+DM entry (the collocation) with two or more other expression+language+DMs. Links should be added in both directions, if I define "nuclear waste" as a collocation of "nuclear" and "waste", it should appear in the collocation list of both entries.

It should be possible to create a cascade of collocations, for example defining "nuclear waste disposal" as "nuclear waste" + "disposal".

Collocations should not be transferred across languages and synonyms, because what is a collocation in one language, might be one word in another. (cf. Expression:little sister).

Note: it is already possible to link these expressions by using "broader terms" or other entries, but this does not always work. Example: "nuclear waste" while is of course a narrower term of "waste", it is not a narrower term of "nuclear". Also, as far as I know "broader term" and "narrower term" don't create bidirectional links. --Mkill 12:29, 6 August 2006 (CEST)

Just a thought I get when talking about "nuclear waste disposal": being able to define this as a collocation of collocations would also remove some of the present ambiguity. Is it "disposal" of "nuclear waste", or is it "waste disposal" which is "nuclear"? The latter is sort of nonsensical, but I'm sure there are situations where several different combinations are plausible. Each of these combinations would then be at their own DM. László 06:02, 14 February 2007 (EST)

[edit] unique placeholder DM content

Following up on Sabines note in International_Beer_Parlour#Adding_terms_while_translating I suggest to enable the usual wiki use of ~~~~ so as to create a unique placeholder for a series later to be filled in words inside DMs as a software extension -- Purodha Blissenbach 19:51, 7 August 2006 (CEST)

Huh, I don't understand what you mean by "enable the usual wiki use of ~~~~". Does it do something else than adding this : 150.214.57.42 16:44, 11 August 2006 (CEST) ? (Kip)
No, in relational data it does not do this, it simply remains as 4 tildes. -- Purodha Blissenbach 11:37, 23 August 2006 (CEST)

[edit] "Variant Spelling" Flag

Following up on International_Beer_Parlour#Variant_spellings, I'd like to suggest that if an expression is entered as a synonyme with 'Identical meaning' checked, then a 2nd flag becomes available which, when checked, puts both expressions in an equivalence class sharing most properties but their spelling and a class of attributes specifically related to classifying/grouping spelling variants. If shared properties are already there, they need to be merged. If this cannot be handled safely by software (e.g. due to omissions or contradictions in preexisting data), the user must be prompted to solve them, or the flag cannot be set. The availability of options in this field might be subject to user preferences or privileges. -- Purodha Blissenbach 12:29, 8 August 2006 (CEST)

[edit] Feature requests cleaned out from Insect room 11 august 2006

[edit] nice to have

  1. Special:Statistics should have a counter of the pages from Special:Allpages/GEMET:!.

[edit] Table with symbols to insert

When editing, a table with symbols to insert would be helpful. For example, see the table "Insert:" that appears in Wikipedia when you start to edit an entry. Such table is very helpful for editors switching between several languages. That looks like us! Miguel Andrade 22:28, 22 August 2006 (CEST)

Yes, that would be nice.. an example could be the way it is done on the English Wiktionary.. The missing Armenian alphabet is something Connel is about to include there .. :) GerardM 22:32, 22 August 2006 (CEST)
Caveat: The javascripts (indirectly) used in the Wikipedias MediaWiki:edittools entries only works on the edit box (single html <textarea>) but not on all other data entry fields. When I quickly glanced into it so as to estimate the time needed to adapt them to rather work on the field currently having the focus, I noticed that this is not easily done, and might need some care so as not to break other things. WZ would need this adaption, so as to have them available for the editing of relational data.

[edit] Search for special characters

This is of minor priority.
Some special characters are not found, likely due to MediaWiki treating them specially, even though they can be part of expressions. Samples:

  • [{{fullurl:Search:[}} Expressions containing an opening square bracket]
  • [{{fullurl:Search:]}} Expressions containing a closing square bracket]
  • [{{fullurl:Search:<}} Expressions containing an opening angle bracket]
  • [{{fullurl:Search:>}} Expressions containing a closing angle bracket]

--Purodha Blissenbach 21:57, 27 September 2006 (CEST)

[edit] Request for addition of CharInsert plugin

It would be very nice if the CharInsert plug would be added to this MediaWiki instance. This would enable us to add special characters in edit mode. Siebrand 22:31, 19 October 2006 (CEST)

see #Table with symbols to insert above. --Purodha Blissenbach 21:28, 19 November 2006 (CET)
The problem is that there is not one but MANY boxes that the characters need to be inserted. It therefore needs quite a lot of work before it works .. Yes we want this .. who want to do this .. ?? GerardM 22:16, 19 November 2006 (CET)

Mabee a convenient way would be to use JQuery and add this functionality with JavaScript on the browser side ? --Toka 10:38, 28 May 2007 (EDT)

[edit] Copying example sentences

I discussed this with Leftmost and he suggested I placed it on this page. Here goes:

Currently, if you add an example sentence to an expression, it is added to that expression only, and not to its direct translations. It is possible to add translations of the whole sentence, at that expression, but while that exact same sentence might be applicable at another expression, I still have to copy it manually, effectively creating a new example sentence, instead of a link to the original example.

Take Expression:voorbeeldzin. The Dutch translation, voorbeeldzin, is annotated with an example sentence. That example sentence is translated in English. However, the English translation of voorbeeldzin, which is example sentence, does not currently have an annotation. The English translation that is at voorbeeldzin would do perfectly at example sentence, but currently there is no mechanism to quickly put it there. A way to quickly copy it would be good, a way to link it would be better.

I hope I'm making sense. László 06:37, 18 December 2006 (EST)


  • So as to make the idea of linking more concrete, we should have a look into the general possiblility of using a mechanism like #redirect [[somewhere]] with relational data, as this may likely show up at other places, too.
  • While I would not mind doing it by typing, as suggested above, imho a better way of handling redirects, or forwarding links, was by virtue of a " [ ] Link " checkbox which, when checked, opens a drop down list for target selection.
  • There needs to be a specification wether of not referential integrity is required for such links. It likely varies depending on the type of link.
- just my 2ct. --Purodha Blissenbach 09:33, 18 December 2006 (EST)

[edit] Special:Newpages

I would like to have a page like Special:Newpages for new DefinedMeanings. It could also be usefull to have this for new Expressions. HenkvD 14:43, 10 January 2007 (EST)

With the new Wikimedia version of 5/2/2007 it is possible to select other namespaces. This works fine for all namespaces, except for Expressions or DefinedMeanings. HenkvD 15:52, 5 February 2007 (EST)

[edit] List of DM's without relations

I would like to have a possibility to list DM's without Relations. I am especially interested in DM's without neither is part of theme and broader terms to be able to find DM's at are currently roots or that might need linking. HenkvD 14:53, 10 January 2007 (EST)

[edit] RSS Feeds

I'm looking for an RSS feed from OmegaWiki to extract "new words for language XXX". It should only be words linking to their page, with none of the typing parts (like expression:) because they make the entry unfit to show in side bars (it's too long). Any idea? It would help in spreading participation by being published in local sites. It would also do good if more people checked new definitions. --Bèrto 'd Sèra 17:42, 29 January 2007 (EST)

RSS feeds do not have our priority at the moment, certainly not when we are to filter as well. There is plenty of stuff that I would rather have, inflections and conjugations come first. This does not stop someone to develop this. GerardM 03:06, 30 January 2007 (EST)
WikiMedia Foundation wikies have "recent chanes" IRC channels on irc.wikimedia.org. If the same functionality is in OW, or is an extension which would fit into OW, I believe it'd be pretty easy for a programmer to filter and format the data stream in the manner wanted. Whether or not it's a good idea to do it at this place is outside my scope to tell. --Purodha Blissenbach 15:43, 31 January 2007 (EST)

[edit] Language filter for Special:Allpages

I'd like to have a selection box with the languages on Special:Allpages, so that if you select a language it only shows expressions of that language.

This would be very helpful for an overview how well-stocked the dictionary is in a certain language. It also helps to search for expressions with spelling errors etc. --Mkill 01:49, 1 February 2007 (EST)

[edit] Namespace for sentences

Recent updates gave us example sentences. Now something that would be very handy to have would be a namespace to access those sentences, something like:

Sentence:To be or not to be. or Sentence:To be or not to be. (18384) or Phrase:To be or not to be.

What for? First of all, it allows easier access. You could click on an example sentence and you could see all existing translations, and click edit to add new ones. Of course, there could also be same-language sentences with the same meaning.

The second handy feature would be added relations. As it stands, each sentence is only connected to one DM. But sentences consist of more than one word, so many sentences could be referenced by multiple DMs. So the above example could be connected to be (DefinedMeaning:be (6480)) and or (DefinedMeaning:ou (433943)).

Third, there could be a function to annotate example sentences, such as marking the above example as a Shakespeare quote.--Mkill 21:51, 8 February 2007 (EST)

You can already have example sentences. The Shakespeare quote is only a part of what people remember; I do not think it is the whole sentence. GerardM 06:07, 11 February 2007 (EST)
I know that example sentences are already included, I was requesting additional functionality to handle them better. --Mkill 00:51, 13 February 2007 (EST)
Making example sentences searchable might be such a task. But I think you want them as different Entities, so the sencences can get reused with other words. Right? MovGP0 12:19, 28 February 2007 (EST)
Yes, exactly. --Mkill 00:57, 7 March 2007 (EST)

[edit] Auto-delete empty pages

So far, when you remove "expression1" from a DM, and there is nothing left under Expression:expression1, the page still exists. I would be great if the database would have a self-cleaning function that removes the page of deleted expressions the same way it creates a page when the expression is added. --Mkill 05:04, 11 February 2007 (EST)

[edit] New relation: opposite

I would like to request a new kind of relations between DMs: opposite. That way, "equality" and "inequality", "high" and "low", "give" and "take" etc. could be set in relation. It would increase the dictionary's usefulness as a thesaurus a great deal. --Mkill 05:07, 11 February 2007 (EST)

Why not call it antonym of. (unsigned)
An antagonism was another choice of wording. What an antonym is, depends in part on context, or domain of speech, and "antonym" is not necessarily identical to "opposite" - thingk e.g. of width, depth, hight when talking of measurements of three-dimensional objects; or high and low land versus high and flat mountains, etc. - So to remedy those interrelations better, which may even lead to more DefinedMeanings when done, it might be wise to introduce those relation types together with domain-of-speech functionality. --Purodha Blissenbach 09:46, 11 February 2007 (EST)

The Oxford Thesaurus uses "opposite", and I think that's an easily understandable term. Well, a rose is a rose, so call it whatever as long as we get the functionality :) --Mkill 00:52, 13 February 2007 (EST)

I thought that the opposite of high is deep!
Therefore we need to clarify the question what is a opposite? before starting to do any implementation. MovGP0 12:27, 28 February 2007 (EST)
No problem here. You can easily add two opposites to one DM.
high <-> low is the opposite pair when referring to land height and everything else that does not go below zero, such as prices.
high <-> deep is the opposite pair when referring to something that can go below zero, i.e. altitude when including the oceans.
Also, don't forget high <-> sober. --Mkill 22:53, 1 March 2007 (EST)

All we need to do for implementation is add the existing DefinedMeaning:antonym (7574) to the list of selectable relations. Please? --Mkill 23:10, 4 March 2007 (EST)

[edit] diff function

Now that we have a working history, it's time for step two: A diff function for edits in Expression. If you go to Special:Recentchanges and click on any (diff) in an Expression you'll notice we still need this. --Mkill 04:29, 16 February 2007 (EST)

I think the history function should be changed into a list of edits, like on standard wikimedia. The diff function could then be like the current history, but should be enhanced to be able to select the difference between two versions. A further enhancement on the logging could be that all changes should be logged on the users contributions. Currently of Expressions or DefinedMeanings only creations are logged. HenkvD 13:54, 16 February 2007 (EST)
Actually, I like the current format. What the developers could include is a list of changes in chronological order as an additional page for the history. --Mkill 13:03, 18 February 2007 (EST)
I would like to keep the current history too, but maybe under a different name. I wrote: The diff function could then be like the current history. HenkvD 13:39, 18 February 2007 (EST)

When speaking about the history I think its useful to group edits done by the same user. Therefore the history should not show something like this: 

# 17:27, 28. Feb. 2007 MovGP0
# 17:19, 28. Feb. 2007 MovGP0
# 17:08, 28. Feb. 2007 MovGP0
# 17:03, 28. Feb. 2007 MovGP0
# 16:48, 28. Feb. 2007 MovGP0
# 19:40, 26. Feb. 2007 HenkvD
# 15:48, 26. Feb. 2007 Mkill

but something like this: 

# 17:27, 28. Feb. 2007 MovGP0 (5x) [show]
# 19:40, 26. Feb. 2007 HenkvD
# 15:48, 26. Feb. 2007 Mkill

MovGP0 12:36, 28 February 2007 (EST)

[edit] Pictures

It would be great if we could add a picture to a DM. If I give you a picture of, say, an apple you'd instantly understand what is meant in any language. And it would be great for the children's dictionary. --Mkill 21:29, 17 February 2007 (EST)

There should also be links to the Wikipedia per each Expression; and links to the Commons per each DefinedMeaning. MovGP0 12:39, 28 February 2007 (EST)
Also there are cases where you need to translate even pictures: The Red Cross is translated to Red Halfmoon in some cultures, and so are the pictures. MovGP0 12:44, 28 February 2007 (EST)

[edit] Alternative expressions

For a number of languages, there are alternative ways to display a single translation (syntrans) in text. Some of these are limited to same-language dictionary entries, but they still are valid Expressions. In the current system there is no satisfactory way to add this information and I would like to propose to add this functionality.

This discussion started from the perspective of Japanese. In Japanese there are often multiple ways to write the same syntrans although they share the same DefinedMeaning, using hiragana, katakana, and different kanji. In addition there is a need to add a universial reading using hiragana, since it is impossible to be certain of the reading for an Expression by looking at the kanji. This problem is not one of mere transcription, since even native speakers need this functionality.

However, the functionality is not limited to Japanese. A similar problem is found in Korean and I belive this solution can also be of use in other circumstances, c.f. benefits.

[edit] Current usage

In the current system there are no ways to relate different expressions for the same DefinedMeaning. There are two solutions used so far, but both have serious shortcomings.

  1. Adding the connected expressions as synonyms (e.g. DefinedMeaning:bathroom (5916)). Problems:
    • No way to know what hiragana expression goes with what kanji expression where there are additional synonyms for the same DefinedMeaning.
    • No way to know if a hiragana expression is an acceptable translation by itself or just there for purpose of searching.
  2. Adding the reading as a separate DefinedMeaning with the hiragana as an expression, and link back to the kanji expression through relations (e.g. DefinedMeaning:ちっそ_(456162)). Problem:

Since users are already adding questionable data to OmegaWiki, we need to deal with these questions before the problem explodes in our face.

[edit] Proposal

There is no such thing as an annotation of a transalted_content type. There is a separate table called SynTrans; in it you find both the translations and synonyms. This negates the whole notion that is being proposed; it has to fit in the existing database.. it is different from how you think it is. GerardM 05:35, 23 February 2007 (EST)

Then please explain to me of what type the annotation in the table uw_translated_content_attribute_values is. It looks like translated_content to me. The following sql: 

SELECT st.syntrans_sid,
       ex.spelling AS expression,
       ev.spelling AS annotation,
       tc.translated_content_id,
       tx.old_text
FROM   uw_syntrans st,
       uw_expression_ns ex,
       uw_translated_content_attribute_values av,
       translated_content tc,
       text tx,
       uw_defined_meaning dm,
       uw_expression_ns ev
WHERE  st.expression_id=357612 AND
       st.expression_id=ex.expression_id AND
       st.syntrans_sid=av.object_id AND
       av.value_tcid=tc.translated_content_id AND
       tc.text_id=tx.old_id AND
       av.attribute_mid=dm.defined_meaning_id AND
       dm.expression_id=ev.expression_id;

Gives this result set: 

         syntrans_sid: 357613
           expression: Belgrado
           annotation: example sentence
translated_content_id: 402592
             old_text: The flight to Belgrade has unfortunately been delayed because of freezing fog.
1 row in set (0.04 sec)

As far as I can tell this is an annotation with a attribute value of the type translated_content that is stored in the table text. The object_id links this annotation to the SynTrans Belgrado. Accordingly I propose a similar table structure where a new annotation table uw_expression_attribute_values links SynTrans:es to annotations of type Expression. I would very much appreciate if GerardM or some developer could explain in more detail where I am misunderstanding things. Regards, Gon-no-suke 21:50, 25 February 2007 (EST)

[edit] Benefits

  • Using Expressions for alternative ortography will allow for the search function to work as before without changes.
  • You can add multiple alternative expressions.
  • You avoid showing invalid expressions in the list of translations.
  • You are not limited to showing "transcriptions" of a word.

Here are some usage cases for different languages. Some of these goes beyond the proposal, but they could easily be acommondated for afterwards.

  • Hiragana readings for Japanese kanji words.
  • Alternative kanji representations of Japanese words.
  • Hanja versions of sino-Korean words.
  • Pinyin or Bopomofo transliterations for Chinese.
  • Linking traditional and simplified Mandarin expression together.
  • Linking latin and cyrillic orthograpies for Serbian together.
  • Non-standard orthographies for Kölsh.
  • Chu nho and chu nôm versions of Vietnamese expressions.
  • Actual readings for modern Tibetan compared to classic Tibetan?
  • Inflections/conjugations??

The alternative expressions could eventually be marked with options to classify them as historical, non-standard, declanation, &c in the future.

[edit] Minimal implementation 

CREATE TABLE uw_expression_attribute_values (
    value_id int NOT NULL,
    object_id int NOT NULL,
    attribute_mid int NOT NULL,
    expression_id NOT NULL,
    add_transaction_id int NOT NULL,
    remove_transaction_id int
);

And of course some tweaking of the interface. In the initial version attribute Expressions could automatically get the same language as the annotated syntrans.

Gon-no-suke 02:50, 23 February 2007 (EST)

I second this request. Thank you Gon-no-suke! --Mkill 04:44, 23 February 2007 (EST)
This proposal cannot be implemented in this way; the way it is proposed is incompatible with the database. GerardM 05:36, 23 February 2007 (EST)
Then please explain why. I added my understanding of the database schema above. Gon-no-suke 03:54, 26 February 2007 (EST)
The idea is good, but the implementation has to be done in another way. I see it in this way:
  • Words are Expressions
  • Phrases are Expressions
  • Sencences are Expressions
  • IPA, Kanji, Pinyin, etc. are Expressions
  • Description of a defined Meaning is a Expression
But even they are all Expressions, they need different Handling. Providing IPA is easier, because this is about adding an additional tablerow in the database and an additional field in the input form, because you can use IPA with any language. But ie. Pinyin is specially for Chinese (and Japanese?), so it doesn't makes sense to provide a special tablerow, but instead a special table for the annotation. Therefore a table like: 
              Table:Speech
+--------------+--------+--------------+
| ExpressionID | Type   | AnnotationID |
+--------------+--------+--------------+
| 耳           | IPA    | əɻ           |
| 耳           | Zhuyin | ㄦ           |
| 耳           | Pinyin | er           |
...
could work. In this example the Annotations are still a kind of Expression, but stored in a separate table. The advantage is that this solution is more flexible and doesn't affect the current database design.
Also the search has to get extended for this. If a Expression is not found in the Expressions-table, then the Annotation-table will get searched too. To improve speed, it might be possible to let search don't search the Annotation if there is a perfect match within the Expressions unless using advanced search. MovGP0 13:28, 28 February 2007 (EST)

@MovGP0: Please read my solution once more. I propose an extra table linking an expression (actually a SynTrans; object_id) with its alternative representation (another expression; expression_id) in a similar way to your table above. The difference is that the AnnotationID is another ExpressionID, so that the annotations are kept in the same table as the "normal" expressions. A lot of them are normal expression, so I think this makes sense. They are not kept in an new field, they are separate entries in the table. Another difference is that I havn't added any type information, but this could be possible in a smiliar way to the POS tags used now. As you say, the Handling have to be different, and it will be since alternative expressions are linked through a different table than the SynTranses, and can thus be handled differently when displaying. As they are not listed in the SynTrans table they will not be shown as direct synonyms/translations of the defined meaning. This proposal will also not affect the current database design, it only adds one table.

As a side note, your view of OmegaWiki is not in sync with the database.

  • Sencences are Expressions
  • Description of a defined Meaning is a Expression

These are not handled as expressions in the database, they are stored in a free-text table (the same as the Wiki pages) separate from the words and phrases. Gon-no-suke 18:15, 28 February 2007 (EST)

[edit] Directly linking DMs / entering DMs in the address bar

So far, a link like DefinedMeaning:chocolate (without the correct number) creates a database error. What I was thinking about is a way to redirect these to a useful result.

It would be great if such a link would instead open a page with a search result of "chocolate", "English:A rich, sweet foodstuff...", to lead the user where he wanted to go.

The page could also include a link "create a new DM for "chocolate".--Mkill 12:24, 25 February 2007 (EST)

The proposed link does not allow for homonyms. The DM will always include a number. It is the text part that is not needed. GerardM 01:13, 26 February 2007 (EST)
I see. Well, it would also be handy if links like DefinedMeaning:100 would work. Bots might use that a lot. --Mkill 10:48, 26 February 2007 (EST)
DefinedMeaning:(100) does already work, although the link is red and in the DM it looks red too. HenkvD 14:40, 26 February 2007 (EST)
Maybe the software could auto-redirect DefinedMeaning:(100) to DefinedMeaning:agriculture framework plan (100) ? --Mkill 23:12, 28 February 2007 (EST)

[edit] Stylistic level

To start a discussion on how to add stylistic level / level of speech functionality, I created stylistic level. Please have a look. --Mkill 00:58, 7 March 2007 (EST)

[edit] Definitions needing translation Special page

It would be absolutely great if Special:NeedsTranslation would get a sister page that allows you to search for missing definitions in a language instead of missing translations. --Mkill 09:18, 10 March 2007 (EST)

[edit] Language quick-pick

It would be great if you could select three or four languages, that the language drop-down box already displays before you enter anything into the edit field. This would speed up editing a great deal. After all, most editors contribute in only a one, two, maybe three languages. The languages shown in the box should be selectable in the user preferences. --Mkill 09:18, 10 March 2007 (EST)

[edit] "Advanced" implementation: known languages in preferences

I've been thinking about this again, and I've come up with a better implementation:

If users could select their language abilities in the preferences, we could add this and even more features:

  • automatic creation of babel boxes
  • preselected languages in edit fields
  • expressions and definitions in known languages are displayed at the top
  • In word search fields, such as when adding relations to DMs, it currently displays the definition either in the interface language, or, when that one does not exist, in the topmost existing language. Instead, the software could select an alternative known language. --Mkill 01:36, 13 March 2007 (EDT)
This has my full support! It would be so much easier to see the Expression and Meaning in both the languages that I use most; it would really start to make OW actually useful! Sergio.ballestrero 17:15, 9 June 2007 (EDT)

[edit] "core expression" tag

It would be great if OmegaWiki had a flag to mark one expression as "best fitting the definition" in one particular language.

This flag could be automaticly set for the first expression that is added in a foreign language, but it should be possible to change the flag to a different expression in the same language, kind of like a radio button.

What do we need this for?

First of all, OmegaWiki depends on certain DMs to translate part of its user interface. To prevent the software from picking a term at random, we can let it choose the one with the "core expression" flag.

OmegaWiki has no practical limit on how many same-language synonyms it can collect under one DM. For some uses, this is an advantage, for example when you use it as a single-language thesaurus. When you write a text in a foreign language, and the word that comes to your mind does not perfectly fit what you want to express, you need synonyms.

For other uses, a large list of synonyms is a disadvantage. When you are just a beginner in a foreign language, you don't want a long list of terms that contains slang, poetic and outdated expressions. All you want is the best-fitting and most widely applicable word for what you want to say. Identifying a core meaning helps here, too.

The core expression flag would also help in cases, where the definition is only given in an obcure language, but there is a long list of expressions.--Mkill 01:00, 13 March 2007 (EDT)

[edit] A new look at the Japanese kanji/reading issue

I use a digital Japanese dictionary (Canon Wordtank G55) every day and I was wondering how that one handles Japanese in its database, especially the Super Daijirin. The Daijirin is a good model because it is a Japanese-Japanese dictionary, i.e. it links Japanese expressions with definitions.

Using Hiragana as base

What I found is that entries are based on their Hiragana readings. That makes sense: In the spoken language, if you say すし (sushi) it always has the same meaning, regardless of how you represent the word in writing (寿司、鮨、酸し、寿し). On the other hand, different readings for the same Kanji often mark a difference in meaning, i.e. different DMs.

The different ways to represent a word in writing (different kanji, hiragana, katakana, or romaji) are tied to this hiragana expression+definition entry (or syntrans in OmegaWiki terms).

Advantages of the hiragana-based approach:

  • expressions can easily be sorted using the Gojūon
  • Only one syntrans entry represents all ways to write a Japanese word/expression
  • Hiragana can be auto-converted to Katakana, Kunrei-shiki (a romanization) and the Hepburn-system (another romanization)

If we follow this structure for OmegaWiki, we need some basic attribute annotation logic, as we need a special syntrans annotation that is only used for Japanese.

Basicly, it's a variant of the string annotation we already have for syntranses. For the sushi example, 「すし」 in Hiragana would be the syntrans, and 寿司、鮨、酸し、寿し would be added as Annotation->string properties->Property "Kanji"->Text "寿司".

Where do we need advanced functionality?

Selecting the displayed expression

A word could be written in different kanji, with hiragana, katakana, romaji, or any combination, but there is always one most common way to write it. So, we need a second annotation, how the syntrans is represented in the interface.

Option properties->displayed term->hiragana / katakana / kanji1 / kanji2 ...

Display

When opening an Expression or DM with a Japanese syntrans, the entry should look like "[selected display term] ([Hiragana reading])", i.e. "寿司 (すし)" Advanced functionality would be that the Hiragana reading is replaced by a transliteration selected by the user/the interface language. I.e. somebody who can't read Hiragana could opt to have Japanese terms transliterated using the Hepburn system.

In Special:Allpages, Japanese entries should be sorted by the hiragana gojuon table, but the term displayed on the page should be the selected most common one.

Access

First of all, the Japanese syntrans should appear, no matter which of the different expressions you enter in the adress bar. "Sushi" should appear under Expression:すし, Expression:寿司, Expression:鮨, Expression:酸し, Expression:寿し, even though the latter terms are not syntrans entries on their own, but annotation text.

Auto-conversion

We need a function to auto-convert Hiragana to Katakana (for terms that are normally written in Katakana), and to Kunrei-shiki and the Hepburn-system

Romaji terms

A few Japanese expressions include capital letters of the latin script, such as 「ＩＳＯ規格」(Iso standard). The easiest solution is to allow latin letters in Japanese expressions. These would be treated like Kanji and other ways of writing. ＩＳＯ規格 would be entered as "いそきかく" (isokikaku). --Mkill 01:13, 18 March 2007 (EDT)

[edit] What can be done technically and how

First of all any string that you want to be able to search for is an Expression. You want to be able to search for ANY string in any script. This is basic functionality that we do not want to compromise. It means that not having 寿司 as a Syntrans is not a good idea because this is where the connection to a DefinedMeaning happens.

Having functionality that allows for connecting the Syntrans records in different scripts for Japanese needs programming. The first language based functionality we have in our Part of speech implementation. This will need to be further developed to satisfy you. One of the things required is to recognise the script. This is doable given that we use UTF-8.

What comes directly to mind is to link Expressions that differ in script together in a relation kind of way. The big challenge is that relations link DefinedMeanings, here we want to link Expressions. This takes some serious thinking and development.

I do not understand why annotation text should be findable as an Expression; it is either an Expression or it is not. Annotations are not findable in their own right. There may be some query options for certain attributes.. but that is for later. GerardM 03:28, 18 March 2007 (EDT)

[edit] Etymology

Part of speech have been added as an annotation which is quite sensible at first sight but would be much better if we could consider word family. Knowing that acquérir is a verb is nice already, but better yet is if it can tell you that acquérir is the verb from the noun acquisition (or acquisition and acquis are nouns based on the verb acquérir) or that acquis is also the adjective derived from the same verb.

For this, we can add proper relations between words of a same family or if we would have etymology, looking at the stem would give us, thanks to relations (based-on-stem? verb-based-on-stem?) or to "what links here", all words based on a stem which is somewhat equivalent to the relation mentionned above, but better yet: you don't have to enter the information n times (but you don't necessarilly know what part of speech it is, depending on how it is implmented). Eden 08:00, 15 April 2007 (EDT)

[edit] Domains for an expression

A word without context (language, epoch, circumstances) has no meaning so I think it would be great if at least we could indicate a domain of use for the expression we enter. Lejocelyn

Hi Lejocelyn, thank you for posting this since the relevance of Domains is somewhat underestimated in this project (at least to my very personal opinion). We translators cannot really work without them and OmegaWiki like it is now seems to be a monster with huge teeth, but many of them still missing ... well ... hopefully they will grow. I would so much like to see more translators here, since we would need their opinion on this, or better: I know we would get so many more notes about "yes domains are definitely needed".
So dear developers: this is one of the things you will need to look at ... because it is not just a joke: there are thousands of translators that need the domain - and it will be needed even more when OmegaT shall become connected to OmegaWiki. --Sabine 13:33, 6 May 2007 (EDT)
This would be really useful, but how would the domains be defined ? - FrancisTyers 07:00, 22 May 2007 (EDT)
May-be having just only limited domains would be great. And with the demand and only after a process of validating adding new domains. Like starting with only 200 domains would be enough. Something like having this :Science>Mathematics>Geometry>Squarre would be interessant. So Science would be a domain as Squarre would be. And the user would specify the importance with ">".

[edit] Collection statistics don't include non-English translated DMs

Currently, DMs that are not translated to English don't appear in the missing translations for any language, in the collections statistics and missing translations list. It would be nice if they appeared instead of having to look for the missing ones trying to guess what languages they are already translated to. (Example: DefinedMeaning:fleuriste_(447049) is part of OLPC collection and it's not listed in any language as a missing translation -- because it's not translated to English) Malafaya 00:18, 9 June 2007 (EDT)

Hoi, they do not. In a way it is a shame, however this functionality was created by a volunteer effort and it is much better than what we had before.. nothing. When someone is willing to take up this code, and make it better, then it would be cool. GerardM 06:51, 9 June 2007 (EDT)

It sure is much better than the nothing we had before. No doubt about it! :) And many thanks to Zdenek Broz for the job! I was wondering how I could find the 12 DMs whose portuguese translation is missing for OLPC though. Malafaya 11:15, 9 June 2007 (EDT)

Corrected! ;) Malafaya 11:26, 21 June 2007 (EDT)

[edit] Page too long

WARNING: This page is 65 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

I doesn't have to be an archive maybe split into smaller parts with some navigation arrows at the page top ie.

[[<prior to 12/31/2006]] [[<01/01/2007-06/31/2007>]] [[next>]]

--Chief Mike 06:49, 9 July 2007 (EDT)

[edit] Function tabs

A + tab add new section on this page even though it is not a talk/discussion page.
A "SHOW SOURCE" tab next to to "EDIT" tab. Why because I often like to use samples of code while editing an other page (standard wiki-page). It lessens the risk of a mistaken edit with multiple windows/tabs open.
I would add these myself (from W:User Scripts) but I'm afraid of breaking my MonoBook.js --Chief Mike 06:49, 9 July 2007 (EDT)

[edit] Case-sensitive search

The search function needs to be case-sensitive. --Ortografix 17:25, 18 July 2007 (EDT)

You can do this by using Lucene Search 2 extension at OmegaWiki. The exact-capitalization is currently set on wmf wiktionary projects. (source: bugzilla) Kipcool 18:09, 18 July 2007 (EDT)
Lucene may be a good tool but that is no solution for the 'normal' user. --Ortografix 13:14, 13 August 2007 (EDT)
If you want an extreme example: http://www.omegawiki.org/w/wiki.phtml?search=Greenland --Ortografix 12:04, 17 August 2007 (EDT)
I REALLY want this. It is such a pain.. Thanks, GerardM 16:09, 17 August 2007 (EDT)

[edit] Some exports

I would like to be able to export a list of all the pages I've edited -- with the comment I made at that time.

I would like to be able to export all the words in Khmer, with the English definition and the Khmer definition if there is one. Well, that would not be difficult now, since Khmer has relatively few words entered in OmegaWiki. I guess there'd need to be some way to keep this practical if there were 25,000 words.

I'd like to be able to keep a list of words (or DM's, or Expressions) that would be a collection of Rsperberg words. And then I could (A) export my list or (B) restrict my searches to words in my list.

For that matter, I'd like to be able to get the export in XML or in PDF (that is, a format immediately suitable for printing). -- Rsperberg 18:55, 22 February 2008 (EST)

[edit] Wikipedia article link should be language sensitive

The Wikipedia article link (present in annotations) should be language sensitive. See DefinedMeaning talk:Wikipedia article (740663) --Purodha Blissenbach 07:08, 8 April 2008 (EDT)

[edit] Khmer numerals

I see at DefinedMeaning:hundred (6685) that the word "hundred" has annotations to Arabic numerals (100) and Roman numerals (C).

Khmer is a language that does not use Arabic numerals but instead its own:​​ ០​ ១ ២ ៣ ៤ ៥ ៦ ៧ ៨ ៩​ (eg, 0 1 2 3 4 5 6 7 8 9). (Unless you have a Khmer font installed, the Khmer digits will probably not display. They are the ten consecutive glyphs in the Unicode range U+17E0 through U+18E9.)

It would be useful if Khmer numerals could be added as a property under Annotation - Plain Text, as Arabic and Roman numerals are. Rsperberg 10:53, 7 June 2008 (EDT)

Added. :) GerardM 18:54, 7 June 2008 (EDT)
Thanks! Rsperberg 14:38, 8 June 2008 (EDT)

[edit] Add 'usage' to annotation

Khmer has two words meaning "yes." There is no difference in their meaning whatsoever. But one should be used only by a man and the other should be used only by a woman.

Similarly there are many expressions in Khmer that have the identical defined meaning -- some words are for common speech, others should only be used when addressing a monk, others when addressing royalty, others still only by royalty. So the king's chauffeur and the king use different words for "car" and the like even when conversing with each other.

For that matter, if I recall correctly, there are about 18 different terms for "you," each reserved for a particular class of person (for instance, a female relative older than you).

Lastly, there are many words whose usage is restricted to formal circumstances, and others that carry a insulting or obscene meaning, and so on.

I think the annotations for plain text ought to include "Usage" so that this information can be carried with the Khmer word. Apart from the complicated community and familial relations, there is a fairly well circumscribed set of usage instances for Khmer: formal, royal, colloquial, insulting, obscene, archaic, religious, and mystical are ones I have encountered. (I will see if I can locate a complete list used by various dictionaries.) Rsperberg 22:53, 8 June 2008 (EDT)

[edit] Downloadable data

It ought to be possible to anyone to download the data that makes up OmegaWiki -- for example, as SQL statements. Currently, this is not possible.

It is currently impossible for ordinary users of this site to exercise the rights granted to them by the GFDL.

RobSpeer 16:31, 24 June 2008 (EDT)

Hi, the Development page explains how to download both the data and the software. --Ascánder 16:57, 24 June 2008 (EDT)
Retrieved from "http://www.omegawiki.org/Functionality_wanted_.."
Personal tools
Toolbox