Extension talk:Page Forms/Archive November to December 2012

Property values are not loaded into the SF fields

Hi Yaron, I have a semantic form that uses a template, with a property of type String, and allows several values (an enumerated property). One of the fields was showing automatically these values. The thing is that I change the type of the property form String to Page, and the field stopped showing the values. Then I change back to type String, to fix it, but it remains not showing the values.

Is this a known bug? by the way, Im using SF version 2.5.1.

Cheers, Chei.

I definitely haven't heard of such a thing... are you sure the property type was the only thing you changed? Yaron Koren (talk) 15:36, 27 November 2012 (UTC)

Yes, Im sure. Inside the template, I've defined a semantic internal objects(SIO extension) that uses this property. Maybe that helps. I was wroking great, until I change its type, then it broke, and I change its type back to fix it, but it is still broken.

It could be that adding "|property=property name" to the field tag in the form definition would fix the problem. I don't know why it would have worked before, then stopped working - it could be a bug in SF - but this might be an easy workaround. Yaron Koren (talk) 06:25, 28 November 2012 (UTC)

placeholder for {{#formlink... resp. {{#forminput

Hi,

proposal for {{#formlink... resp. {{#forminput

add the placeholder-Attribute (like in forms, see http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Defining_forms)

thx ;)

Cheers, --213.33.94.194 14:30, 5 November 2012 (UTC)

That makes sense for #forminput, but how would it work for #formlink? And what does "resp." mean? Yaron Koren (talk) 14:59, 5 November 2012 (UTC)

Hi Yaron. I just wanted to suggest the same: add the placeholder parameter to #forminput. It would be great to have that feature - since the placeholder text helps pointing the user into the right direction.
Makes no sense for #formlink though :) --Stefahn (talk) 10:33, 15 November 2012 (UTC)

Suggestion: Remove hard-coded background colors for various elements

Hi,

I have installed Semantic Forms and am using it since quite some time. One particular thing I noted is that the various elements are getting assigned usually white or light grey background colors.

It seems that is happening EITHER in one of the CSS or is even hard-coded into the PHP files, such as in specials/SF_CreateForms.php where it says:

// 3 values per row, with alternating colors for rows
			if ( $i % 3 == 0 ) {
				$bgcolor = ( $i % 6 ) == 0 ? '#eee' : 'white';
				$text .= "<div style=\"background: $bgcolor;\">";
			}

For most wikis that work with a light background color and a dark font that should have no complications, however for wikis with dark skins (such as my own), and very light fonts (white) you will get a white box with all text in white, until you manually disable the color functions.

Suggestion: - Move all color attributions into classes and create one single CSS file title "skin-related.css" where these classes (and its colors) are defined. - For wikis with more than one template and more than one style (various background colors), they could delete these individual classes or leave them empty and re-declare them in their individual skin CSS files

--180.94.145.167 02:31, 7 November 2012 (UTC) Azchael of Rock in China

It's a good idea to un-hardcode all the CSS. Most of the CSS already is in CSS files - SemanticForms.css and others. Wouldn't it work to just move the remaining CSS into those files? Yaron Koren (talk) 05:27, 7 November 2012 (UTC)

It would work for all elements that are marked up with CSS styles in the PHP files. But for the example as shown above, one would have to change the PHP code to switch from an automatically created table background (either white or eee) to two individual classes that are being assigned (e.g. row_even and row_uneven). --180.94.145.167 07:30, 7 November 2012 (UTC) Azchael of Rock in China

Yes, of course. Yaron Koren (talk) 15:04, 7 November 2012 (UTC)

Forward or redirect to result of 1 page query

I could have sworn I saw this somewhere, but I've searched everywhere with no luck. I'm trying to make a short RunQuery that takes you straight to a page with the entered information.

So for example, if someone Selects Texas for state, and Austin for city, the search will take them to the page Texas/Austin. I tried making a template with the redirect

#REDIRECT [{{{State|}}}/{{{City}}}]]

, but the redirect doesn't initialize. It seems the redirect is thrown into a <p> or turned into a list item. Anyone know how to do something like this? Thanks for the help.

Multiple embedded query forms on same page

Seem to be having a little trouble with this. I have two embedded query forms with different names and different templates on the same page. The user can run one or the other, depending on what they're looking for. This doesn't seem to be working though. When I enter in the information and click search on the first form, the second form on the page complains that there are required fields missing. Is this possible to do, or can you only embed one per page? Thanks

That sounds like a bug - though one I'm not surprised by. My guess is that you can get around this, though, by (1) removing all "mandatory" requirements from the query forms, and (2) using #if in the query templates to not display anything if no fields were filled out. Yaron Koren (talk) 16:32, 9 November 2012 (UTC)

Thanks. I'm sure I can figure out something, just wondering if it was a bug or me missing something.

ConfirmEdit integration

Couldn't find anything on this. I have ConfirmEdit with questy captcha on edits and creations. When I go to change a page with semantic forms and click save, it changes the page to a source edit with the captcha question and an Error: A MediaWiki extension prevented the modification of the target page. Is there some settings available to integrate these two extensions that I missed? If not, is there a way to disable source editing for anonymous users, but keep forms editing? Thanks

What versions are you using of ConfirmEdit, Semantic Forms and MediaWiki? Yaron Koren (talk) 16:53, 13 November 2012 (UTC)

MediaWiki 1.19.0, Semantic Forms (Version 2.5.1), ConfirmEdit (Version 1.1)

Oh, I think I understand - it's not that you can't save the form, it's that the saving happens over two pages, and you want it to all happen on one page. Unfortunately, I don't think there's any way to do that. You can basically do the second thing, though, with the 'viewedittab' permission - see here. Yaron Koren (talk) 22:18, 13 November 2012 (UTC)

Exactly. I saw the ability to get rid of the viewedittab, but I assume the bots would just go straight to the edit page without the button anyway. Surprised the ConfirmEdit guys haven't added support for FormEdits. I'll have to see what I can do to make it a little more user friendly, while keeping it bot unfriendly.

Multiple instance templates using "holds template" and "embed template"

Hello, I've found the link to Extension_talk:Semantic_Forms/Archive_December_2011#Template_in_a_template and am trying to implement. It's a pretty good example,except it's unclear what content is to be placed into the form, and what exactly should go into the (sub)templates pages. I believe the main content described there goes into a form, but am unsure. I've somehow created a template loop when setting this up, so some more clarification on this functionality would be useful. Patelmm79 (talk) 17:03, 13 November 2012 (UTC)

Do you understand the basic difference between forms and templates? Yaron Koren (talk) 22:19, 13 November 2012 (UTC)

Of course, I've set up and edited both as well. What's not clear though, when creating a template of templates and then implementing via form, is how the template would look (especially in the case of trying to create a header row of multiple instance templates). The loop does not exist anymore, and the list of instances now appears in the form, but now my trouble is that I'm unable to save new instances to the list (I hit save, but nothing happens, nor does an error message result.) So there's still something off in my code, and I believe it has something to do with how I set up the templates.Patelmm79 (talk) 22:53, 13 November 2012 (UTC)

Sorry, what do you mean by a "template of templates"? Yaron Koren (talk) 23:46, 13 November 2012 (UTC)

Quoting from Semantic froms archive mentioned above: "The page itself in this case would use 4 templates. A main one called {{Create person}} with 3 variables, {{{Main}}}, {{{Add address}}}, and {{{Contact info}}}, which actually call a template themselves"

Oh, I see - you're talking about a template field that holds multiple templates. If it's not working with you, I'd suggest copying your form over to a public wiki, like http://scratchpad.referata.com, so that it's easier to debug the problem. Yaron Koren (talk) 14:24, 14 November 2012 (UTC)

Yaron, thanks a lot for your help. Here is the page: http://scratchpad.referata.com/wiki/Multipleinstancetemplate Patelmm79 (talk) 17:32, 14 November 2012 (UTC)

Okay - you could have actually set up the form, but this is fine. Your #forminput call, and the "wikiPreview" div, both seem to be in the wrong place - either of those could be issue. Yaron Koren (talk) 18:06, 14 November 2012 (UTC)

Gotcha. I set up the form and made changes as you suggested. I'm able to save the form now. But my remaining issue is, how do I apply formatting so that I can get a table of information to appear? If I apply a wikitable class to the main template, only the first row of data is formatted. If to the subtemplate, the subsequent rows are formatted. Both at the same time does not quite work either See http://www.referata.com/wiki/BankBranchData Patelmm79 (talk) 20:58, 14 November 2012 (UTC)

Hi - you shouldn't put stuff on referata.com, but only scratchpad.referata.com. Anyway, I think I mostly fixed the problem in your template. Yaron Koren (talk) 21:56, 14 November 2012 (UTC)

Oops sorry, In any case, that fixed the issue perfectly, thanks for your help! It's clear that there's actually nothing complicated about the templates which would be caused by the extra complexity in the form, it's simply a matter of having the table contained in the main template, and the fields in the subtemplate. Patelmm79 (talk) 14:59, 15 November 2012 (UTC)

how stop creating new pages through #forminput

We are trying to control the naming convention of our pages. I have given the users #forminput to do searches but they are inadvertently creating new pages through this...

Should I being using a different call? Maybe I could answer this myself by testing. Just thought I could get a quick answer. let me know. Thank you again. Margaret--Amblerllc (talk) 02:51, 14 November 2012 (UTC)

Hi - you definitely shouldn't use #forminput to do searches. Do you know about Special:RunQuery? Yaron Koren (talk) 13:36, 14 November 2012 (UTC)

Performance issues with pauses

I'm getting a lot of pauses when filling in Search RunQuery forms. Typically the page takes quite a while to load, then each of the fields and drop downs take about 2.5 seconds to actually blur the field or drop down. Autocomplete on or off doesn't seem to matter. Filling in regular forms don't have the problem either. This is all on a pretty beefy dedicated server with only a few pages for testing. I've been modeling my search after the one on www.wdoc.org, and don't see anything obviously different in the code, except for use of the "values dependent on". I even noticed the skin's search box will take a few seconds to blur when on a RunQuery page. Any idea what it could be, or how to fix?

I assume all the slowness is due to JavaScript, which is client-side, so the server isn't causing the slowness; it's your computer. Maybe you have too many applications running? That's always my problem. Yaron Koren (talk) 21:58, 14 November 2012 (UTC)

I Noticed on selecting the field it loads api.php from load.php before showing the cursor in the field. With wdoc.org's site, it doesn't try to load api.php until you start typing into the field. It also takes a little over a second to load on mine vs 231ms on wdoc. Not sure if it matters, but mine also doesn't have the little thinking gif when typing in the field. Did I miss a setting for choosing when it attempts autocomplete?

Autocompletion is set within the form definition. Are you using the same versions of MW, SMW and SF in both? Yaron Koren (talk) 16:01, 15 November 2012 (UTC)

wdoc.org isn't my site, but he is running MW 1.17.0, SF (Version 2.2), and SMW (Version 1.6.1). I'm running MW 1.19.0, SF (Version 2.5.1), and SMW (Version 1.8 beta 2). So obviously his versions are a good bit older. I was referring to there maybe being a setting that determines after how many characters it loads the autocomplete. Maybe between the different versions it was set to 0 characters instead of 1, or something like that?

No - but there's the "remote autocompletion", which uses Ajax (and api.php) to do autocompletion. My guess is that WDOC is using it for that field. Yaron Koren (talk) 17:16, 15 November 2012 (UTC)

Ok, so we both have "remote autocompletion", but he doesn't have "values dependent on". I just removed it on mine, and now it's behaving similar to his and only auto-completing on a character press. I really need the "values dependent on" feature though, so hopefully there's a way to get it to behave right with the option in there?

What do you mean, "behave right"? I thought the issue was just the speed. Yaron Koren (talk) 17:59, 15 November 2012 (UTC)

Sorry, I just mean for it to only start requesting autocomplete when the user inputs a character like it does without the "values dependent on" isn't in there.

Just to clarify: what you're saying is, with SF 2.5.1, when you have "values dependent on" and "remote autocompletion" in the same field, it doesn't actually seem to be doing remote autocompletion? Yaron Koren (talk) 19:52, 15 November 2012 (UTC)

Sorry if I'm not explaining this well. It does seem to do the remote autocompletion just fine with "values dependent on", it's just doing it too early. When you have "values dependent on" set, it does the ajax query for autocomplete results before a character has even been entered into the field. So just selecting the field causes a query for autocomplete on nothing. When you don't have it set, it does it on each character press. So selecting the field does nothing, but entering an "a" does a query for everything starting with an "a", and so on.

Error after install

I am getting this error ERROR: Semantic MediaWiki must be installed for Semantic Forms to run! after a new install. Here is the wiki's version page as it was during the error. As you can see Semantic MediaWiki is installed and working. Database setup ("Database installation and upgrade") & Automatic data update ("Data repair and upgrade") were successfully completed. I apologize I could not find this subject in the archives. Mlpearc (powwow) 03:40, 15 November 2012 (UTC)

My guess is that you just put the SF inclusion in LocalSettings.php before the inclusion of SMW, instead of after. Yaron Koren (talk) 14:53, 15 November 2012 (UTC)

DUH :P Thanx Mlpearc (powwow) 17:44, 15 November 2012 (UTC)

auto complete not working on category????

I'm struggling.

I have two fields. Both are suppose to be auto completing on a category. One is working and the other is not.

But here is the weird part. The one that isn't working does find all the entries that I imported using data transfer.

I am using a two different forms to populate the two different categories.

I am using a tabbed form with the fields that are suppose to auto-populate.

I am using embedded templates in the tabbed form.

Can you help? Thanks, Margaret User:Amblerllc

Tabbed form:

= Providers =
{{{field|Client Providers|list|holds template}}}

{{{for template|Client Providers|label=Client Providers|multiple|add button text=Add a Provider|embed in field=Client[Client Providers]}}} 
{| class="formtable"
! Provider:
| {{{field|Provider Name|values from category=Provider}}}
|-
! Other Contact:
| {{{field|Other Contact Agency|values from category=Other Contact}}} 

What do you mean by "The one that isn't working does find all the entries..."? Is it autocompleting, or not? Yaron Koren (talk) 15:39, 29 November 2012 (UTC)

My form that is populating the category... those entries are not being found by the auto-completion. I see the entries in the category though. The Provider name field is NOT auto completing and the Other Contact Agency is auto completing.

Well, I'm still not sure I totally understand, but - try adding "|input type=text with autocomplete" to the "Provider Name" field. Yaron Koren (talk) 04:24, 30 November 2012 (UTC)

Ill try again cause this is strange. I used Data Transfer to bring records in to the db. The template places them in Category:Provider. I have a form that creates new records and places them in the same category, Category:Provider. When I do a search using a field that auto completes on Category:Provider only the records that were brought in using Data Transfer are found. But I can see ALL the records in Category:Provider. So they are there, just not in auto-complete.

Ah! Now it's about 10 times clearer. My guess is that there's a bug here where MediaWiki thinks there are two different categories, both named "Provider"; that sometimes happens. Assuming the category is set by the template, I would try making a small change to the template, and resaving it - that might fix the problem. Yaron Koren (talk) 15:22, 2 December 2012 (UTC)

Some more info on this problem. Making a change to the template didn't fix the problem so I removed the category on the template, ran the SMWRefresh.php, runJobs.php and depopulated the category. I then added the category back on the template and ran the same scripts. It all looked great! I added new records to the category and the autocomplete found the new records. Unfortunately there were 150 records that didn't have a category on the records (using pages without categories special page). I assumed that these were the records my client added that never made it to the category.... I ran the same scripts one more time and it messed it up again. Now when I add new records using that form/template the auto-complete doesn't find the records.

Is it runJobs.php or SMWRefresh that is making this discrepancy?

If anything, it would be runJobs.php, I think - I don't believe this is an SMW-related issue. Yaron Koren (talk) 14:42, 7 December 2012 (UTC)

Form vanishes after preview

Hi Yaron,
when previewing a page one is transferred away from the form input and only sees the usual wikitext editor. I found this problem described here and you said you would fix this. What is the status of this fix if I may ask?
My users get confused if they don't see the form after previewing their input...
Thanks!
--Stefahn (talk) 15:49, 29 November 2012 (UTC)

Hi - yes, that functionality was added into SF years ago. You just need to add the "wikiPreview" div to your form, as described in that talk page section. Yaron Koren (talk) 16:53, 29 November 2012 (UTC)

Thanks for your quick reply! Okay, now I see why I need this div. I once deleted the div because of this issue (if I hit "Save page" in the preview I get a popup asking me if I want to quit the page). What is the status of this issue? Also, do you know how I can get rid of the scrollbar within the preview?
Thanks so much for your excellent extension and support, Yaron!! Stefahn (talk) 17:57, 29 November 2012 (UTC)

Ah, right, now I remember. Well, the scrollbar issue was recently in the fixed in the code, and it could be that the popup issue has been fixed as well. There have been a bunch of changes to the form-preview Javascript code recently, and they're all going into the next version of SF, which will hopefully be released within a week or so. So I'd recommend upgrading when that happens, and trying everything out then. Yaron Koren (talk) 19:21, 29 November 2012 (UTC)

Form definitions disappear when new a namespace is added to LocalSettings.php

I am adding the following namespace definition to my LocalSettings.php:

define("NS_TRANSACTION", 800);
define("NS_TRANSACTION_TALK", 801);
$smwgNamespaceIndex = 800;
$wgExtraNamespaces[NS_TRANSACTION] = "Transaction";
$wgExtraNamespaces[NS_TRANSACTION_TALK] = "Transaction_talk";
$wgNamespacesWithSubpages[NS_TRANSACTION] = true;

This change makes all my previous form definitions disappear:

• Special:Forms is empty
• There is no record of the previous form definitions in the deletion log

If I revert back to the old LocalSettings.php the form definitions appear again

My version:

• MediaWiki 1.20.0
• Semantic Forms (Version 2.5.1)
• Semantic MediaWiki (Version 1.7.1)

Anyone?

Thanks --Xavier Atero (talk) 07:28, 4 December 2012 (UTC)

There's no reason to reset $smwgNamespaceIndex there - I'm pretty sure that's what is causing the problem. Yaron Koren (talk) 13:48, 4 December 2012 (UTC)

Fatal error caused by SF when using MW web updater

Hi Yaron,
there is an issue with SF when you use the MW web updater (I don't have shell access, so I have to use the web updater). You can see the error message here on my test wiki - just click on "Weiter". You can see the same error on semantic-mediawiki.org. The issue was once discussed here but it seems there was no final solution for it. BTW: I'm using the very latest SF from today and SMW 1.8.
Thanks for your help!
Stefahn (talk) 21:32, 4 December 2012 (UTC)

I don't see a "Weiter" link on that page. Yaron Koren (talk) 22:42, 4 December 2012 (UTC)

I mean the Weiter button - please see here. This is the error message that is shown. Stefahn (talk) 22:51, 4 December 2012 (UTC)

Okay, that's helpful (the button has a different name when I see it in English). I don't know what exactly is causing this problem, but I'd say the easiest workaround is to comment out SF when you're doing the upgrading. Yaron Koren (talk) 00:32, 5 December 2012 (UTC)

Yes, that's what I did now. Time for me to get my own server - to be no longer dependent on the web updater... Thanks for your support! Stefahn (talk) 13:05, 5 December 2012 (UTC)

Applying "edit with form" to subcategories

Hello--is it at all possible to attribute a form to a parent category, so that that form is used to edit pages that use subcategories of that parent?

For example,I want to be able to edit page Competition Analysis with form Process. This page has category of Competition Research. But instead of applying to form to that category, I'd like to be able to apply that form to its parent category, Market Research. In this way, all subcategories of Market Research inherit the form.

Is this possible? Patelmm79 (talk) 23:18, 6 December 2012 (UTC)

I think that's already how it works - did you try it? Yaron Koren (talk) 02:04, 7 December 2012 (UTC)

I did, both on mine and Referata scratchpad, you can see it set up there --page CompetitionAnalysis does not have the form available and is set up as described above; page CompetitionAnalysis2 has parent category Market Research directly, and shows "Edit with Form" Patelmm79 (talk) 16:41, 7 December 2012 (UTC)

Oh, I guess that's not how it works, then. You'll have to apply the "default form" declaration to each subcategory, then. Yaron Koren (talk) 16:20, 9 December 2012 (UTC)

Thanks Yaron! 69.80.65.58 14:53, 10 December 2012 (UTC)

No page saved with multiple embedded templates

Just letting you know that I've experienced a critical performance issue with using multiple embedded templates. On one page I had about 50 instances of the same embedded template (the only values being a name and number) and tried to save the page. What happened instead is that I was directed to the form again and no data were saved. Regards, Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.7.1} 09:39, 7 December 2012 (UTC)

What version of SF are you using? And does the problem occur when there are fewer instances? Yaron Koren (talk) 13:03, 7 December 2012 (UTC)

SF 2.5.1. No, the issue starts to occur when you're somewhere near the 50 instances mark or above. Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.7.1} 09:53, 9 December 2012 (UTC)

Having a label in the template definition prevents multiple templates to be saved

I have created the following form http://scratchpad.referata.com/wiki/Form:Student containing:

• Tab 1: name of the student
• Tab 2: last name of the student
• Multiple notes

As the form is defined when typing a name, a last name and adding notes the notes are not saved. But when "label=student" is removed from the "for template" definition the notes are saved --Xavier Atero (talk) 21:40, 7 December 2012 (UTC)

That's not entirely surprising - putting a fieldset (which is what "label" does) around tabs seems like it would mess up the HTML or Javascript somehow. Yaron Koren (talk) 21:56, 7 December 2012 (UTC)

Multiple-instance templates, new items added on top of the list

When creating new items in a multiple-instance template, the default behavior adds them at the bottom of the existing list. Would it be possible to have the new item added on top of the list instead (newest first rather than oldest first)? Thanks --Xavier Atero (talk) 18:01, 8 December 2012 (UTC)

Not at the moment. Yaron Koren (talk) 16:20, 9 December 2012 (UTC)

Internal Error when attempt to publish an item with a form with a "googlemaps" input type.

I got an internal error [5074c884] 2012-12-09 10:13:03: Fatal exception of type MWException

When I try to publish with a form and when the field geographic coordinate is not filled

You can try to publish without filling the "Coordonnées géographiques" field. http://domotiki.eu/index.php?title=Z_elec&action=formedit

My conf :

• MediaWiki 1.20.0
• Semantic MediaWiki (Version 1.8) (SMWSQLStore2)
• Semantic Result Formats (Version 1.8)
• Semantic Maps (Version 2.0)
• Maps (Version 2.0)

more details

Thanks for help,

I would try upgrading to the recently-released Maps and SM 2.0.1, and see if the problem is still there. Yaron Koren (talk) 15:22, 16 December 2012 (UTC)

Upper case first character's input

I was wondering if anyone had a way to do this, or maybe a ucfirst function could be thrown into the next update. Basically I have a forminput that uses super_page to add the input onto the subpage, and I want that input to always have the first character upper case. Thanks!

Call one-step-process from maintenance type script?

Hey folks. I use semantic forms at work for a ton of simple user generated content. Most of the time the articles names are set by the form with prefix and and an increasing sequential number using the <unique number> tag. Well, I'd like to do a similar thing automatically, with a cron job or something. Say I had a handful of rows and wanted to turn each into an article, once a day. How would I get the same functionality as <unique number> into maintenance/edit.php (or equivalent)? Guess it's not strictly a forms question. Thanks! - Lbillett (talk) 01:40, 14 December 2012 (UTC)

The "Import CSV" feature of the Data Transfer extension may be helpful here. It won't generate automatic page names, but you could potentially use Excel or something like that, if you put all the rows into an Excel spreadsheet. Yaron Koren (talk) 02:16, 14 December 2012 (UTC)

Interesting. I'll check that out. Though, automatic page name creation is kind of a clincher for this one. If someone new where/how in the SF code the <unique number> tag gets the page name information, I might have a chance. - Lbillett (talk) 12:55, 14 December 2012 (UTC)

You can search in the code for "unique number". Though trying to call that code from elsewhere might be challenging, I think. Yaron Koren (talk) 14:20, 14 December 2012 (UTC)

Query form link with vs without popup function

Hi Yaron. The "queryformlink" normally takes you to a special page (Special:RunQuery/<...>) that has both query fields and once the query is run, query results. I just noticed though that the popup version omits the query fields, so that it's useful only if you want to show a query with preloaded data. Is that intentional behaviour or perhaps just inevitable? Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8} 22:19, 14 December 2012 (UTC)

I'm pretty sure that's intentional, from what I remember. Yaron Koren (talk) 01:08, 16 December 2012 (UTC)

Okay, I was thinking of a setup where this would have been useful feature, but never mind. Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8} 10:36, 20 December 2012 (UTC)

Localisation questions

Hi Yaron,

I have just finished translating SF into Greek and when I tried to incorporate the translation to my wiki I noticed that it doesn't have the usual *i18n.php file but a 'languages' dir. I understand that all data from translatewiki.net go into SF_Messages.php but what about other messages in the rest of files? For instance, how do I translate the "Form:" namespace (file SF_Namespaces.php)?

And a second question. Is it safe to just replace my 'languages' dir with current 'languages' dir in git? or do I have to upgrade the whole SF extension to the current version? --Protnet (talk) 13:12, 15 December 2012 (UTC)

The best way to translate those other files, if you don't have a developer account, is to just send me an email with the translations, at yaron57 -at- gmail.com. And no, I don't it's safe to just replace the "languages" directory, since the set of messages usually changes somewhat between versions. Yaron Koren (talk) 01:10, 16 December 2012 (UTC)

I just send you the translations for everything I found in the SF languages dir (except SF_Messages.php of course). I have noticed that some people use original english message as alternative (which I haven't), ie:

'formlink' => array( 0, 'وصلة_النموذج', 'formlink' )

Isn't that redundant? Isn't English an alternative by default? And, is that all? Are SF messages and magic words and such independent of other extensions? Or must I translate something more in order to work?

Anyway, I am translating Semantic MediaWiki language dir too (and I am willing to do more) but I don't know whom should I tell about it. --Protnet (talk) 12:51, 16 December 2012 (UTC)

I actually don't know the answer to that first question - I guess you could try it and see. No, you don't need to translate anything more for it to work. And I don't know if there's an official person to send SMW magic-word translations to, but if you send them to mediawiki -at- kghoffmeyer.de, he'll definitely take care of it. Yaron Koren (talk) 15:21, 16 December 2012 (UTC)

Thanks! I'll send it there. As soon as the SF language files are updated I will test it and come back here with a report. --Protnet (talk) 16:40, 16 December 2012 (UTC)

Popup Forms: Problems with cancel and mandatory

when calling a form via formlink and popup, I have two problems:

• if fields marked as mandatory are empty when I hit "Save", the form shows the expected warning for a short moment and then dissapears. Any content of the form is saved regulary, the template vars of unfilled fields stay empty.
• if I hit "Cancel" on a popup form, some of the form fields loose their content, but the form stays visible

I searched for "semantic forms popup cancel" and such things, but didn't find an answer. Robertseetzen (talk) 18:52, 22 December 2012 (UTC)

Those both sound like bugs. Yaron Koren (talk) 16:47, 23 December 2012 (UTC)

Thanks for your answer, Yaron. I just tried it on a complete fresh MW/SMW/SF install to avoid any conflicts with other extensions and/or JavaScript. "Cancel" seems to work now, but the problem with "mandatory" still exists. Robertseetzen (talk) 10:34, 24 December 2012 (UTC)

Okay, that's good to know. By the way, what version of SF are you using? Yaron Koren (talk) 08:23, 25 December 2012 (UTC)

SF 2.5.1 on the fresh install and 2.4.2 on my production wiki. Sorry, I should have written that in my first question. Robertseetzen (talk) 09:02, 27 December 2012 (UTC)

Unique number: Can I use it in field tags

Hi Yaron, is there a way to use <unique number> in field tags? Like: {{{field|id|input type=number|default=<unique number>}}} Or, do you know other ways to generate unique numbers? Thanks in advance | Jaider ^Msg 19:51, 25 December 2012 (UTC)

No, I don't believe there's any way to display a unique number in a form field. I would suggest including the number in the page name - that's the only way of guaranteeing uniqueness, anyway. Yaron Koren (talk) 20:58, 25 December 2012 (UTC)

Ok, Thanks Yaron | Jaider ^Msg 21:22, 25 December 2012 (UTC)

Is listbox broken?

The listbox input type is defined to support list of enums, but I am only able to select one item. I've only been able to get the default of checkboxes to work, but for a large list they are rather unsightly and difficult to read. Currently using Semantic Forms v2.5.1.

Are you definitely seeing a listbox, as opposed to a dropdown? If so, you should definitely be able to select more than one. Try pressing "Shift" or "Ctrl" while you click. Yaron Koren (talk) 01:27, 31 December 2012 (UTC)

I'm getting a dropdown instead, but set size=5 to see if that had to be done. Maybe I'm not implementing it correctly. What I've done is declared a Property DLCList with Allows values and use that to provide the list. If I do the following:

{{field|dlc|list|property=DLCList}}

I get all of the values displayed as checkboxes. If I then add input type=listbox it reverts to a dropdown. Kodene (talk) 08:14, 3 January 2013 (UTC)

I have no idea. Is this problem viewable on a public wiki? If not, could you reproduce it on a public wiki, like http://scratchpad.referata.com? Yaron Koren (talk) 15:58, 3 January 2013 (UTC)

I just created a property, form, and template on referata, and the listbox works as expected (Property:DLCList, Form:DLC, Template:DLC). No idea why it won't work on our site (always reverts to dropdown). You can see a list of our extensions at Special:Version. Source for a form where I first tried to use a listbox can be seen here (contains multiple forms, and the one in particular is Template:ModAttributes with the fields dlcrequired and dlcsupported). Kodene (talk) 17:51, 3 January 2013 (UTC)

That's very strange - I have no idea. Yaron Koren (talk) 19:17, 3 January 2013 (UTC)

I have a development system to keep in sync, and doing a database export/import (and full directory copy) I have the same result where listbox doesn't work. I then did a fresh install of MediaWiki 1.20.2, installed all of the extensions, and imported an XML dump of the site. This time listbox works. So at this point, I'm guessing it's either a setting in LocalSettings.php, or something isn't right in the database (maybe caused at some point by the upgrades?). Kodene (talk) 21:00, 3 January 2013 (UTC)

Again, I have no idea. If you want, you can send me login details for your server, and I can try to diagnose the problem directly. Yaron Koren (talk) 22:24, 3 January 2013 (UTC)

Found the cause. We had $wgHtml5 = false; for some reason that causes a listbox type to display as a dropdown. Setting it to true and the listbox appears and functions as it should. Kodene (talk) 23:03, 3 January 2013 (UTC)

Good to know! I just added to the "Known bugs" section. Yaron Koren (talk) 23:22, 3 January 2013 (UTC)