Multi-lingual forms : language selection on screen not carried through system

  • Profile Image
    Asked on October 03, 2017 at 07:31 PM

    Just noticed the language selector, to display the form in any one of the allowed  languages for a given form, does not carry through the entire system.

    My forms' main language is French.  Users are allowed to display certain forms in English. Just about all fields do translate (except widgets which use iFrame). But  the translation module does not allow translation in eMails nor does it get applied for generated PDFs.

    If the user is allowed to change the language displayed on screen, that language should carry through all communications to that user... Thus, eMails should be in the selected display language. The JotForm form has everything needed on hand from the translation "table", which even includes translation of dropdown, choice and other such details.  This means even the "answers" could be translated on a generated PDF and eMail.  That would be incredible ... and expected. All JotForm needs to do is remember display language for each submission = add a 'system' field, like the IP address one. One could also ask for a "preferred communication language" as part of their multi-lingual forms.  JotForm's eMail / PDF generators could then use this value, if form creator so wishes.  Oh what a wonderful world that would be, eh ?

    It is a needed feature which would be over the top for true multi-lingual support by JotForm forms.

    Now, the work around previously suggested by JotForm Support to allow for full translation of any form, including the widgets which use iFrames, would be good here as well.  After all, the form would have just one language; each language is a separate form (!) to keep in sync.  That last bit becomes the problem, 2 forms (or more) to manage for each "form".

    Why bother having developped a translation module if it can't be used ?

    I thought of a (temporary) work around:  I have a field in the given form which asks the "spoken language at home". I could use it to change 2 email response, one email for each target languages.  One condition would not add the person's email = no email sent.  The other would add the person's eMail - email sent.  A eMail would be in French, the other in English.  Yeah !

    A catch, two in fact :

    1) the field values used in the eMail (PDF) are those of the form's language, not translated even if the translation tables HAS all the needed info to translate the fields' titles and content (unless free form text, obviously)...  After all, the eMail module does not know or ask for a language.  So even if I translate the "static" text, the values remain as stored by JotForm ("natural" form's language).   The fact the default email is built using the form's 'natural' language is also an issue unless the form generated a default email for each activated language ...

    2) the problem is worse. The value in question is actually part of a Configurable Field.  Those values, as tested to date, cannot be used to affect a condition !!  I suspect they could not be used, at this time, to affect anything else ...

    So I told myself : "Self, what don't you just turn on the print button ?!"  What a great idea.  "You must be a genius !"  The user of the form could at least PRINT the form BEFORE he/she submits it.

    Three catches here :

    1) they have to remember to click "Print" BEFORE clicking "Submit" - especially when they are displayed in the "wrong" order (submit is before print, at least on my forms.)

    2) most often it creates a multipage print out.  Afterall, the screen scrolls ... the paper doesn't.  My form, which used to be a two page paper form, beocmes 6+ pages !

    2) If there is any kind of CSS magic to place things just right on any size screen some of it incorrectly affects the placing of things on paper.  Even if paper could be just a static screen of a specific dimension ("letter", "legal", ...) it's controlled outside of JotForm - darned!  One can add CSS for the print media. ;(  Not a big big deal, short of being more work when creating forms.  Oh, the wonderful joys of Internet's capacity to be independent of the media used, eh ?

    But PRINT seems to be the closest to an immediat solution to the issue of eMail and PDF not being translated by JotForm given it has all the needed information

    I feel like I'm adding quite a few feature requests in last few hours just from a single "fancy" form. A form probably most would not tackle.  But Jotform does allow for all that fancyness.  It just falls short on a few aspects it can address, with time from the developers ...

    JotForm DOES allow for just about any web based form to be created.  Some, such as my forms, push those features to their current limits and need some tender loving CSS tweaking. I have not found an other service/solution which comes close to it, short of having to write everything from scratch !

    Did I mention that I love JotForm ?  I really do.  ;)

  • Profile Image
    Answered on October 03, 2017 at 09:53 PM

    Thank you for bringing this up to our attention, I have forwarded this to our development team. You will be notified via this thread about any updates on this matter.

  • Profile Image
    Answered on October 11, 2017 at 12:00 PM

    It would be nice of the development team would at least give a sign of life with these forwarded feature requests and such.  Even if just a three level response :

                 1- critical - trying to schedule asap

                 2- valuable - no timeline set, but added to list of things to be done

                 3- wishlist - probably will never be implemented given other priorities

    There could be a 4th level :

                 4- impossible - would require major rework / does not fit product roadmap

    Just a thought as we seem to be otherwise left with no news compared to JotForm's support fast responses to anything thrown at them... Even if the 'forwarded to development team' seems like an escape route (given the black hole feeling it leaves at our end).

    Is there some form of dashboard where I could see all of my requests - especially those pending a follow up from the "development team" ?

  • Profile Image
    Answered on October 11, 2017 at 01:12 PM

    Please note that feature request are taken based on the number of users requesting it, for example, if there is a potential number of users requesting the same feature then it will most likely applied; however, we cannot provide a time frame about when a feature can be implemented. 

    Regarding to your question about view your threads, it's possible to view all your opened threads, but there is not a way to filter which ones have been sent to the second level. You can see your opened threads here: 

  • Profile Image
    Answered on October 12, 2017 at 12:45 PM

    Fair enough. 

    However, without any indication of any kind of this "popularity" status, nor a hint of some of the feature requests made by others (like the top "25"), how are we to know if there is even hope for a feature request to ever see the light of day ?

    Once passed to the "development team", it is as if we released a balloon with our address hoping it lands somewhere, be found and someone actually bothers to get in touch to tell us about it.

    There must be some way at your end to show us at least where within the queue a feature request is idling ... 

    To be able to view the top X feature requests would be the cherry on top of the whipcream as it would allow at least some of us to vote the most interesting higher up the list.  There would be hope for some of us to see some feature requests make it to a future update.

    As it stands, all we know is that the request fell into a black hole never to be seen again ...

    Just a thought. 

  • Profile Image
    Answered on October 12, 2017 at 02:06 PM

    OK, in order to assist you better and forward this to our second level, I've moved it to a different thread, we will assist you as soon as possible here: