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

From OmegaWiki
(Redirected from Insect room)
Jump to: navigation, search

The Insect room is intended to inform about bugs particular to the OmegaWiki software. It is not a place for feature requests (see Meta:Functionality wanted).

Solved bugs should be moved to the Insect room/Archive.

See also OmegaWiki related bugs at phabricator.

Nuvola apps chat.png
Start a new discussion
Discussion pages
Strategic discussions
International Beer Parlour

- archives

List of Beer Parlours

International Linguists Beer Parlour

- Inflexions

Questions about words
Articles needing attention
Insect room (report bugs)

- archives

Functionality wanted

- archives


First Definition/Expression NEEDS to be marked[edit]

There is currently no way to see which Expression and Definition that constitutes any given DefinedMeaning. IMO it is fundamental to have this information available since it is the only way to avoid semantic drift. Now with new DM:s being created in great quantities from all languages it is absolutely vital that this information is shown. --Sannab 20:06, 28 July 2006 (CEST)

This issue is not yet resolved. I think this should have a fairly high priority, to avoid future drift in definition translations. Siebrand 18:39, 18 October 2006 (CEST) Siebrand 15:11, 30 November 2006 (CET)
T10092] --Purodha Blissenbach (talk) 13:42, 26 January 2016 (CET)

Cannot link to a word[edit]

The word asilo pe bammine or Expression:asilo p''e bammine exists and it can be found as asilo_p%27%27e_bammine. It is one place where MediaWiki sucks. GerardM 22:49, 17 September 2006 (CEST)

It works this way: Expression:asilo p''e bammine. Zanatic 22:53, 17 September 2006 (CEST)
This means another workaround ... well: in some way I am gettin quite ... ehm ... better to shut up ... with workarounds for nap ;-) --Sabine 23:10, 17 September 2006 (CEST) Siebrand 15:17, 30 November 2006 (CET)

Done Done There is a UNICODE character printing the double apostrophe which needs to be used here. Please report a new bug if that is not a working solution. --Purodha Blissenbach (talk) 14:21, 26 January 2016 (CET)

Unclean deletions[edit]

It would be good if a developer could have a look at the case of Expression:ちっそ and DefinedMeaning:ちっそ (456162) First, user MovGP0 deleted the DM and the Expression and made the links red. But if you opened the links the database entry was still visible. I had to delete the definition entry and the syntrans entry by hand to make the entry disappear. For a clean deletion, it would be great if deleting a DM would delete all of its entries and relations and not just make the link to the page red.--Mkill 11:49, 4 March 2007 (EST)

Indeed, Bugzilla GerardM 03:16, 9 August 2007 (EDT)
Meanwhile T12853 --Purodha Blissenbach (talk) 13:30, 26 January 2016 (CET)

Red link to Meta:Policy[edit]

The deletion confirmation page (and probably several other pages) links to Project:Policy, which is redirected to Meta:Policy, but this page does not exists. Where is the policy? --Mkill 22:11, 14 February 2007 (EST)

Vocabulary trainer down[edit]

I have never been able to get the vocabulary trainer to work. After logging in it times out with the error message:

Fatal error: Call to a member function xpath() on a non-object in /var/www/ow/extensions/Wikidata/util/voctrain/collectionlist.php on line 19

McDutchie 05:30, 28 May 2009 (EDT)

Problem with Ugaritic script[edit]

Whenever I try to add a word in Ugaritic script, I got the following:

Une erreur de syntaxe de la requête dans la base de données est survenue. Ceci peut indiquer un bogue dans le logiciel. La dernière requête traitée par la base de données était :

    insert into page(page_namespace,page_title,page_is_new,page_touched) values(16, '𐎓𐎕', 1, 20100912221219)

depuis la fonction « ». MySQL a renvoyé l’erreur « 1062 : Duplicate entry '16' for key 2 (localhost) ».

--Kip 22:13, 12 September 2010 (UTC)

Note to myself, this is because of UTF-16 scripts not being supported by the current version of mySQL. There is a trick on the MediaWiki servers (binary instead of varchar), but I am not sure whether the change can be made without harming the data, or if it's just better to wait for a later version of MySQL that support utf-16. --Kip 23:37, 17 March 2012 (CET)

Duplicated definition and lost spellings of translations and synonymes[edit]

Yesterday, I created both definitions appearing on the page Expression:Dat sėn Jeschmakßaache, hät dä Buur jesaat, doh hätt e singe Koh der Aasch jebütz. at the moment, that is

The respective URLs are:

I see no difference between the two, thus imho, the 2nd on should not have been created, even though I knowingly made two tries. Experience with other pages showed up to now that saving the same data twice would not duplicate it, and that I could easily add different or even overlapping data from two browser windows to one page concurrently without duplcating something. No so this time.

Since I came from the page DefinedMeaning:Watt_dämm_Eijn_sing_Uhl_is_dämm_Andere_sing_Nachtijall._(1257659), where the above had been present already as an expression having "not identical meaning", I was wondering that its syntrans have "identical maning"s were not already automatically added to the new page with "not identical meaning", which I had expected, and which I had in mind having seen working this way before.

I believe, the problem is caused by the fact that software modified the original expression

from   Dat sėn Jeschmakßaache, hät_dä Buur jesaat, doh hätt_e singe Koh der Aasch jebütz.
to Dat sėn Jeschmakßaache, hät dä Buur jesaat, doh hätt e singe Koh der Aasch jebütz

on its way from a data base entry, through a link, through an URL, to a character string being searched in the database. Each of "_", "%20", and a space character are mapped to a space character. This poses no problem since the underscore ("_") is rarely used in written language. Unfortunaltely, I copied the above string from the ksh Wikipedia, where we use underscores to denote liaison, and some syllable borders, so as to enhance readability, and to be a bit closer to spoken language, which often greatly reduces ambiguities, since word flow and intonation quite strongly determine meaning - often you negate a sentence by just shifting stress and choosing another melody for it (c.f. Ferdinand Münch: Grammatik der ripuarisch-fränkischen Mundart. Cohen, Bonn 1904, Saendig Reprint, Wiesbanden 1970, ISBN 3-500-21670-6 eg.), so the unmarked written form is highly ambiguous without context.

We do not have to use "_", and it usually does not appear inside words anyways, so it is nothing to really worry about for the relational data in OmegaWiki. I shall leave these things as they are for a while just in case someone want to investigate. I shall later, in a week or so, try to fix the whole thing, and only be back here if I do not succeed. However, I would also like to recommend to fix software so as to avoid such duplicates in the future. Ok, this may be low priority issue, and may be already on someones list, else I may dig deeper into how it exactly happened, and what could be done about it. --Purodha Blissenbach 10:46, 27 September 2010 (UTC)

Language selection[edit]

My default language is set to English. I search for word "hala" which is a word in Turkish but does not have a counterpart in English (it means "sister of father"). I get a page with "Language:Rohingya" where only the word "black" is defined. Only when I click on the down-arrow next to Rohingya and select Turkish do I get the English definition of "hala". There is not even an "English" selection under Rohingya to see the English definition of the word. --InfoCan 19:40, 17 March 2012 (CET)

Oh I see, a feature, not a bug. [1] --InfoCan 23:04, 17 March 2012 (CET)
...yes, a recent feature. It is much better in terms of server response time, and avoiding too much scrolling.
However, I am aware that it is maybe not so obvious or intuitive for new users. If you have an idea to improve it, that'd be nice. I guess that the main problem you had is that you added a word in Turkish, and it did not show up when you saved? So maybe the page should automatically switch to the new language when a language is added (not sure how to do that with regard to the current php code). --Kip 23:31, 17 March 2012 (CET)
Maybe you could use tabs for each language, displayed horizontally (something like the Monobook skin tabs), instead of a combo/dropdown box. At least, it would be more visible that you can select the desired language. Malafaya 01:46, 25 March 2012 (CET)
good idea, I'll see how that can be implemented. --Kip 10:06, 25 March 2012 (CEST)
If there are translations in many languages, it may not be practical either. It seems the best solution is to be able to set in your Preferences which languages you want displayed for 1) interface language choices, 2) translations for a DM, 3) SyntTranses. Presumably most people would choose less than 10 languages they will ever be interested in. These then can be displayed without encumbering the user, overloading the server and slowing the display of information. Malafaya's suggestion above would work as well. --InfoCan 16:44, 25 March 2012 (CEST)

On a related subject (again, not a bug but a feature request), I think when the DefinedMeanings in a particular language are displayed, the regional variations of it should be displayed on the same page as well. Most users would not think about changing the language from "English" to "English-USA" to find additional entries, for example. --InfoCan 16:56, 25 March 2012 (CEST)

The regional variations will be changed to annotations, i.e. "English-USA" and "English-UK" will be merged to "English", and an annotation will be used to indicate that the word in used in US or UK (or Australia, or southern-US, or anywhere else). But before doing that, I need to make the annotations more visible. --Kip 17:35, 25 March 2012 (CEST)
I think this might have serious implications, so we should think seriously before taking such a decision. The ISO 639-6 standard lists languages variants within a single code, while RFC 5646 use a composite approach using subtags: Primary Language Subtag, Extended Language Subtag, Script Subtag, Region Subtag, Variant Subtag, Extension Subtag and Private Use Subtag. The RFC 5646 approach seems intellectually more beautiful, more promising, easier to manage by a program, and more like Omegawiki, but is also more dangerous: one can easily "define" purely artificial combinations, like "Cuneiform polytonic English"; secondly, at the opposite, some really existing variants could be referenced several ways. For instance, there are variants inside the the Mongolian-Uighur script, and they have not been standardised by the IANA yet. Another example is that, also the same "Cyrl" (Cyrillic) is used for several languages (Bulgarian, Belarussian, Mongolian etc) their alphabet is not exactly the same (For instance, Mongolians added 2 letters to the Russian Cyrillic), while the composite code seems to imply the alphabet would be the same. At the opposite, ISO 639-6 lists only real languages, and tries to register all (though, for the moment, ancient languages are badly registered). The IETF language tags uses both the composite tag system of RFC 5646 and a registration by IANA. But I suspect the IANA to be even less interested by ancient languages than the ISO. Maybe a way to deal with this would be to put language variations in annotations as you propose, like IETF, creating as many annotations as RFC 5646 tags, but using the private tags when necessary for ancient languages. For instance, it is not reasonable to have a single "grc" language for "ancient Greek", as if Homer in the 8th century before Christ and Bizantine emperor Constantine XI Palaiologos in the 15th century used the same language. These extra annotations would solve several problems, like writing or not accents and breathes on Greek words (IANA has a "polytonic" tag for this). It's important that variants of a given expression be registered as such, not only as different expressions of one definedMeaning. For instance, it's not enough that "dishonour" (British English), "dishonor" (American English) and "disgrace" (English) be registered as expressions of the same definedMeaning: it should also be registered that "dishonour" and "dishonor" are variations of the same expression, which is, so far, not done. Another thing to think of is that a few words may have regional variations without requiring to register a language variant for that. Example: " chocolatine" in Southern France and "pain au chocolat" in Northern France, though there is no such a thing as "Southern France French". So I suggest only registered combinations of Primary Language Subtag (i.e. annotation), Extended Language Subtag, Script Subtag, variant Subtag, Extension Subtag and Private Use Subtag be allowed, but the use of the regional subtag be freeer. 15:01, 26 November 2012 (CET)

No word class in several languages, no gender in several languages needing them[edit]

If I define a word in languages "English (United Kingdom)", "English (United States)", "French (Switzerland)", "Middle French" or "Breton", there is no "part of speech" in "Annotation". It's safe to consider that word classes in "English (United Kingdom)" and "English (United States)" are the same as in "English", and that, as far as our, very rough, level level of precision is concerned, that the word classes of "Middle French" are the same as for "French". As far as Breton is concerned, I don't know, but I'm sure there are at least nouns. Moreover, in middle French and Breton there should be genders: masculine and feminine. 15:03, 26 November 2012 (CET)

The possible annotations need to be defined. You need to have admin privileges to do so. Currently, only one annotation of the type you need can possibly be defined anyways, see #Cannot add class attributes option values. So, annotatins are mostly broken. --Purodha Blissenbach (talk) 13:18, 26 January 2016 (CET)

Word of the day is broken[edit]

The word of the day template seems broken. (talk) 06:02, 29 August 2013 (CEST)

It is not broken, but rather there is no word of the day, because nobody put any. I don't have the time for this anymore. --Kip (talk) 17:29, 6 September 2013 (CEST)
Would you have time to write a small function picking randomly a word of the day from definedMeanings with translations in at least 10 languages and definitions in at least 5 languages, for instance? (talk) 03:39, 7 September 2013 (CEST)
No I am not sure how to do that easily (i.e. quickly) --Kip (talk) 15:25, 7 September 2013 (CEST)
And what about a function just picking a definedMeaning at random? After all, if the information is poor, it my incite users to improve it. (talk) 02:10, 8 September 2013 (CEST)
The problem is not selecting the DMs, but rather writing in the templates, one template for each day, with the correct format.
Also, anybody could do it, not just me (no need for admin rights or developer access).
PS: please note that almost nobody edited the WOTD anyway, which is why I don't want to invest more time than necessary in it. --Kip (talk) 15:24, 8 September 2013 (CEST)
OK. Thank you for the time you spent on this during many years. So what about just deleting the "World of the day" from the homepage? (talk) 16:00, 8 September 2013 (CEST)
Hmmmm ... have to look into this - for "marketing reasons" it is fairly relevant to have one. Years ago I started this "feature". --Sabine (talk) 17:24, 20 September 2013 (CEST)

Questions about tables 'language' and 'language names'[edit]

This is not a bug but rather a set of wannabe deveolopers questions possibly to be subsummed under the heading understanding the code.

  • Why is there a field iso639_2 in table language ?
  • How are languages dealt with that have two distinct ISO-639-2 codes assigned to them?
  • Why is the field iso639_2 in table language initialized with an ISO-639-1 language code en in the function createLanguageEnglish() in file $IP.'/extension/WikiLexicaldata/Console/install.php' ?
  • What are tables language, and language names used for in the light of the thought that, after bootstrapping, a class or collection such as "language(s) allowed for WikiLexicalData expression/translation/defnition entries" should be serving the same purpose more flexibly, independent of ISO-639 restrictions?

--Purodha Blissenbach (talk) 14:58, 27 October 2013 (CET)

Redirects to Expression pages[edit]

Expression pages lack the "redirected from …" hint at their tops when shown as a result of a redirect. This behaviour is inconsistend with other wiki pages. I did not check Definition pages yet. -- Purodha Blissenbach (talk) 13:50, 3 December 2013 (CET)

Bug 62489 --Purodha Blissenbach (talk) 19:13, 3 May 2014 (CEST)
Patch uploaded: gerrit:251683 --Purodha Blissenbach (talk) 04:10, 7 November 2015 (CET)

Specific page edits seem to crash Wiki[edit]

There are some pages that cannot be edited, since their edit links yield an empty page, which is usually an indication that the php program powering OmegaWiki crashed.

There are likely several more of that kind in the Portal namespace. -- Purodha Blissenbach (talk) 18:32, 3 December 2013 (CET)

Exchanging the source id of a collection in a DM page is not working as expected.[edit]

There is a wrong collection source id store for a DM. I open the DM page in edit mode, open the collection section, checkmark the wrong entry for deletion and add another entry with the same collection name and the new id. As a result of the edit, the DM is not member of the collection any more. This behaviour is counterintuitive, and different from syntrans, where you can delete and add syntrans's for the same language within one edit process. Purodha Blissenbach (talk) 20:47, 8 January 2014 (CET)

See T124768] --Purodha Blissenbach (talk) 12:48, 26 January 2016 (CET)

Thumbnail generation error.[edit]

In the International Beer Parlour, an error message is shown instead of the icon in the beginning of the page.
> Error creating thumbnail: Unable to save thumbnail to destination
> Start a new discussion
--Purodha Blissenbach (talk) 12:10, 12 April 2014 (CEST)

Done Done Solved, it was a problem of permissions that were not correct after the MW upgrade. (and then a problem of cache). --Kip (talk) 18:59, 12 April 2014 (CEST)

Attribute cannot be set.[edit]

When I enter the attribute "usage=euphemistic" for a German noun, that is now changed to "usage=inoffensive" while it is being saved. "usage=inoffensive" is not even a choice offered to be selected when entering attributes and it is apparently wrong. What can I do to retain the correct attribute value?

By the way: Why are attributes for German not shown in the German language? --Purodha Blissenbach (talk) 11:49, 1 May 2014 (CEST)

It was a problem of wrong translations at Expression:euphemistic. The system takes whatever translation is available, and (for some unknown reason, but it has been like this for a long time) does not take the same translation in the dropdown list and when displaying the saved attribute.
I removed two wrong translations, it should now be ok.
Attributes for German or any other language (Latin, Chinese, etc.) are shown in your user interface language (or by default in English if no translation is available). I don't know what user interface you use. I use French and see all attributes in French. This is like this since the beginning of times. --Kip (talk) 16:21, 1 May 2014 (CEST)
Bug 64781 --Purodha Blissenbach (talk) 15:56, 3 May 2014 (CEST)
I agree that this could be confusing. But I am way behind my schedule with the prefixed database bug, the DfM 2014 update, web API and the Min Nan language data too. If I find time for this, I would help, you may commit a bug fix though. --向榮 /Hiong3-eng5/ (talk) 06:52, 5 May 2014 (CEST)
By the way, attributes are definitely not shown in my user interface language but in English - always, even if a translation is available. --Purodha Blissenbach (talk) 23:55, 4 May 2014 (CEST)
Kip, remember my gerrit patch NS DefinedMeaning Title defaults to DM id - expression? Re:My @todo comment, I think there was a problem with defaulting to a language preference there. I forgot what but there are two records of the language code. In Min Nan for example, the code on one preference is nan, and on another, it is zh-min-nan. The current API function retrieves one (again I forgot which one) which is not seen in the language table, and so defaults to English. So German may also have this issue with Ger and Deu, I guess. --向榮 /Hiong3-eng5/ (talk) 06:52, 5 May 2014 (CEST)

Broken image symbol on each OW page[edit]

In the lower right edge of each page, there is a "broken image" image being shown by Opera which is linked to --Purodha Blissenbach (talk) 11:51, 1 May 2014 (CEST)

Fixed, the image was lost during the last MediaWiki upgrade. --Kip (talk) 16:25, 1 May 2014 (CEST)

Done Done

Missing attribute[edit]

In English expressions, the "grammatical gender" attribute is gone to the hays. --Purodha Blissenbach (talk) 16:05, 3 May 2014 (CEST)

Language statistics pages use wrong base to compute percentages.[edit]

See, for instance, the language statisics of expressions - it says in its beginning, we had roughly 494,600 expressions but only about 49,800 English ones, which is pretty easy to believe, or even to trust. That is, 10% of our expressions are English expressions. Yet, the bar diagram gives us 100% next to the English bar. That is incorrect and bewildering.

Since all other percent figures apparently use the Engilsh=100%, they are all wrong as well. -- Purodha Blissenbach (talk) 09:23, 11 May 2014 (CEST)

I prepared a patch. Looked easy - Shall try to upload it to Gerrit tomorrow. -- Purodha Blissenbach (talk) 02:44, 12 May 2014 (CEST)
As I am used to meanwhile, it took me ages of unsuccessful tries with git to get anywhwew. Now, it looks like I have the newest version pulled, which seem to be necessary so as to commit somthing new, but it did not automaticall merge. I think, it should and this is the end of my wisdom.
Here is the conflicting data:
                                // find the defined meaning record
                                $qry = "SELECT dm.meaning_text_tcid, exp.spelling ";
<<<<<<< HEAD
                                $qry .= "FROM {$dc}defined_meaning dm INNER JOIN {$dc}expression exp ON dm.expression_id=exp.expression_id ";
                                $qry .= "FROM {$wgDBprefix}{$dc}_defined_meaning dm INNER JOIN {$wgDBprefix}{$dc}_expression exp ON dm.expression_id=exp.expression_id ";
>>>>>>> e39581e91aa026a1ec944a107fe02bf86011d364
                                $qry .= "WHERE dm.defined_meaning_id=$dmid ";
                                $qry .= "AND " . getLatestTransactionRestriction( 'dm' );
                                $qry .= "AND " . getLatestTransactionRestriction( 'exp' );
I have no idea what the correct piece of code could be here meanwhile, and how to tell git about it. --Purodha Blissenbach (talk) 03:54, 17 May 2014 (CEST)

You need to delete the older portion. Conflicting data are inside
So if you have...
This is my
You must delete the old one and the label as well, producing ...
This is my
So in your case should be...
// find the defined meaning record
$qry = "SELECT dm.meaning_text_tcid, exp.spelling ";
$qry .= "FROM {$wgDBprefix}{$dc}_defined_meaning dm INNER JOIN {$wgDBprefix}{$dc}_expression exp ON dm.expression_id=exp.expression_id ";
$qry .= "WHERE dm.defined_meaning_id=$dmid ";
$qry .= "AND " . getLatestTransactionRestriction( 'dm' );
$qry .= "AND " . getLatestTransactionRestriction( 'exp' );
--向榮 /Hiong3-eng5/ (talk) 00:21, 18 May 2014 (CEST)
Done Done. Thank you.
I know how to solve conflicts in general. I did not know how to decide which solution to choose in this case, and why there was a conflict at all in the first place. --Purodha Blissenbach (talk) 15:04, 18 May 2014 (CEST)
  • Cannot upload the changes anyways. Back to git not working in the way expected, like the last time:
$ git pull
Already up-to-date.
$ git commit -a
# On branch review/purodha/bugfix-65456
# Your branch is ahead of 'origin/master' by 1 commit.
nothing to commit (working directory clean)
$ git push
To ssh://
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'ssh://'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.
That repeats itself ad nauseam. There is nothing in the help that woul help, or even explain, why the push is rejected. I could use git push --force but I do not dare, since I do not believe that I am the only one committing to the repository. --Purodha Blissenbach (talk) 17:16, 18 May 2014 (CEST)
Now I also tried a fresh checkout on another system, of both mediawiki and all extensions following the page. Then I repeated my changes in a fresh branch, still following the tutorial page, gerrit rejects my uploads. Error messages vary greatly depending from which directory I try the submit. I do not have more time to waste. I think I am giving up the idea to participate in the development of this project. :-( --Purodha Blissenbach (talk)
My untested suggested changes can be found at bug 65456. I'm not working on it any more. --Purodha Blissenbach (talk) 02:07, 19 May 2014 (CEST)
I am not sure I understand, why use git push and not git review? If I am correct, only Kip can use push on wld (along with the Translatewiki people and former maintainers). --向榮 /Hiong3-eng5/ (talk) 22:21, 19 May 2014 (CEST)
Neither worked.

I have submitted my patch as part of Gerrit:246232 now. --Purodha Blissenbach (talk) 16:43, 14 October 2015 (CEST)

Done Done

Cannot edit page[edit]

Cant edit page whatever I try to add or change, it is lost once I hit the submit button. Now the page is in a dire intermediate state. :-( -- Purodha Blissenbach (talk) 21:58, 1 August 2015 (CEST)

Done Done

Edits are not stored[edit]

Again, my edits are lost once I hit the submit button. Now;action=edit and various other pages do not work. --Purodha Blissenbach (talk) 23:19, 28 October 2015 (CET)

Indeed, it also does not work for me.
The server has recently been updated with the latest code.
This had not been done in some time. And once again, I see that people who actually don't use or test OmegaWiki have made changes that break. For example this change [2]: There are probably others bugs. Please wait a bit until I fix them. --Kip (talk) 18:08, 30 October 2015 (CET)
See also Meta:International Beer Parlour#Hacking OmegaWiki, current last item of the list: "The [save] button does nothing&amp;nbsp;&amp;hellip;" - possibly I encountered the same problem in my test. I used the latest versions of core and everything else from git. I was not yet able to trace the problem. --Purodha Blissenbach (talk) 20:13, 30 October 2015 (CET)
One problem was the history, identified on my link above, the other problem with save was an issue in suggest.js introduced here [3] , although it was not really expected that changing a != null to !== null would create this bug (and I still don't see the point of !== actually when != works fine).
Yes probably your problem in your test is the same. --Kip (talk) 21:46, 30 October 2015 (CET)
The != vs !== is a mediawiki coding standard of sorts. Values compared should be the same type. So a string '5' is not equal to numeric 5. Probably a security measure of some sorts, I don't know. --向榮 /Hiong3-eng5/ (talk) 02:19, 31 October 2015 (CET)
And since it is a javascript problem, you might need to refresh the cache of your browser (under chrome I use Ctrl + Shift + F5). --Kip (talk) 21:48, 30 October 2015 (CET)
I updated my test to your latest commits, and the problem is solved there, too. Thank you a lot! --Purodha Blissenbach (talk) 10:54, 31 October 2015 (CET)

Done Done

Moving Expression page kills wiki script.[edit]

See: --Purodha Blissenbach (talk) 11:07, 1 November 2015 (CET)

Personally, since all expressions may contain multiple DefinedMeanings and or language, I think expressions should not be moved. That this function should be disabled rather than created, I think I know how to disable the move function. But I am curious, what do you expect a moved expression do? If you agree with me, I think I can disable it, what do you think? --向榮 /Hiong3-eng5/ (talk) 17:20, 3 November 2015 (CET)
Yes, I think moving to/from/within namespaces representing relational data should be disallowed. --Purodha Blissenbach (talk) 18:36, 3 November 2015 (CET)
Check this out . --向榮 /Hiong3-eng5/ (talk) 03:27, 4 November 2015 (CET)
Looks good. Questions:
  1. I do not see how this gracefully stops move request from hand made URLs.
  2. Does this also stop moves to the OW namespaces?
  3. If pages in the OW name spaces are declared immovable, how is this done? Maybe, in Localsettings.php? If so, it is not documented, and that is why I did not have it included in my test.
  4. What exactly do I need to do to download the patch from gerrit in a way that I would be able to upload amendments, if need be, without interfering with my test branch? Last time, I tried something like that, I lost my test branch, and I was unable to upload an altered patch as well. :-(
Sorry for my stupidity. I still do not really understand enough of gerrit and its git commands. --Purodha Blissenbach (talk) 10:04, 4 November 2015 (CET)
point 1. The mediawiki software plus the WLD hooks will just say point out that the namespaces can not be moved. Point 2, No. This is not addressed. Point 3. In Wikidata.hooks.php via the public static function onNamespaceIsMovable, setting $result to false (meaning, the namespaces pointed here are not movable). Point 4. I do not know how to answer that. Your test branch setup is still unclear to me. Sorry. -- 向榮 /Hiong3-eng5/ (talk) 11:25, 4 November 2015 (CET)
I have just submitted this link, , that solved point 2. --向榮 /Hiong3-eng5/ (talk) 06:22, 5 November 2015 (CET)
point 4 : you need to use the commands "git branches" and "git checkout"
when you are in you own test, do first a "git branches", it will show all branches that are available (locally), with an asterix * in front on the one you are currently in (probably "master"?).
To test an amendment, you need to do "git review -d 251197" (if the url for the change is, as explained here [4] git review -d includes a checkout, so that a git checkout is not needed.
The files will all be modified so that you will think that you lost your changes if you look at the files.
you need to do a "git checkout ..." (the name of your previous branch) to go back to your test branch. With "git checkout" you can switch between your different branches at any time (it is not a checkout in the usual svn sense that downloads something fresh, it is just actually a switch between branches). It is recommended to do "git branches" from time to time to verify on which branch you are currently working. Also before commiting a change to be sure that it will be attached to the correct change. You can also do a bit of "git status", that can give some useful information.
Hope this helps. Personally I don't like git very much, I get easily confused as well. --Kip (talk) 01:04, 6 November 2015 (CET)
  • Thank you, Kip, that helped. I only have to commit the changes I made in my test, before I am allowed to switch branches, and I must be aware that I do not have to submit them and that I have to always use "commit --amend" ever after the first commit in a branch. Thank you. --Purodha Blissenbach (talk) 07:54, 6 November 2015 (CET)

@向榮 /Hiong3-eng5/ - I tried the combination of the patches from gerrit in my test at and they do not fix the problems 1 to 3. Maybe I am still missing the declaration as immovable somewhere. I was able to move from / to Expression and DefinedMeaning name spaces, see:
For instance:
is now a redirect to:
which itself became a redirect to:
etc. --Purodha Blissenbach (talk) 10:42, 6 November 2015 (CET)

Actually, if you use get pull, you will get the latest WLD software as committed by Kip. 1 has been solved there. But as I've said, I do not know your setup there. --向榮 /Hiong3-eng5/ (talk) 11:33, 6 November 2015 (CET)
If my patches were both used, then point 3 is already set, you do not need to change it, Wikidata.hooks.php is considered part of the software. Configurations files are LocalSettings.php and LocalApp.php (the latter, only if created/used). Maybe Kip can help you regarding this one, I don't have access or an account at tools.wmflabs and have no idea how to use that. --向榮 /Hiong3-eng5/ (talk) 11:46, 6 November 2015 (CET)

Sure, I used git pull so as to get the newest base from gerrit, then I used git fetch ssh:// refs/changes/97/251197/3 && git checkout FETCH_HEAD (which I copied&pasted from so as to get the new patch hat kip did not merge yet. Then I inspected the code and verified that I really got what I wanted. I specifically looked inside Wikidata.hooks.php<code> for it. Then I played around and got the results mentioned above.

Did you test your patch? If that was successful, then there must be some other difference which makes it work that I do not have in my test. There is no <code>LocalApp.php in my test anywhere. Of course, I did create a file LocalSettings.php so as to make the whole thing work. If this is the place to specify immovable name spaces, it is not done, since it is not mentioned in which I followed when installing WikiLexicalData for the test. --Purodha Blissenbach (talk) 14:58, 6 November 2015 (CET)

There is also no LocalApp.php on the current server. Everything is in App.php. --Kip (talk) 16:53, 8 November 2015 (CET)

My re test[edit]

Yes, I actually tested my patch before submitting it for review. But to check your method.

  • I also copy pasted from using my ssh version.
  • I then used git checkout -b tryFetched, to create a new branch for the fetched patch.
  • Checked if I am in the tryFetched patch, using git branch. (saw the * before tryFetched, good.
  • Tried to move my MovePage page to Expression:MovePage. Got the response below
You do not have permission to move this page, for the following reasons:
  • No pages can be moved to any namespaces handled by the WikiLexicalData extension.
  • A page of that name already exists, or the name you have chosen is not valid. Please choose another name.
    • (The page was create from my original test)
  • Tried to move Expression:trafic ferroviaire to trafic ferroviaire. Got the response below.
You do not have permission to move this page, for the following reason:
Pages in namespaces handled by the WikiLexicalData extension cannot be moved.
  • Tried to move Expression:trafic ferroviaire to DefinedMeaning:trafic ferroviaire for good measure. Got the same response above.

So yes, I had tested it the patch before I submitted it for review. And have re-tested the patch, now to leave out any doubt in my mind that the patch did the work it suppose to do. So I have no idea why it did not work in the lab version. --向榮 /Hiong3-eng5/ (talk) 02:09, 7 November 2015 (CET)

Hm, strange. I shall inveestigate. Maybe, there needs to be a "Pages in these NS are immovable" somewhere, which I missed, misspelled, or something. Tomorrow :-) --Purodha Blissenbach (talk) 04:26, 7 November 2015 (CET)
Did you define the $wdHandlerClasses array in your LocalSettings.php ? See [5] (maybe we should move that part to App.php ?). --Kip (talk) 17:01, 8 November 2015 (CET)
Yes, there is:
170 $wdHandlerPath = "$IP/extensions/WikiLexicalData/OmegaWiki/";
171 $wdHandlerClasses = array(
172         24 => 'DefinedMeaning',
173         16 => 'OmegaWiki',
174 )
I think I copied it from --Purodha Blissenbach (talk) 17:10, 8 November 2015 (CET)
Missing a ";" in the last line? Otherwise it's fine. --Kip (talk) 23:33, 8 November 2015 (CET)
There is a semicolon in the following line. --Purodha Blissenbach (talk) 23:45, 8 November 2015 (CET)

Red links to existing DMs in normal wiki pages[edit]

Definedmeaning page names are structured "DefinedMeaning:expression_(ID)" where ID is a positive integer numeric id that must be matched in the database (else the page name is erroneous) and the expression part is an arbitrary string which will be replaced by a canonical one via an URL redirect when a page of an existing DM is rendered.

Links and redirects to DM pages are red links when expression does not match the canonical expression for the ID. That means, when following the link, you get the right page but it is in edit mode. Both the red links and the edit modes are undesirable.

Also reported as phabricator:T118066 --Purodha Blissenbach (talk) 04:16, 7 November 2015 (CET)

I've updated the software, and found out that the valid DefinedMeaning:5685 is still redlinked. see User:Hiong3.eng5/dm redlinks. -- 向榮 /Hiong3-eng5/ (talk) 09:29, 28 November 2015 (CET)

A normal wiki page redirecting to a missing expression does not redirect[edit]

A redirect to an expression should either show the expression (which works) or show an edit/create page for the expression, if it does not exist (which is not working at the moment) The redirect page itself is rendered instead.

Also at phabricator:T118071 --Purodha Blissenbach (talk) 09:16, 7 November 2015 (CET)

Notice: Undefined offset: X in /var/www/ow/extensions/WikiLexicalData/OmegaWiki/OmegaWikiRecordSets.php on line 232[edit] emits a series of PHP notices about varying undefined offsets.

See T121972] --Purodha Blissenbach (talk) 12:21, 19 December 2015 (CET) does it, too, once, the offset is 1144365. --Purodha Blissenbach (talk) 15:09, 26 December 2015 (CET) and do it, too with the same offset. --Purodha Blissenbach (talk) 17:58, 26 December 2015 (CET)


There are various similar places and error messages. They have in common that a name for a language is not shown (empty) somewhere in the page displayed, or that a name is generally not shown but the data used internally are the same as in the cases mentioned before. The routine collecting names for languages from the data set in the data base for the dataset independent "languages" table must be buggy and there are circumstances making it not find, or store, a name. There are lookups that let us know that there are unassigned language numbers. Thus it is likely that missing names yield missing numbers in the "languages" table, and preexisting values are dropped. Yet existing language numbers in the dataset remain, causing the missing index errors. --Purodha Blissenbach (talk) 12:40, 26 January 2016 (CET)

File names generated by Special:ExportTSV should reflect data downloaded[edit]

Whatever the Collection, Class or Theme selected in , the download file name always starts with "destit" (like "destination Italy", a sample preset)

Better use the actual selection.

See also: T122298.

--Purodha Blissenbach (talk) 15:04, 23 December 2015 (CET)

Cannot add class attributes option values.[edit]

When adding option values to ▼ Class attributes - Level=SynTrans - Attribute=word class - Type=Options - - List of options ▼ of an arbitrary language, only one value (the first new one) or no value at all is saved. The choice seems arbitrary. -- Purodha Blissenbach (talk) 17:50, 25 December 2015 (CET)

Wrong interface language in AJAX popup[edit]

About an hour after switching the interface language for the session of a logged-in user, the drop down list of languages has a heading in the previous language (Colognian) while everything else correctly shows the new language (German). See attached screen shot. This may be a caching issue.

See Screenshot

See T122435

--Purodha Blissenbach (talk) 18:03, 25 December 2015 (CET)

API gives wrong error message[edit]

When trying to add DMs to collections, the API complains <result1 WARNING="Non existent language id(1601607)."/> although a language is not involved. Likely, the message should say "non existent collection". --Purodha Blissenbach (talk) 18:18, 25 January 2016 (CET)

See T124764

API must accept non-numeric member IDs for classes[edit]

When trying to add DMs to collections, the API is documented to accept only numeric member IDs and so it does. Otherwise, it complains. But that is not justified, since many collections, such as the ISO-xyzzy classes, have alphanumeric IDs. --Purodha Blissenbach (talk) 18:18, 25 January 2016 (CET)

See T124765

Collection creation needs to offer a list to pick from if there are multiple matches for the name entered.[edit]

Currently, it just takes the first element of the list, according to Meta:International_Beer_Parlour#Collection_requests --Purodha Blissenbach (talk) 16:33, 27 January 2016 (CET)

See T124907

Code inspection reveals that there needs to be no expression nor a DM for the collection before it created, but is an expression exists, an arbitrary one of them and an arbitrary DM connected to it s picked. I do not understand why the latter is as is is. Likely, collection creation is meant to only happen for non-existing expressions in the first place. Likely, most of the code needs to be rewritten. Too much for a quick fix, imho. --Purodha Blissenbach (talk) 21:06, 30 January 2016 (CET)