Have something to say?

Tell us how we could make the product more useful to you.

First Class i18n Support - Multiple Language Support for a Single Form

So it would be great for single forms to be able to have multiple translation variations. Probably the cleanest way would be using i18n strings. Ideally we'd be able to specify the language tags ourselves, as it can be different per implementation e.g. en-US, en-UK, pt-PT, pt-BR etc. which is the ISO standard afaik. But some prefer to use e.g. just 'en' for US english, 'br' for Brazilian Portuguese. You could potentially make use of this: https://github.com/txty-io/texterify It has transitioned from a BSL to Apache v2 license. I've used their managed solution for years and it's been great. There is also inlang/opral: https://github.com/opral/monorepo/tree/main/inlang I only use paraglide from inlang/opral and it's quite nice for the front end, but not sure about their string management solution as I have not tried that. We'd need to be able to send the language tag to the form, particularly for embedded ones, to ensure it's possible to make sure the correct language can be loaded matching the currently used language on the site it is embedded on. Could perhaps have a json file that is downloadable for the primary language as well as uploading the translated versions. Could also potentially allow editing the strings inside the web panel and machine translations also. E.g. opnform.com/forms/uuid/en-US could use the en-US.json file, opnform.com/forms/uuid/pt-BR could use the pt-BR.json file etc. This would also allow using languages that aren't officially supported yet also, so we could provide our own translations for all form fields, success/error messages etc. Alternatively, it could be limited to languages officially supported. In that case, the translations would only need to cover the user modified parts. Just ideally would still use a url structure like above so it follows standards and all user cases could be covered.

form_enthusiast 3 days ago

2

πŸ’‘ Feature Request

Completed

Removed Fields - Fully Remove & Exclude from Duplicates + Improved Editing of Submissions

So I noticed that in the submissions section, it retains and displays previously saved fields that have since been deleted. This makes sense for a live form that already has submissions, for safety, ensuring info isn’t removed. That said, when I duplicate a form, which excludes all submissions, I don’t think it should include the removed fields. I created a template form and did a bunch of testing, but now, if I clone it, the other forms will always keep the removed fields as an option to display on the submissions page - despite no data now, or in the future, that will use those fields. It would be nice if this was excluded from duplicated forms and also for it to be possible to clean them out of existing forms (and accept that any submissions that used those fields, will lose data saved in those fields). Also, if a removed field is enabled to be visible on the submissions page, if you click the edit button - those fields will not be visible to edit. It would be useful to have this, in order to move data from the previous fields to the new fields and empty out the old fields. Also, to update the records, if you have a captcha on your form, it requires solving a captcha to edit each individual record (so that should also be removed).

form_enthusiast 6 days ago

2

πŸ’‘ Feature Request

Completed

Duplicate Form - Randomise Field IDs & URL

When duplicating a form, I think it would be better if the field ids were randomised as a safe default. Right now they use identical uuids. The url also uses the previous url and adds a suffix, though it’s easy to regenerate the url. Changing the field ids is a bit more tedious, cloning every individual field, removing the originals, renaming to remove β€˜copy of β€˜ and remaking any logic. So it would be nice if the field uuids were automatically randomised when cloned. Currently, with identical field ids, this means if forms are cloned between brands, workspaces etc. the form field ids can be used to definitively link forms together as having a common origin/owner/agency etc. Which is not ideal for privacy.

form_enthusiast 7 days ago

3

πŸ’‘ Feature Request

Need separate Time field in addition to Date field

I would like to suggest an addition of a separate Time field alongside the existing Date field. Rationale: While users currently have the option to fill out date and time in a single field, many service booking scenarios only require a start time after selecting a date. A separate Time field would improve user experience by providing a more intuitive and streamlined interface. This would align with common practices found on other booking sites, where the date is often prefilled and users can select time from a dropdown (ideally with possibility to restrict from-to). This change could ultimately reduce user errors and make the booking process more efficient. Improved User Experience: By providing a dedicated Time field, users can quickly select a time for their appointment or event without having to navigate a combined Date-Time picker. This segmentation simplifies the process and reduces potential confusion. Users who only need to specify a start time without reference to an end time will find separate fields more intuitive. Thank you for considering this enhancement!

Peter Kizik About 1 month ago

1

πŸ’‘ Feature Request