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

Meta:Insect room/Archive/2014

From OmegaWiki
Jump to: navigation, search

→ Meta:Insect room/Archive/2013

Wiki-Tags do not work[edit]

The <sub> tag appears to be broken in the Expression namespace. For example see Expression:water. --Tosca 18:33, 1 June 2006 (CEST)

We want definitions to be "self contained" this means that a definition should not link to other definitions. There are several good reasons why we do not want this. One is that we do not yet link to DefinedMeanings but to Expressions. As to markup, some markup particularly the sub sup italic and bold are things that may be usefull. They have to be (re)enabled for the definitions.. Thanks, GerardM 12:17, 3 June 2006 (CEST)
We're working on a whitelist for some parser functions (or rather, a mini-parser for OmegaWiki). But, for the most part, we're going the relational route as far as possible. We may have the ability to link to a disambiguated term using a special syntax in the future.--Erik 00:10, 14 June 2006 (CEST)
Any progress/new ideas on this, Erik? Siebrand 18:33, 18 October 2006 (CEST) Siebrand 15:08, 30 November 2006 (CET)

Done Done Imho not a bug. Wiki tags inside expressions are forbidden anyways, and both definitions and expressions can be used and exported to whatever environment outside OmegaWiki where wiki tags can not be dealt with. --Purodha Blissenbach (talk) 13:43, 26 January 2016 (CET)

New messages notification[edit]

But it' not true, just only one posted a month ago but the orange message does not disappear! I have a mac with safari. The Doc 10:18, 14 June 2006 (CEST)

Is this still an issue? Please provide feedback. Siebrand 18:34, 18 October 2006 (CEST)
Yes it is, people with spaces in their usernames have this problem. Needs Mediawiki updating. Kipcool 18:04, 22 November 2006 (CET)
Fixed GerardM 03:23, 9 August 2007 (EDT)
Over fixed: I never get any notification for the pages I want to follow. 00:34, 26 September 2009 (UTC)
Did you select "M’avertir par courriel lorsqu’une page de ma liste de suivi est modifiée" in your preferences? --Kipcool 21:33, 9 October 2009 (UTC)
No but, on Wikipedia, for instance, when I connect and a page I follow has been modified, I then get a notification on the form of a banner in the web site itself, than is at the right time. Isn't it supposed to work like that in Omegawiki? 12:08, 2 December 2009 (UTC)
I've seen such a banner only for modifications to my talk page (also in Wikipedia). --Kipcool 13:49, 5 December 2009 (UTC)
I suggest we test. You select a Wikipedia page you want to follow, you say me which one, I modify it and inform you, then you check if you get a banner. Fortunately I never receive mails from Wikipedia, so if this doesn't work, I wonder what is the "Follow this page" checkbox for. 06:35, 20 December 2009 (UTC)

Likely Done Done meanwhile. --Purodha Blissenbach (talk) 14:18, 26 January 2016 (CET)

edit boxes overlapping other clickable items do not work[edit]

See last entry - if edit boxes overlap with other clickable content already on a page, selcting from a drop down list by clicking an item becomes impossible (with Opera 9.02 under WIN2K) - yet one may end up with the wanted item always at the wrong place. Opening and closing subdivisions on a page (- other languages / + other languages, etc.) may help to avoid the unwanted overlap. Unfortiunately, that may not always be possible. --Purodha Blissenbach 12:47, 25 December 2006 (EST)

I assume, the following description (stolen from User_talk:GerardM) describes the same problem.

Partially Done Done --Purodha Blissenbach (talk) 14:23, 26 January 2016 (CET)

Spaanse woordsoorten[edit]

Hola Gerard, Zalig Kerstfeest, met wat je vroeg hoop ik dat het is, waar ik nu met bezig ben, namelijk de woordsoorten in het Spaans te zetten. Spijtig maar ik kan de annotation mode niet gebruiken. Als ik naast de vertaling op annotation druk opent een vak met 3 keuzes. Ik kies dan de laatste en bij "attribute" kan ik "woordsoort" in brengen, tot hier alles ok maar bij de "option" waar zich een klein keuzevakje bevind loopt het mis. Druk ik daarop rolt er een piep klein vakje open 4 cm hoog of laag en 1 cm breed. Daar kan ook niet in geschreven worden. Doe ik wat verkeerd of is het iets anders maar ik heb vanalles geprobeerd en het lukt me niet. De groetjes MARCEL 12:16, 25 December 2006 (EST)

I have the same problem. HenkvD 13:47, 25 December 2006 (EST)
Translation please? Malafaya 15:27, 10 October 2009 (UTC)

In short: Cannot create or add word class annotations (of Spanish, in this case) - had been fixed and is broken again in a different way, see #Cannot add class attributes option values. Thus Done Done and shoved into the new bug. --Purodha Blissenbach (talk) 13:40, 26 January 2016 (CET)


At the top of Special:Specialpages, there's a funny-looking link to Special:Select. The latter page throws a database error. László 12:08, 12 February 2007 (EST)

OK, I've found SpecialSelect.php. Will fix later. László 03:08, 15 February 2007 (EST)
This has somewhen gone away :) László 09:07, 9 August 2007 (EDT)
I believe this page has some specific use and is expecting some parameters to be thrown in. An improvement would be input checking. Malafaya 01:46, 12 February 2009 (CET)

Done Done but there should be documentation on the special page → T124772]. --Purodha Blissenbach (talk)

Long time to respond[edit]

Strange: The section before this one just took over 10 minutes to be saved. During that time, I had a trip to the bathroom, did various other things, and tried to load a number of pages from OmegaWiki in several browser windows, which all would not load during that time. --Purodha Blissenbach 02:07, 25 September 2010 (UTC)

And the server did not crash, so this is a good news.
I reduced the number of apache servers, to prevent swaping. When no more server can be created, you have to wait. --Kip 08:18, 25 September 2010 (UTC)
Aaah, I gotcha. I was doing several things in parallel, but the Lord himself may know what took more than tem minutes for all server copies to terminate. MediaWikis job queue, perhaps?
Yeah, really good, that it did not crash. I was happy! Greetings --Purodha Blissenbach 21:34, 25 September 2010 (UTC)

Apparently Done Done --Purodha Blissenbach (talk) 13:25, 26 January 2016 (CET)

Pop-up windows for Annotation don't close[edit]

The pop-up windows for Annotation links don't close, they prevent seeing or clicking on what is underneath. A close button is needed. --InfoCan 23:08, 8 March 2012 (CET)

You have to click on the same Annotation link again to close it. If it does not work, please indicate the browser you are using. There are some problems with Google Chrome (I'm working on it), but not this one. --Kip 09:29, 9 March 2012 (CET)
Oh, indeed it does! The popup panels that appear when you click on a textbox have it ("clear previous next X"), I guess I was expecting the same behavior. --InfoCan 18:39, 9 March 2012 (CET)
This is confusing for newbies. I remember I had the same problem. Would it be difficult to change the colour of the link (to orange, for instance) and maybe its size once the annotation is open in order to draw attention to the link? 23:22, 11 March 2012 (CET)
I can add an X and change the colour. I am in the process of rewriting the code so that it works fine with Google Chrome (and optimized with jQuery). I can do the change in the process. --Kip 23:34, 17 March 2012 (CET)
Thank you in advance. 14:49, 26 November 2012 (CET)

Looks like this was Done Done --Purodha Blissenbach (talk) 13:21, 26 January 2016 (CET)

Search Text[edit]

When there is no search text entered in the page Special:Ow_data_search, the resulting headline becomes bewildering since the empty search text is part of it. I suggest to have a different headline in that case. --Purodha Blissenbach (talk) 21:05, 6 September 2013 (CEST)

See T124769 --Purodha Blissenbach (talk) 13:13, 26 January 2016 (CET)

Done Done with Gerrit 267438 --Purodha Blissenbach (talk) 15:41, 30 January 2016 (CET)

Collection statistics error[edit]

Currently, the page

correctly lists that there were 13 English expressions in the collection but incorrectly pretends a 100% coverage for English. The page

correctly lists 4 expressions in the collection not having English translations. Likely, the computational base of the percentages is taken from the size of the biggest language subset, not from the size of the collection itself. --01:28, 13 October 2013 (CEST)

Done Done fixed with or one of its predecessors. --Purodha Blissenbach (talk) 13:10, 26 January 2016 (CET)

Invalid link in collection statistics pages[edit]

Both the pages

link to "Overview, expressions per language"

which yields a "not found" error. --Purodha Blissenbach (talk) 01:28, 13 October 2013 (CEST)

Done Done fixed with or one of its predecessors. --Purodha Blissenbach (talk) 13:10, 26 January 2016 (CET)

Installation does not honor database prefix[edit]

I am trying to set WikiLexicalData up from scratch not using the data base dump wich. It is simply too big for casual testing with the anticipated need to reload the database every now and then - quickly :-)

After having gone through the Installation of MediaWiki with only the extension WikiLexicalData added in LocalSettings.php, I tried to run php install.php --prefix=01_ --template=databaseTemplate.sql --datasetname="OmegaWiki community" and got an error message saying Table 'bli00_ow.01_language' doesn't exist. Inspecting the data base tables, I see lots op properly prefixed tables plus:

  • 01 (21)
  • language
  • language_names
  • wikidata_sets

I did no checks of the code yet. --Purodha Blissenbach (talk) 09:19, 16 October 2013 (CEST)

language, language_names and wikidata_sets are not supposed to be prefixed, because they are common to all dataset. So this is correct.
bli00.ow_01 is weird... Try with --prefix=01 , without the "_" which is added later in the code. I can imagine that a double __ can mess things around.
You are using mysql, or sqlite or something else ? --Kip (talk) 11:10, 16 October 2013 (CEST)
The prefix is 01_ indeed, the data base name is bli00_ow, using MySQL 5.1.66-0+squeeze1 - (Debian) - protocol version: 10 - UTF-8 Unicode (utf8)
Having unprefixed tables with the idea that they were the same for various prefixed data bases is imho a genuine design error. If I want to update one data base, I sincerely do not want another data base touched at all. So there must be no overlap.
--16:45, 18 October 2013 (CEST)

Unfortunately, there is no component "Extension:WikiLexicalData in MediaZilla. Should we request one? Basically, I would like to file a bug in a place visible to MediaWiki developers for this issue. One of the reasons is to possibly get feedback on the question how to solve the issue.

  • Having a central set of language definitions for several wikis may appear a legitimate wish.
  • Having the ability to have several wikis in a database that do not interfere with each other, is legitimate as well.

My suggested solution was to add an installation parameter allowing either. I am working on a fix like this. --Purodha Blissenbach (talk) 12:53, 27 October 2013 (CET)

  • Update
    A partial fix is working since a week. That is, WikilexicalData database tables are created and bootstrap data is inserted error-free. But now, database access after the installation phase is broken. The reason is likely that there are inconsistent uses of raw SQL and capsulated method calls, and prefixes are not consistently added. I am going to fix this, too, but it looks like a lot of work. --Purodha Blissenbach (talk) 10:02, 3 November 2013 (CET)

this is a copy from the International Beer Parlour

Bug 56220 - I managed to come to a partial fix, but was unable to further persue it last year. I found a bunch of more prefix-related problems once the in initial one had been fixed. --Purodha Blissenbach (talk) 20:11, 9 March 2014 (CET)
I think that if we follow Kip's suggestion here and used 01 instead of 01_, the problem might be solved. The point of the prefix is that multiple databases can be added. so ow_expression might be the main db, 01_expression is for your personal db, etal_expression can be for others. It is probable that the double underscore might be the problem here. So try using
01 which will produce 01_defined_meaning
instead of
01_ which might produce 01__defined_meaning ('note the double underscore)
Since I have not tested it, the program might produce the correct 01_defined_meaning, but wreck havoc on language. --向榮 /Hiong3-eng5/ (talk) 01:45, 10 March 2014 (CET)
Moving this diskussion to the Insect Room before it gets too off-topic... --Purodha Blissenbach (talk) 10:19, 10 March 2014 (CET)

A quick rundown of my analyses and testing results:

  • Underscores are not an issue.
  • There are three different places where to use prefixes:
    1. the entire wiki (often ignored by WikiLexicalData)
    2. WikiLexicalData's tables meant for many or all datasets
    3. WikiLexicalData's tables of a single data set.
  • WikiLexicalData currently (i.e. as of last November) uses a mix of database accesses which all need to, or do, individually deal with prefixes. A more systematic approach would be advisable, where prefixes are added only once, or at one place, respectively.
  • WikiLexicalData's tables meant for many or all datasets must use the prefix of the entire wiki, too.
  • Some parts of the data structures behind WikiLexicalData are unclear to me. I would like to see them properly documented (or find documentation and read it)

--Purodha Blissenbach (talk) 16:40, 10 March 2014 (CET)


I just want to be clear about some things.

  • In your partial fix, you are using the unprefixed language, language_names and wikidata_sets?
  • Can I have a copy of your LocalSettings.php, you can post it here or email it to me if its too long (especially important is the database settings). --向榮 /Hiong3-eng5/ (talk) 05:41, 11 March 2014 (CET)
As fas as I remember, I first gave every table the database prefix of the entire wiki. Then I may have given the three otherwise unprefixed WikiLexicalData (WLD) tables an additional extra prefix (so as to be able to have multiple sets of them in wiki farms), and finally fixed lots of data base accesses in WLD, which I likely could not complete.
Do you have a tools lab account? If so, I shall add you to the project (owintes) so that you can look at everything for yourself. If you do not have one, consider getting a tools lab account, its easy, and it may make things easier in the future. Alternatively, I could e-mail you the LocalSettings.php and put everything else into a branch and commit it. This would take a few days since it is untouched since November, and there is likely much stuff to be merged before I can commit.
--Purodha Blissenbach (talk) 13:21, 11 March 2014 (CET)
Sorry, I forgot, I was testing an installation process which did not work, So there is no LocalSettings.php proper. Yet I found some set-aside ones from failed installations. Since installing WLD/OW involves two steps - installing MediaWiki via the web, and running an installation script via a shell - they likely reflect only the outcome of step 1 plus maybe manual amendments which I do not recall by now.
--Purodha Blissenbach (talk) 14:20, 11 March 2014 (CET)
In my opinion, there is no need for language, language_names to have prefix. Since languages does not change, they should be used whatever database you are using. If you want to have this changed, I am unable to help you. If you check my contributions, if I am correct, all of it is not related to the OmegaWiki db structure and main program. They are mostly API related (And whatever spare time I have will be to improve the API). This is kinda outside my territory. If I may, I would suggest that the install be left as is for the moment, that is, non prefixed lang, langnames etc. Then work from there, familiarize with the code then discuss your suggestions to Kip, who will know more about this part of the code, and is the one who approves the WikiLexicalData commits. If he agrees with the changes you suggest, I may help in testing, depending on my spare time. I am really sorry for not being much help here. --向榮 /Hiong3-eng5/ (talk) 09:32, 12 March 2014 (CET)
There is an nondisputable need for those tables to have a prefix. When the entire wiki has one, these tables have to have that one, too. This is a requirement of MediaWiki that all extensions have honor. But giving the entire Wiki a database prefix is exactly what causes the WLD installation script to fail.
No problem if you cannot help, thank you all the way til here!. I can get along with these thing anyways, it only takes some time. :-) --Purodha Blissenbach (talk) 03:31, 13 March 2014 (CET)
Wait, since reviewing this thread, I think I misunderstood your point. Tell me if I understand correctly.
Example you want to have a wiki with the prefix test. So mediaWiki will create databases test_page, test_user etc.
Then you want to add the WikiLexicalData extension with the prefix lexical, so this should produce test_lexical_expression, test_lexical_text, test_language etc. But instead still creates lexical_expression, lexical_text, language etc.
Is this the design error that you speak of? --向榮 /Hiong3-eng5/ (talk) 05:35, 13 March 2014 (CET)
Purodha, are you working on this bug right now? I am thinking about helping here --向榮 /Hiong3-eng5/ (talk) 09:45, 14 March 2014 (CET)

The patch is outdated meanwhile. I am not working on the bug currently. The rest of the code still is likely inconsistent with the setup/installation script, which should be merged with the rest to be able to do automated database updates like all other decent MediaWiki Extensions do. That should be a bug on its own. Still there are lots open questions around the languages table which is not prefixed with a dataset prefix. I shall not and cannot work on the bug before I know what to do in this context. --Purodha Blissenbach (talk) 12:57, 26 January 2016 (CET)