Extension talk:Page Forms

Extension:Translate and Semantic Forms
Hi, we would like to use the Extension:Translate to allow translations of pages created with forms. But we are having troubles and I would like to understand if Semantic Forms is compatible with this extension.

First, we can't insert the &lt;languages />&lt;translate>&lt;/translate> tags in templates in order to automatically embed the strings / value in field that will be translatable.

The only way to use Extension:Translate with Semantic Forms is to, once a page has been created thought the form, go to the edit page "&action=edit" and add manually the &lt;languages />&lt;translate>&lt;/translate> tags.

Then, we can't translate Property. Well, in fact it's possible to translate a Property page but when I go to a page that use a property and I switch language, system says that the translated words doesn't belong to the list of authorized values. For the system, only the original values (untranslated) are authorized.

Do you confirm that or is there a doc that I haven't seen? Thanks a lot. ClemFlip (talk) 13:38, 22 April 2016 (UTC)


 * I've never tried using Translate and Semantic Forms together, so there's not much I can contribute here. Maybe someone else reading this knows more. I will say that in part this is also a Semantic MediaWiki question; and more generally, it's an issue inherent to these extensions, in that none of them were designed to work on multi-lingual sites (that's part of why a new extension, Wikibase, was needed in order to power Wikidata). I do think that the handling needs to be different for fields that have a set list of allowed values, vs. those that can take in any sort of value. But I haven't really looked into any of it. Yaron Koren (talk) 19:02, 22 April 2016 (UTC)

Multiple instance forms for long tables
We are using a multiple instance template to add rows to a table. The table has 17 columns, so the form fails at around row 62 - assuming due to the php field input limit of 1000. This limit, along with the fact that loading time for the form get long after 20 or 30 multiple instances or so, suggests Semantic Forms may not work for this use case (managing large tables). We can't split information across multiple pages.

Could something like this work: a query-based display page (Cargo) that calls a single instance form for each row of the table, showing in a pop-up, so that each row is stored semantically as individual page in the background, but the person using the table never sees it. Maybe include a button/action in each row to "edit row", and another for "delete row". I think I can see how editing rows might work, I don't know about deleting them.

The goal obviously is a better UI for maintaining mediawiki tables. We can't use Visual Editor right now due to our custom skin. We would prefer to keep content stored in the wiki (as opposed to just pulling, say, Google Docs onto the page) so that we can use our draft/published control and permissions scheme (supplied by Ponydocs Extension).

Anyone have a magic solution we haven't thought of yet?

--Bgrenon (talk) 12:57, 13 April 2016 (UTC)


 * There's actually a new feature coming in SF 3.6 that might make the handling of large tables more doable - spreadsheet-style editing. 3.6 will hopefully get released in the next few weeks, so that might be worth trying out. On the other hand, I don't know how well it would display on the screen, with 17 columns. Unfortunately, there's no way to isolate a single instance of a multiple-instance template in a form. Why wouldn't the multiple-pages thing work? Yaron Koren (talk) 15:28, 13 April 2016 (UTC)

Undesired effects of query form on page title and section headers
Using a query form in a page started to have undesired effects after updating Semantic Forms.

I have a page Sandbox with the following code: = a = == aa == === aaa ===

The page title (first line in the page) is displayed as Spezial:RunQuery/QueryAuflage instead of Sandbox and the section headers are displayed as UNIQ70028b3423b19709-h-0--QINU a, UNIQ70028b3423b19709-h-1--QINU aa, and UNIQ70028b3423b19709-h-2--QINU aaa.

(MediaWiki 1.21.2, Semantic MediaWiki 1.8.0.4, Semantic Forms 3.6-alpha) LambdaB (talk) 12:58, 14 April 2016 (UTC)


 * Hi LambdaB, this is a known issue and one for which there is no fix I'm afraid. Best advice is to ensure that any embedded query form comes first in the page's syntax. You can sort of cheat around this though by using CSS to lower the embedded form. Cavila 19:03, 26 May 2016 (UTC)

Size in percentage for text input boxes?
This is admittedly a request, but would it be possible to make the size parameter for text input boxes to be a percent of the container rather than number of characters (or to have that option)?

The reason I ask is that I have such a pain trying to edit the CSS appropriately for these, especially if I'm trying to build multiple instance templates. Character numbers are quite difficult to work with for different browser window sizes or anything responsive. If I'm missing an easy trick, I'd love to hear that also of course.

Thanks for the consideration! --Joshkking (talk) 14:13, 16 April 2016 (UTC)


 * It would be nice if there were a way to do that directly, although you can instead use the "class=" parameter, and set the width in the CSS. Although maybe you knew about that one, given that you mentioned CSS. Have you tried this? If so, what's the difficulty? Yaron Koren (talk) 13:23, 17 April 2016 (UTC)

Multiple loading of SemanticForms Extension
During initial setup using index.php (when LocalSettings.php is absent), if you choose the SemanticForms extension, the setup will add two lines

The first line ```# wfLoadExtension( 'SemanticForms' );``` should not be included or it checks for certain things (version, flags, etc) that it should abort loading.

I encountered this issue

After I commented the first line, its work fine now.

Yoonghm (talk) 06:00, 17 April 2016 (UTC)


 * What setup process are you using? I didn't know there was a MediaWiki setup process that also added extensions. Yaron Koren (talk) 13:20, 17 April 2016 (UTC)

Enable links to forms
I followed the instructions of your example in the quick start guide exactly. This works great. After I altered the template as described in the 'enable links to forms' section, something strange occurs.

When you create a new book, the values of Genres are stored in the Authors field and those of Authors in Genres. Why is that?

--C Wagner (talk) 08:37, 18 April 2016 (UTC)


 * Where is the error - in the underlying wikitext, in the display of the page, or in the values stored by Semantic MediaWiki or Cargo? Yaron Koren (talk) 16:44, 18 April 2016 (UTC)


 * The error is visible in the wikitext, the display of the page and in the values stored by Semantic MediaWiki. C Wagner (talk) 14:16, 3 May 2016 (UTC)


 * Great - it sounds like the error is in the form. Could it be that, in the form, you have something like "Authors: ", i.e. the wrong labels for the fields? Yaron Koren (talk) 15:05, 3 May 2016 (UTC)


 * No that's not the case. In Form:Book there is "Authors: " C Wagner (talk) 10:48, 4 May 2016 (UTC)


 * Alright. Could it be that you just entered the data in the wrong fields when filling out the form? Yaron Koren (talk) 13:51, 4 May 2016 (UTC)

Error using datepicker
When I use the  input type, I get the following error:

Warning: OutputPage::getModuleStyles: style module should define its position explicitly: jquery.ui.datepicker ResourceLoaderFileModule [Called from OutputPage::getModuleStyles in /w/includes/OutputPage.php at line 623] in /w/includes/debug/MWDebug.php on line 300

Using:
 * MediaWiki: 1.26.2 (f465524)
 * PHP: 5.6.20 (cgi-fcgi)
 * Semantic Forms: 3.6-alpha (77c4a3b)

Jaider msg 18:31, 22 April 2016 (UTC)


 * Sorry for the long delay. This is due to a MediaWiki bug - I just added a note about it (including a fix) here. Yaron Koren (talk) 18:54, 28 April 2016 (UTC)
 * Thank you, Yaron. Do you know if there is an open bug report on Phabricator to follow up on this issue? Jaider msg 23:20, 2 May 2016 (UTC)


 * No idea. I actually don't even know if the error still shows up in MW 1.27 - I seem to remember that it doesn't, but I could be wrong about that. Yaron Koren (talk) 00:13, 3 May 2016 (UTC)

Spreadsheet mode with combobox
The new spreadsheet-style editing approach is really nice, but it's missing combobox support. Are you planning to add it?


 * It would be great to have autocompletion within the spreadsheet display, but I have no specific plans to add it. It would require custom JS programming - how much of it, I don't know. Yaron Koren (talk) 16:04, 18 May 2016 (UTC)

Force unnamed parameter for template?
Hi,

is there a way to force unnamed parameters to always be printed out? By the way I did not find any section for the  configuring variables. --Andreas P. 09:19, 24 May 2016 (UTC)


 * Do you mean print something like "1=ABC" instead of just "ABC"? I don't think so. The documentation for the $sfg global variables is scattered around in different sections - perhaps there should be one central list of them. Yaron Koren (talk) 14:39, 24 May 2016 (UTC)
 * "1=ABC" instead of just "ABC"? yes. With SF 3.4.1 there is the problem: adding an equal sign into the form field, e.g. "ABC=lorem ipsum" to an unnamed template parameter it does not transform to "|1=ABC=lorem ipsum" but to "|ABC=lorem ipsum", which distorts the template structure --Andreas P. Icon_External_Link_E-Mail.png 22:56, 24 May 2016 (UTC)


 * That's true. Why not just give the fields names, then? Yaron Koren (talk) 00:34, 25 May 2016 (UTC)
 * Well I guess I understand what you're pointing at, but I'd like the extension to take care of it to transform (always) to the unnamed parameter, e.g. "|1=lorem ipsum" --Andreas P. Icon_External_Link_E-Mail.png 08:27, 25 May 2016 (UTC)
 * That's a fair point; I guess the real solution is for the form to add the number if the value contains an equals sign? Yaron Koren (talk) 11:43, 25 May 2016 (UTC)

Autocomplete glitch
Thanks for the SF 3.6 release, Yaron and everyone else who made this possible. One thing I noticed is that autocomplete did not work properly on pages in a namespace other than the 'main' one - using textarea with autocomplete: the dropdown only shows me possible values when the namespace prefix has been entered. More specifically, it is just the first word of a value (after the prefix) for which this issue exists. Say, for instance, that there is a page called "Wiki:Cars for rent". No matching values are found if the user types "Cars", but things are okay if he/she types "Wiki:Cars" or "for" or "rent". I don't think I've seen this using SF 3.4. Cavila 18:57, 26 May 2016 (UTC)