Outlook on the future of WoltLab Community Framework 2.2

  • In the past few months we've extensively evaluated the future of Community Framework and agreed on a list of changes and improvements that will take place. Despite its utter importance for all our products, it always had to take a step back and work in the background, revealing itself only through the administration control panel.


    We decided that it is finally the framework's time to shine and launched the project "Lantia": Embedding an entire CMS directly into the core, eventually granting users the ability to build their entire website without the need of poorly integrating 3rd party applications for instance having issues with shared logins, layouts barely in sync and other differences harming the user experience.



    CMS


    Creating pages will take place using Redactor's full HTML mode without the limitations of bbcodes. Each page can be built completely from the ground up or using a placeholder-powered template. This does not only allow less experienced users to create and maintain appealing and complex pages (e.g. woltlab.com), but also allows for more advanced scenarios such as nested pages (e.g. a documentation).


    Pages allow for a whole range of customization options starting with simple meta tags up until full URL customization. Following our tradition all pages can be optionally set to be available in different languages, with each version being independently configurable. Pages are backed with a box-like system similar to the already known dashboard-box-system, easily creating reusable and complex content, and an exhaustive media management system.



    Styles


    Great CMS are not only defined by their ability to easily manage content but also their overall flexibility when it comes to visual customization. People often tend to see the visual appearance as some sort of eye candy, but this completely misses the point of having visual guidance and recognition through unique designs. Given this background we have to make a whole bunch of changes to the entire style system and the HTML source to provide these abilities, eventually sacrificing backward compatibility wherever necessary, despite this will render most styles incompatible or at least requiring some work to get them running again.


    We consider this to be an opportunity to tackle and resolve certain short-comings of the current style system. The style editor will undergo a huge overhaul process to push the limits of visual customization and typography even further, ultimately easing the creation of unique and appealing styles as well as adding a proper and reliable update mechanism for styles.



    Future Development


    Upcoming changes and additions will be announced much earlier and more frequently, granting a better insight into the evolution of our products. Community Framework 2.2 and Burning Board 4.2 will be released together.

  • What led to the decision to integrate the CMS directly into the core rather than releasing a standalone product?


    Having the CMS integrated tightly into the core opens up a lot more possibilities and greatly improves the development process of other components of our software products. The dashboard is a great example, right now it is build with a completely different mechanic known as dashboard boxes, looking closer it becomes obvious that this is in fact nothing else but a custom CMS page heavily utilizing the planned box system. More possible use-cases include the imprint and privacy policy, especially the later offers little to no editing capabilities besides editing the used phrases directly - which isn't really designed for working with large chunks of text. Opting-in to build these using the CMS allows us to make use of the CMS functionality, eventually leading to an easier maintenance of these pages for the end-user without requiring us to reinvent the wheel.



    Progress is fine, but why sacrifice compatibility with current styles?


    During development of the 2.1 versions for both calendar and gallery it became obvious to us that we're in need of a more flexible style system, especially to cover more complex scenarios. Considering the level of complexity required to build a versatile CMS, we realized that the current style system won't make the cut unless we want to burden the system with countless additional features that are barely reusable and massively increase the amount of code that we need to maintain, always at the edge of conflicting with legacy code parts. This is even more the case when considering the enormous improvements that have taken place in all major browsers and most significantly CSS3, providing us with easy and maintainable solutions for common cases with little effort. Besides the technical aspect, a CMS should allow for 3-column layouts which is simply not possible with the current layout without hurting backward compatibility and/or risking serve issues with existing plugins and styles.



    Can I run the CMS completely standalone?


    Yes, version 2.2 of WCF will introduce all required components to present a frontend without the need of any installed application.



    Does WoltLab Community Framework (WCF) remain free and open-source?


    Absolutely yes.



    Is there a release schedule for version 2.2?


    The release is estimated to take place in the second half of 2016, but please understand that we cannot provide a fixed date at this point.

  • Sounds promising, just hope it's not overly complex to create pages from backend like some of those CMS software out there (based off of wbb wcf etc). I guess with 2.2/4.2 I wouldn't need my two page plugins either lol.

  • Hi @Marcel Werk,


    The developers want more documentation (very necessary), but I have to ask more facilities to work in translations. I said in many times: woltlab is not very friendly with translators. I have to compare with external software every en.xml files when you publish the updates to check the changes and maintain my translation updated. Is not more simple, usefull and friendly share en.xml and de.xml files on Github to check changes in every update?


    In the past I asked to Woltlab access to the software to translate your products to Spanish. I only received the en.xml files. Translate from english to spanish without a context and checking every phrase is very complicated. I helped to other developers to translate their software to Spanish without problems (for example @Smooey plugins). But Woltlab is very frustrating for me. I have abandoned frustrated my translation many time.


    Translations are a volunteer job that helps to expand your product around the world. Translators should be important in the community and have a support from Woltlab.


  • %100 True. WoltLab must take a decision to support translators here in the forum in order to have a perfect translation. Of course if you want to be World wide community and not for Germany or some countries.

  • %100 True. WoltLab must take a decision to support translators here in the forum in order to have a perfect translation. Of course if you want to be World wide community and not for Germany or some countries.

    Woltlab used to have a small team of volunteer translators years ago - I used to be one of them. This was back when wBB2 was being developed, and they've since moved on. Personally, I think that the discussion about translations between the team members was invaluable in creating solid translations. It also provided a lot more natural translation when the people doing the translations were native speakers. A lot of the (English) translations that I've seen don't flow well, and at times seem awkward/unnatural. I think this could be improved. Since I imagine it would be costly to employ translators, especially in the multitude of languages that the software has potential for use in, volunteers seems like a good option from my view.


    I do recall, in the past, that when some customers found that volunteers were used for translations they were less than pleased. They were using the software for business purposes, and they wanted to receive a professionally developed product. It was almost as if they felt that volunteer translators degraded the work, or provided a lesser quality product. I disagree, but to each their own. Woltlab has to give their customers what they desire in order to be profitable, so it may take a lot of convincing if they are to even consider going back in that direction.

  • They were using the software for business purposes, and they wanted to receive a professionally developed product. It was almost as if they felt that volunteer translators degraded the work, or provided a lesser quality product.

    From what you are saying, it sounds like they wanted the cake and eat it too, which I believe made those volunteers such as yourself feel like their work wasn't worth the hassle.


    I am aware that WoltLab is still a relatively small company, and I can understand if they didn't want to hire professional translators because of the price. I think that for the time being, translating wbb into several languages would be trying to put too many eggs in one basket. The current English translation is acceptable, but not great considering that it still shows odd/awkward wording here and there. I do believe that Burning Board should focus on providing an excellent English translation to begin with, which is what makes a product reach broader audiences nowadays -- for instance, the potentially lucrative American market that I believe WoltLab is trying to win.


    It is my personal opinion that for the moment trying to include volunteer-based translations in various languages would be dispersive, since as I mentioned above, the focus should primarily be on improving the current English pack. I know for a fact that several potential customers across the ocean (and who speak English either as both first or second language) are often put off by the odd and unconventional wording the current English translation displays.


    Translations in other languages could come later on, and possibly tasked to professional translators.

  • I think is not necessary have professional translators. Many projects use collaborative translation tools, and the results are good. In my opinion the important is create a good community to support the project. I don't know the Woltlab balances, but I think it's a small company. The price of their products is fair, and I don't have any problem to colaborate translating to Spanish.


    About a Spanish translation...


    I sent an email to Woltlab and they provided me access to their products (Thanks!). I'm going to share my translation on Github to try to do a collaborative translation (I have permission to share on github all xml files and for use a free licence). I am Spanish native but I also have some technical questions (I don't know translate all terms and is not necessary translate all words). I think with colaborative translations is possible do good translations: asking and learning from other users.


    Maybe is a good idea move all posts about translations to a new thread in General Discussion section? I think is a good discussion thread, but not related with this topic. (cc @Alexander Ebert)

  • From what you are saying, it sounds like they wanted the cake and eat it too, which I believe made those volunteers such as yourself feel like their work wasn't worth the hassle.
    I am aware that WoltLab is still a relatively small company, and I can understand if they didn't want to hire professional translators because of the price. I think that for the time being, translating wbb into several languages would be trying to put too many eggs in one basket. The current English translation is acceptable, but not great considering that it still shows odd/awkward wording here and there. I do believe that Burning Board should focus on providing an excellent English translation to begin with, which is what makes a product reach broader audiences nowadays -- for instance, the potentially lucrative American market that I believe WoltLab is trying to win.


    It is my personal opinion that for the moment trying to include volunteer-based translations in various languages would be dispersive, since as I mentioned above, the focus should primarily be on improving the current English pack. I know for a fact that several potential customers across the ocean (and who speak English either as both first or second language) are often put off by the odd and unconventional wording the current English translation displays.


    Translations in other languages could come later on, and possibly tasked to professional translators.

    It was a wonderful experience for me to work with Woltlab as a company and the other volunteers. I would do it again. :) Since it was on a volunteer basis there was no hassle for me, and like I said I quite enjoyed the experience & opportunity. They treated us with great respect. :thumbsup: I also know they appreciated our efforts. I have no hesitation in saying that Woltlab is a great company, and I hope I didn't give a different impression to anyone with my previous post. I guess I see both sides of the spectrum (business & consumer). The German community is something else, and I hope one day the English one will be more similar. It's such a great software & system!

  • The German community is something else, and I hope one day the English one will be more similar. It's such a great software & system!

    On that we agree. And that is why I believe that the primary focus should be having an excellent English translation. Of course, if volunteer-based translations in other languages turn out to be decent, it's all for the better. Yet, nowadays it's the English language that makes the product more accessible and user-friendly on wider, global scale, at least now that an increasingly number of English-speaking audience is discovering WBB, and that's where the focus should be for the time being. But that's just my opinion, of course.