What is your idea about?
TYPO3 pages and content can be translated nicely. When it comes to multilingual forms, the editor has to take an unattractive detour. At the moment, the editor has to create a copy of the form for each of the different localizations. In a second step, the editor has to translate the form. This results in considerable additional work, and additional adjustments/ extensions have to be made manually in all language versions - which is in turn prone to errors.
It would be better to stick to the localization workflow of the “Page” module.Similar to pages, it should be possible to create localizations for each form in the “Form” module. It should also be possible to choose between “Connected” and “Free” mode and to change this later on.
If at least one localization already exists for a form, the drop down for selecting the language variant of the form to be edited is displayed above the toolbar. If there are languages for which no localization of the form has been created yet, the editor can create a new localization via a drop down below the form title.In “Free Mode” the form is taken over with all configurations of the source language and is freely editable afterwards, with all configuration possibilities.In “Connected Mode” this is partially possible, with the restriction that form elements cannot be moved, deleted or added. Also finishers and validators cannot be added or deleted. Values that have already been set in the source language are mapped below the fields, analogous to localized page content. Form elements can be hidden by toggle switches within a localization.Within the form manager it is possible to display all localizations, delete them and open the form directly within the editor.
What is the potential impact of your idea?
Our solution will enable editors to quickly and easily translate a form into new language versions. Editors can use the workflow and controls they are used to in TYPO3. The clarity of the form module listing is maintained. The management of forms for different languages is possible centrally in the “Form” module and does not require any further adjustments to the plugin on localized pages. This wonderful UI will solve the biggest problem editors reported during the last years.
Who can / should implement your idea?
I will take care myself
thank you for your application. In our call for applications we asked for specific ideas to grow the membership of the TYPO3 Association. Can you please explain how you application can help to grow the number of members?
The goal of the TYPO3 Association is to reduce the amount of money spend on worktime for code. Instead the money should be used to enable people to be part of teams or to enlarge the community. Can you please explain why we should -in your special case- money for code should be spend?
Why should companies and individuals be members of the TYPO3 Association unless we have a great product that is worth supporting?
We saw last year how we catapulted the TYPO3 project forward by diverting money to get problems actually solved.
And being prepared for easy translation handling is one of the big advantages TYPO3 has over other CMS.
The now falling numbers of association members I can also see in a kind of frustration that there had been only few differences between TYPO3 9 and 10 and the project was kind of stuck. Now we are moving forward and divide money to the projects where actual work is done!
@ischmittis to be honest, I didn’t know that. Sure, I have read Call for Budget Application Ideas—Association Budget 2022 and was very happy to hand in some budget applications for our biggest pain points we have learnt as the form initiative. Together with Lina, we created two additional proposals for documentation which will help to grow the acceptance of the product and thus grow the community. And I am with Lina when it comes to this feature.
At the moment, I am frustrated to read those lines:
As infrastructure and development are already covered, we are solely interested in innovative ideas to foster and grow the TYPO3 community and number of TYPO3 Association members.
Why? A couple of weeks ago, we had another core sprint. I asked at least 5 people of the TYPO3 community which are deeply involved in the ecosystem. None of them was able to tell me anything about development budgets. In the end, someone gave me approval to hand in our sprint expanses. But the reimbursement of 20 € was declined. We decided to not get any further into this and canceled the reimbursement.
At the moment, I do not see anything covered or communicated when it comes to core development. All I see is people not being sure who is responsible and how to get things paid and therefore done.
This is no rant. I am an enthusiastic member of the TYPO3 ecosystem, love the community and the product. But one thing is sure: as a paying gold member of the community since ages I want to know which features will be developed and I want to be part of the development roadmap. Since I listen to our users and hear their frustration about certain missing features and quirky implementations, I want to change the situation. To not only add new members to the community but keep existing members on board.
As we both know: the whole discussion is kind of weird. If you do not want to invest in development, my application is not worth the effort. It will not add new members to the community. And it will be hard to measure how many people stayed as a member. I am kinda lost now. I do not understand how our product is financed, who decides what will be development and in which direction the product is moving to.
Hi! Interesting discussion here…
in short: I’m with Lina and Björn. To invest in development to get an even better product, reduces the pain and motivates the members. So why shouldn’t there be a budget for this?
