Extension talk:Page Forms

Adding a list of existing pages names and link into a form results page
Hi Yaron, Hi All,

I want to insert an autocompletion search field into a form to let the users search for existing pages and who "tokenizes" the page name in the field.

In the results page, I should be able to display the name of the pages that have been tokenized in the form. Each page name has a link to its page.

In other words, this functionality will link a page to others.

Any idea how to do that ?

Thanks for your great support.

BR,


 * I don't really understand the point of this, but it sounds like you could do it with Special:RunQuery, where the template would not call a query but instead just display links to all the pages, using #arraymap. The form would presumably use the "tokens" input type. Yaron Koren (talk) 14:02, 24 September 2015 (UTC)

Inserting a simple popup (modal) in a form
Hello there,

I would like to insert a popup (like a Bootstrap modal) into a form.

Do you know how I can do that ?

I know how to insert a Tooltip and to Enhancing query forms. But I didn't find anything about inserting a simple popup with simple text in it without using HTML.

Thanks a lot


 * What about a tooltip instead? For that you could use #info, if you have Semantic MediaWiki installed, or if not you could use the SimpleTooltip extension. Yaron Koren (talk) 16:50, 15 September 2015 (UTC)


 * Hi Yaron, a tooltip is to small for all the content that I want to insert in the popup (image + text) plus, it doesn't fit well in my webdesign. :( is there a way to insert a boostrap modal ? I use Chameleon skin by the way. Thanks.


 * I fixed the problem. To anyone that might be interested : I used [|this shortcode of Chameleon] and I remplaced the that is not interpreted by mediawiki by a simple div.

Horizontal code output from form?
Hello Does anyone know whether its possible to force a form to create horizontal code eg.

instead of

I don't want this on every form, so im not looking for a global setting. any ideas?


 * I don't think it's possible, unfortunately. Yaron Koren (talk) 18:14, 1 September 2015 (UTC)

Save And Continue breaks multi instance forms with divs
Just a heads up, though this might be a bit specific... I have a form with multiple instances. Additional fields appear/disappear depending on your choice from a dropdown. Pressing save and continue and then changing your choice from the dropdown will load the fields as it should, but they're greyed out and not editable until you reload the page. SMW 1.6.2, SF 2.2.1

Automatic page creation "broken" with SMW's
On our wiki pages get created automatically with SMW's  (previously called  ) and. We use the ExternalData extension to load customer data into the wiki. When a customer is new the page will then be created automatically. This worked fine but stopped working in SMW 1.9.2. In this release the move was made from  to. I tested this on MW 1.23.9 and different SF versions, 2.8 and master.

Testing this in my home wiki (MW 1.24.1, SMW dev-master and SF 3.3.1) the same thing happens. Example with a property page called Property:Testname with the following content:
 * Has type:Has type::Page
 * Creates pages with form::Testcaseautofill

Test pages

 * Testname::Testcase1
 * Testname::Testcase2
 * Testname::Testcase3
 * Testname::Testcase4

After saving the page and running  the 4 pages get created automatically.

When I then delete Testcase1 and rebuild with: php rebuildData.php --no-cache -v and php runJobs.php The page Testcase1 does not get created. The property Testname actually has the value Testcase1 but with a red link. Even when I use the Data repair and upgrade function and run  the page Testcase1 does not get created.

I am pretty sure that  added pages to be created to the MW job Que which you could then "empty" by using. I am not sure why this is not working any more. It seems that SMW's  is "ignoring"   or SF as a whole or SF is not doing its "job".

Because of this "problem" it is not possible any more to get pages to be created automatically. The only way to do this in the example above is to refresh the Property:Testname page and run. I already reported this on GitHub (half way the discussion) because I noticed this behaviour during testing. It would be a shame when this "functionality" is lost. Is this something that can be fixed in SF or in SMW or both? Regards, --Felipe (talk) 12:27, 3 September 2015 (UTC)


 * The discussion on GitHub has progressed. Yaron, when time permits could you have a look at the comment from MWJames on GitHub? Is this part of a possible "solution" for the problem discussed here, if so is it something that can "easily" be achieved with SF? Thanks, and regards. --Felipe (talk) 12:26, 4 September 2015 (UTC)


 * Actually, I'm planning to replace the "Creates pages with form" special property with a parser function, like was done with "Has default form" and "Has alternate form". That will remove the SMW-related issues, and will enable Cargo support as well. I'll try to get to that soon. Yaron Koren (talk) 13:34, 4 September 2015 (UTC)


 * OK, thanks. --Felipe (talk) 14:30, 4 September 2015 (UTC)

I think I found a bug during testing. On a Property page (but it can be any page) when you use:

heading

 * Testname::Testcase1

When you save the page and Testcase1 does not exist the page gets saved but on your screen you get: [03b02c65] /mediawiki/index.php/Property:Testname MWException from line 86 of /var/www/html/mediawiki/includes/parser/ParserOutput.php: Bad parser output text. Backtrace: SMW's  also won't run BUT When you don't have the heading: or there is no heading before  like:
 * 1) 0 [internal function]: ParserOutput->{closure}(array)
 * 2) 1 /var/www/html/mediawiki/includes/parser/ParserOutput.php(97): preg_replace_callback(string, Closure, string)
 * 3) 2 /var/www/html/mediawiki/includes/OutputPage.php(1854): ParserOutput->getText
 * 4) 3 /var/www/html/mediawiki/includes/OutputPage.php(1873): OutputPage->addParserOutputText(ParserOutput)
 * 5) 4 /var/www/html/mediawiki/includes/page/Article.php(617): OutputPage->addParserOutput(ParserOutput)
 * 6) 5 /var/www/html/mediawiki/extensions/SemanticMediaWiki/includes/articlepages/SMW_OrderedListPage.php(67): Article->view
 * 7) 6 /var/www/html/mediawiki/includes/actions/ViewAction.php(44): SMWOrderedListPage->view
 * 8) 7 /var/www/html/mediawiki/includes/MediaWiki.php(458): ViewAction->show
 * 9) 8 /var/www/html/mediawiki/includes/MediaWiki.php(255): MediaWiki->performAction(SMWPropertyPage, Title)
 * 10) 9 /var/www/html/mediawiki/includes/MediaWiki.php(682): MediaWiki->performRequest
 * 11) 10 /var/www/html/mediawiki/includes/MediaWiki.php(476): MediaWiki->main
 * 12) 11 /var/www/html/mediawiki/index.php(41): MediaWiki->run
 * 13) 12 {main}
 * Testname::Testcase1
 * Testname::Testcase1

heading
It works, the page gets saved without any faults and  also works. Maybe I am doing something wrong here but that MWException should not come I think. There are also some other strange things happening but that could be me, not understanding  in combination with create page:). It seems that it is not possible anymore to tell the wiki to create pages for a certain property like Creates pages with form in the past. --Felipe (talk) 08:30, 19 September 2015 (UTC)


 * That indeed sounds like a bug. But I don't understand why you have that particular text - won't it print the page name twice? Maybe you should use #set to do the setting of the property - and maybe doing that won't lead to the same error. Yaron Koren (talk) 00:22, 21 September 2015 (UTC)


 * Hello Yaron, yes it will print the text twice. I was just playing around with an "old" template. I did some more testing and below is what is happening when the page that needs to be created does not exist yet.


 *  Example 1 with heading 

heading

 * A. This breaks, it will fail on the specific page with  . I can send you the Backtrace if you want.
 * B. When you refresh the page it shows:
 * SF_Page_Refresh_2015-09-21.png
 * If you refresh again the page looks normal and Testcase1 is created.


 *  Example 2 heading below 

heading

 * A. This breaks, it will fail on the specific page with.
 * B. When you refresh the page it looks normal with a redlink for Testcase1.
 * If you refresh again the page looks normal and Testcase1 is created.


 *  Example 3 no heading 


 * A. This breaks, it will fail on the specific page with.
 * B. When you refresh the page it looks normal with a redlink for Testcase1.
 * If you refresh again the page looks normal and Testcase1 is created.


 *  In combination with ExternalData 


 * I also converted our template to use . It uses externaldata to generate pages automatically but it is not possible to save the page, you get a blank screen. This is because it uses  :


 * When we use  it works.


 * But the same faults appear as in the earlier examples. When a page does not exist yet  will fail and if there are headings before   you get faults on the actual pages. I hope this helps to fix this. Regards, --Felipe (talk) 13:18, 21 September 2015 (UTC)

[SOLVED] Query for the page title in a query form
Hello,

how can I query for the page title in a query form? Since the page title is created via the first form field in the two-step-process, there is no manually created property behind it. I need to have a form field where I can search in the page titles. – I have the feeling I might just be missing something very obvious. –Zabien (talk) 16:52, 3 September 2015 (UTC)


 * You just need to have the template store the page name via a property (if you're using SMW) or field (if you're using Cargo). In either case, you can use the magic word. Yaron Koren (talk) 20:10, 3 September 2015 (UTC)


 * So I have to use e.g.  to be able to query for it later? Okay, that seems to be the obvious I've missed. Thought there might be an even more direct way. Thank you for the quick help! –Zabien (talk) 21:36, 3 September 2015 (UTC)


 * I think that's the easiest way. Although using #set might be preferable, since you don't want to display a value to the screen. Yaron Koren (talk) 23:16, 3 September 2015 (UTC)


 * Good point! I'll give this a try! Thanks heaps! –Zabien (talk) 10:21, 4 September 2015 (UTC)

Missing values in "Semantic Property" dropdown box
I am using Mediawiki 1.25.2, Semantic MediaWiki 2.2.2, Semantic Forms 3.3.2 (2e5712c). I tried to create a template. The semantic property dropdown box only list 14 values. Even I add additional properties via Special:CreateProperty. Does it happen to your version? Any fix? --153.20.95.74 08:24, 15 September 2015 (UTC)


 * I had restarted php-fpm and the problem went away, i.e., there is a cache issue. Is there a mean to force the update of cache? Also renamed properties (redirects were deleted too) also showed up in the list of values of Semantic Property --153.20.95.74 08:29, 15 September 2015 (UTC)


 * I don't know - this might be a Semantic MediaWiki issue. The SF code is just calling an SMW function to get the list of properties. Yaron Koren (talk) 13:37, 15 September 2015 (UTC)


 * I would like to confirm that even the property is deleted, the SWM function (please point me to the file or function as I am new to mediawiki and php) still return the deleted property.


 * That is a known SMW issue - I'm guessing that you can also see that same deleted property on the page Special:Properties. If so, you should ask the SMW developers about it. Yaron Koren (talk) 14:37, 15 September 2015 (UTC)


 * For a discussion about deleted properties/subjects (and its apparent reappearance), please have a look at the #1100 issue.--MWJames (talk) 14:59, 15 September 2015 (UTC)

Using query string in #forminput
I have a form which has a property "Student ID" and I want this property to be filled from #forminput via query string and using value from the title of the page.



If I use form name "12345699A", the immediate URL is http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=Student

What I want is http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=12345699A

I do not know how to get or parse URL using the existing standard extension as I did not install Extension:UrlGetParameters.


 * I'm not completely sure I understand, but it sounds like you'd be better off using #formlink instead of #forminput, and a page name formula. Yaron Koren (talk) 14:40, 15 September 2015 (UTC)


 * I tried #formlink just now, do not know how to enter the "Student ID". My original question can be simplified to

1) Enter 123456789A into the textbox

2) I want $forminput to generate the url http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=12345699A instead of http://localhost/wiki/Special:FormStart?page_name=12345699A&form=Student&Student[Student+ID]=Student --Yoonghm (talk) 14:59, 15 September 2015 (UTC)


 * The specific thing you're asking about can't be done. However - if the student ID is always the page name, why do you need a form field for it at all? Can't you just always use the page name? Yaron Koren (talk) 15:03, 15 September 2015 (UTC)


 * The problem for beginner likes me is that there are too many features within mediawiki and its extensions, there is no other good reference except your book. I want to put the Student ID as a property as I cannot prevent people from changing it and can be used for semantic query. Okay, I will consider your suggestion. --Yoonghm (talk) 15:30, 15 September 2015 (UTC)

Max size for properties
I would like to start a review site and store the reviews in properties. Yet even a comparably short review (800 words, 4500 signs) breaks the parser. What would be the recommendation in order to deal with this? I would like to add interviews with the length off 12(!) A4 pages into a property. Currently, I had to move all into a standard input field in order to avoid broken parser tags.

To give an example of what I talking about: http://adsol.oneyoudontknow.com/index.php/wiki/Anticosm_-_Anticosm
 * Top: the text added as a property (text)
 * Below: text added as a free field.

The lack of formatting is due c/p it from the bottom.

--Temptuousinsolence (talk) 18:17, 15 September 2015 (UTC)


 * Is this a Semantic Forms question? Anyway, I don't think it's the size of that text that's causing the problem, but rather the fact that it contains square brackets. Yaron Koren (talk) 01:21, 16 September 2015 (UTC)

Group pages (created via Semantic Form) in Category: according to other properties instead of page name
I have created several pages using Form:Student with the following page names.
 * 1111111A
 * 1111112B
 * 2222222C
 * 3333333D

These pages are in Students category.

Form:Student uses Template:Student which has the following properties

In the Category:Students page, these pages are grouped under 1, 2 and 3. How can I use Tutorial Class property to group them? --Yoonghm (talk) 02:18, 16 September 2015 (UTC)


 * This isn't a Semantic Forms question, but: you should be able to use DEFAULTSORT for that. Yaron Koren (talk) 13:13, 16 September 2015 (UTC)

Constraining the user to use forms to create a page.
I want to constrain users the use the forms to create a new page.

In other world, users can't create new pages on my wiki. They can ONLY add new pages thought the form. Is there an easy way to do that ?

Thanks a lot.


 * I don't know of any. Yaron Koren (talk) 13:14, 16 September 2015 (UTC)

#default_form parameter to hide "This category uses the form ..."
Is there a way to hide the "This category uses the form ..." text that is inserted automatically by #default_form? Like ...

--Planetenxin (talk) 11:47, 17 September 2015 (UTC)


 * Unfortunately, not at the moment - other than putting it in a hidden div or some such. Yaron Koren (talk) 12:56, 17 September 2015 (UTC)

Semantic forms and Translate
Hi,

I'm trying to use Semantic Forms and Translate extensions. My problem is that I can't modify an existing page containing the Translate's tags &lt;translate> with Semantic Forms (big red message when saving "Modifying Page failed").

As the page can safely be modified with the tags using the edit tab, I'd like to know if there is something I can do to force Semantic Forms to save a page with those tags ?

Best regards. LS.


 * That's unexpected... what versions of MediaWiki and SF are you using? And are the "translate" tags contained above or within the infobox template, or just below it? Yaron Koren (talk) 16:25, 17 September 2015 (UTC)


 * Thanks for your reply. The versions are the last stables (1.25.2 for Mediawiki) downloaded tuesday. The tags are in the wikicode produced by the form. For example, I create a page containing :


 * by writing &lt;translate>Blabla in the Title field of a Semantic Form. All goes right until I try to effectively translate the content : as soon as the appears, it's no more possible to modify the page with the form. If I try to change (with the edit tab) say &lt;translate> in or  in , the Semantic Form returns to its normal operation.

--Ludovic Strappazon (talk) 20:57, 17 September 2015 (UTC)


 * That's unfortunate... I have no idea why that's happening. It sounds like a bug in either SF or Translate, but I don't know more than that. It might be worth creating a Phabricator ticket for it. Yaron Koren (talk) 01:47, 18 September 2015 (UTC)


 * Hi, I've just seen that if I remove the Translate extension, Semantic Forms returns to its normal operation and save the contents with tags. I'm going to create a ticket. Thanks again.

Best regards, --Ludovic Strappazon (talk) 07:21, 21 September 2015 (UTC)

Wrong format date output
First I want to congratulate you on this great script. I am Spanish, and here the usual format is day / month / year. When I create a page with form, the date field appears in this format. When I edit the property of the field is also used properly displayed in this format. But the end result is always the created page Year / month (with numbers) / day. I have read through everything and I have tried everything without getting any results. I'm not sure that the problem is in your script, because if I put on any page also shown year/month/day. But I insist that the property is properly displayed. Can you help me solve this ?. Thank you very much for your time and help: Luis.


 * I don't think there's any way to get a form to output day/month/year. But you can have the template display dates in this format to the user, using the #dateformat parser function - see Help:Magic words. Yaron Koren (talk) 16:32, 17 September 2015 (UTC)

Thank you very much for your quick reply. I'm clear that the problem has nothing to do with his script. Anyway, I had already tried this method I have even tried to define it manually in LocalSettings.php simply ignored by my wiki. You can see an example here: Thanks again


 * I don't understand the syntax you're using in that template - you should be calling #dateformat. Yaron Koren (talk) 01:38, 18 September 2015 (UTC)

solved
Explain the steps if they can be of help to someone: First I tried his method and works but it has any drawbacks:

- Does not accept the format xx / xx / xx so must first replace the "/" with "-"

- The system does not recognize it as date format and has an error, so that the property can not be "date" it must be "text"

- You can not add words to date like (typical in Spanish) "02 de enero de 2010"

The solution I've found to not have any of the above three problems is to use (requires ParserFunctions). For example Where "Nacimiento" is the name of the property that I used to date in my template, It produces output (if such date is 2010/01/20): 20 de enero de 2010 and the system is no problem recognizing it as date. Thank you very much for your support that has helped me a starting point and hope it can be useful to someone. Greetings: Luis

Problem with #default_form
When you transclude a page that uses #default_form through a template, then the page which embeds this transcluded content also inherits #default_form: as a result, that page becomes editable using the wrong form. I'll just stick to the old SMW approach (which lets you embed content without inheriting its annotations). Is there anything else that can be done about this? Best, Cavila 12:18, 21 September 2015 (UTC)


 * I can't think of anything. Yaron Koren (talk) 13:53, 21 September 2015 (UTC)


 * Alright, thanks. It's no problem for me as long as that special property is supported. Cavila 18:59, 21 September 2015 (UTC)

Problem with "checkbox"
When i use input type "checkbox" with russian as main wiki language, it stores value "Yes" like "да". But when I try to edit existing page with this value checkbox shows unchecked. If I manually change value from "да" to "Yes" the checkbox shows ckecked.

Is it possible to disable this localisation interchange for checkbox and have only Yes?


 * No... but that's a bug that should be fixed. What versions of SF and MW are you using? Yaron Koren (talk) 14:10, 25 September 2015 (UTC)
 * SMW 2.0, SF 3.3.2 (90cb2b3) (Dmitry Russkih (talk) 12:13, 11 October 2015 (UTC))


 * I was actually asking about your MW version, not your SMW version, but anyway, I think I have enough information to solve this bug. The issue seems to have been due to a combination of a change I made two months ago and the fact that PHP's regular lowercasing function doesn't work for Cyrillic. I think I just fixed it; if you get the latest SF code, the problem should go away. If not, please let me know. Yaron Koren (talk) 23:21, 11 October 2015 (UTC)


 * I had MW 1.23 but today I've completely updated MW to 1.25, SMW to 2.2.2 and SF to 3.4 (90cb2b3) (latest version including patch with mb_strtolower). It still not shows checkbox checked when template has "Да" as "Yes". I'll send You login data to my wiki (I guess it may help).
 * One important add: I've not set any value to mbstring.internal_encoding, so when I try execute mb_strtolower('Да') I show 4 black diamonds with ask sign into (utf-8 to iso 8859-5). When I execute mb_strtolower('Да','utf-8') I recieve 'да' (correct).

Editable-grid input (jqGrid?)
This has been a planned feature at least since 2011 and was discussed on the mailing list back in 2010. A good alternative is, of course, the multiple-instance form, which has seen a lot of improvement over the years and which is in some respects, more versatile than a simple datagrid. So I was wondering: do you still see a future for the grid feature? And in situations in which a form contains (say) 40+ instances of a template, do you think there's any significant performance gain to be had from an editable grid input in comparison with the current feature? Cavila 21:07, 2 October 2015 (UTC)


 * I still think it would be cool to have the editable grid feature; although I also think it would be hard to implement. And yes, it would be less flexible than the multiple-instance template option. I don't know whether it would have better performance, but I'm guessing it would. I've heard that forms start to become unloadable if there are 50 or more template instances on the page, which probably wouldn't happen with the jqGrid thing, I would think. Yaron Koren (talk) 22:42, 2 October 2015 (UTC)


 * Thanks. Implementing and maintaining such a feature can't be trivial (FWIW, jqGrid is used in the timeseries result format, but that's for presenting rather than inputting data). But it would be a great thing to have, perhaps especially for keeping long lists of things. Sounds like a candidate project to be proposed for the next Google Summer of Code. Cavila 07:56, 3 October 2015 (UTC)

Firefox problems with tree and combobox
We've started having some weird issues with Firefox after installing Semantic Results Formats. In particular, the combobox and tree input types no longer seem to be working properly.

The code looks like this:

and

It continues to work just fine in Chrome. Here are screenshots comparing the two: Combobox and Tree

We're on MW version 1.25.1, SMW version 2.2.2, Semantic Forms version 3.4, and Semantic Results Format version 2.3 (though I don't know that that one's related, it did seem to break after installing it).

Any ideas for things to look at? I'm mystified.


 * The SRF thing might actually be the cause - if you use SMW and SRF, they should be at the same "2nd level" version, i.e. if it's SMW 2.2.*, it should be SRF 2.2.*. It could be that the mismatch is causing some JavaScript problem. Yaron Koren (talk) 01:14, 18 October 2015 (UTC)


 * Thanks, I'll see if can get those in the same version and see if it fixes the problem! --Aekki99 (talk) 03:46, 18 October 2015 (UTC)


 * My wiki has same parameters (mw 1.25, smw 2.2.2, sf 3.4 and srf 2.3 ) and both features (combobox and tree) work fine in firefox. Try to look over browser javascript console (Ctrl+Shift+K). It might be another extension that also uses javascript (like fancybox etc.). Dmitry Russkih (talk) 11:58, 18 October 2015 (UTC)

Old Error pops up again: .....includes/MagicWord.php: Error: invalid magic word 'default_form'
I'm running MW 1.25.1, when I upgraded SF to 3.4 I get this error when I tried to run /mw-config/. ...includes/MagicWord.php: Error: invalid magic word 'default_form' I see others had this problem a year ago but I couldn't find their solution to it. Only after commenting out SF in LocalSettings.php would /mw-config/ complete, after which I could reinstall SF and /mw-config/ would simply show its "Upgrade complete." page. Is this fixed in v1.25.3? WmBliss (talk) 03:05, 19 October 2015 (UTC)


 * I don't know. Is this problem still happening? Yaron Koren (talk) 14:04, 19 October 2015 (UTC)

template in forms
Hi Yaron,

I would like to use a template for an often needed field type in a form like

{|



... where the first parameter is an upcounting number, the second parameter contains the topic.

The templates source is
 * {{{field||input type=radiobutton|values=yes,no|show on select=yes=>yes;no=no;|mandatory}}
 * 50 points 0 points
 * 50 points 0 points

Using this I don't get a field in the form.

When I use this lines instead of the template (of course without parameters) in the form like

the form works.
 * topic1
 * {{{field|topic1|input type=radiobutton|values=yes,no|show on select=yes=>yes01;no=no01;|mandatory}}
 * 50 points 0 points

What goes wrong using templates in a form? Even a template without parameters doesn't work. And even if I don't use a table it doesn't work.


 * You need to escape the form elements; see here. Yaron Koren (talk) 01:50, 20 October 2015 (UTC)

Undefined property: SFTemplateField::$mCargoFieldType
Not sure if this is a Page Schemas or Semantic Forms issue. I'm trying to setup semantics using Cargo. I've got a page schema setup, runJobs, and it gets as far as creating tables but not the fields.

In edit schema for a category I check the cargo field box and select types (i.e. text, page, date). After I generate pages I look in the edit source for the template created and the fields aren't defined for the cargo_declare...

I'm getting errors in my logs like this...

Undefined property: SFTemplateField::$mCargoFieldType in extensions/SemanticForms/includes/SF_Template.php on line 67.

Here are my versions:

Semantic Forms	3.4 (464a78b) 12:45, October 23, 2015

Cargo	0.10 (5d58912) 00:38, October 15, 2015

Page Schemas	0.4.5 (05b735d) 13:49, October 20, 2015


 * Sorry about that! This was a bug in Semantic Forms, although it only showed up when used with Page Schemas. I guess I must not have tested this... I just merged in what I think is a fix for this bug in SF. Yaron Koren (talk) 01:16, 26 October 2015 (UTC)

language of boolean values in templates
I have a Form:X calling Template:X which contains a boolean Property:X. I'm seeing a behavior related to the language used for the value of the property which I'm having trouble finding a reason for.

I'm using: MW 1.24.2, SMW 2.2, SF 3.4. The value of $wgLanguageCode is "da".

I have a fair amount of pages using Form:X, Template:X with correctly functioning values of Property:X in English: "yes" or "no".

Something must have changed, because when I use the Form:X to edit one of these pages now, it gets saved with Danish boolean values: "ja" or "nej". It appears to me that $wgLanguageCode is one place to control the selection of language for these booleans, but I'm fairly certain I did not change that.

What is puzzling me is this: given that I did not change the $wgLanguageCode, what setting was it which resulted in a SMW with $wgLanguageCode of 'da' to use english boolean values? I've tested changing the language in my account and that does not seem to override $wgLanguageCode.

any clues? JosefAssad (talk) 18:17, 27 October 2015 (UTC)


 * Yes, there was a change in SF two months ago; you can see it here. The code now gets its values from MediaWiki, not SMW; and I'm guessing that MW has Danish values while SMW doesn't, or something like that. Is it a problem? Yaron Koren (talk) 23:55, 27 October 2015 (UTC)


 * I did figure out that $wgLanguageCode was the first factor which changes which language is used for booleans. The thing which is causing me confusion is, that the wiki has always had a Danish language code, yet I have pages which were created and work fine using sematic forms which used english boolean values. A couple of days ago, I performed a null edit on one of those pages and it changed the Booleans to Danish. Of course this is fairly easily remedied by adding the Danish booleans to the SMW_true_words and SMW_false_words but I'm wondering what prompted the form to suddenly choose Danish when it had been using English boolean words before. Of course the answer is usually "you changed something" so I think it's mainly a matter of finding out what it is precisely I changed. :) The versions of MW/SMW/SF have not changed, and the $wgLanguageCode has not changed either. JosefAssad (talk) 10:01, 28 October 2015 (UTC)


 * Oh, okay. Well, it could be that that page, or pages, was created before you upgraded to SF 3.4... Yaron Koren (talk) 10:16, 28 October 2015 (UTC)


 * Ah yes, that looks like the cause; I checked a backup and it was on 3.2, the server in question is on 3.4 currently. So before, SF was getting the boolean words from SMW_true_words and SMW_false_words, and after it was getting them from the MW localisation, is that correct? It seems to me that my problem (SF saves Danish boolean values which are not recognised by SMW) can be remedied by adding the Danish words to SMW_true_words and SMW_false_words, but shouldn't SMW also recognise the Danish boolean terms automatically? JosefAssad (talk) 10:54, 28 October 2015 (UTC)