When is IPB 4.0 ?

[Rikki]

I'm playing devil's advocate here because I'm not a developer, but if this is so why are some developers getting stressed if this information has been made available to them? Are ALL developers included or only selected developers?

More curious than anything lol.

:rofl:

Any with the "Contributor" badge have access to the forum, chats etc.

[DustinRyan]

My only issue with IPB 4 is the announcement was too early. Skin sales are significantly lower this year and the most popular response I get from customers is that they were waiting for IPB 4. And with every blog post, they think it's just around the corner, when it's clearly not, because such complex software takes time. But the average person doesn't know that.

The announcement of IPB 4 on the way convinced a lot of people that it was coming soon, and have held off on buying new fancy stuff for their forum, out of fears that they would waste their money if IPB 4 was coming a few short weeks or months later (not knowing that there's no way it would).

So while I'm excited for IPB 4, I'm just a little disappointed (financially) about the timing of the announcement of IPB 4 last year. It's definitely made people more conservative with their purchases.

[nylyon]

My only issue with IPB 4 is the announcement was too early. Skin sales are significantly lower this year and the most popular response I get from customers is that they were waiting for IPB 4. And with every blog post, they think it's just around the corner, when it's clearly not, because such complex software takes time. But the average person doesn't know that.

As a forum owner I can say this is an accurate statement. I have been holding off on any potential updates to the forum because of 4.0. To me it doesn't matter when 4.0 is released to the owners like myself, but when it gets released to the skinners and developers who will need to update their products, which I hope they do.

Even if 4.0 is released tomorrow.... (is it?) it will be months before I'll be able to upgrade because of the 3rd party dependency and skinners, that many of us need or want to have. My biggest concern isn't 4.0, but the developer support for the add-on's which are in use as well as the skins.

So in the mean time, I'm not buying extras because I am unsure if they'll be required in 4.0, or if they'll be updated in 4.0.

[Jake Sully]

when IPB 4.0 is out will existing license work on IPB 4.0 as well or do we all have to re-order to get new type of key?

[jair101]

We understand that this will mean that translators will need to start again which is why we're keen to give contributors early access to beta releases so they can make a start on there IPS 4 code.

Do you consider releasing the language files to everyone in advance? Many translators are not contributors (me for example) and we will appreaciate if we can start this time consuming task as early as possible.

[Hexsplosions]

when IPB 4.0 is out will existing license work on IPB 4.0 as well or do we all have to re-order to get new type of key?

You will not need to re-order. This isn't the vB fail-train. :smile:

You simply need to have an active licence.

[Jake Sully]

You will not need to re-order. This isn't the vB fail-train. :smile:

You simply need to have an active licence.

Okay just wanted to make sure :) since i would be suprised if IPB decides all of sudden require every users who has a license to upgrade it to new one to get 4.0 but luckely that wont happen :)

[Midnight Modding]

Well, it really goes back to the points made in some other threads where bottom line is I wish I had higher renewal costs because it';s going to be a ton of work. And some areas I would badly like to redo from scratch (unrelated to ip.board, just my own functions) are so complicated I would never try to redo them any time soon as it's taken me probably 12 hours just to test one feature and it's the craziest function anyone here has ever seen, I guarantee, because I had to do some hilariously crazy things with numbers in it. A for loop where the start and finish numbers vary depending on many circumstances, two numbers which change in totally different ways each time, and just really crazy arrays of numbers. I would badly like to simplify it, but I just fixed enough bugs as it is.

As far as ip.board, though, I always knew we would have to change a lot. But lang bits is not one I thought would change from simply importing from an xml file! I thought maybe there would be new info each word needed added in, but not redoing it all from scratch.

[Clover13]

Well this whole re-write from the ground up sounds great but also concerning, especially given that the re-usability and portability of existing 3.4.x code will be minimal (or nil).

Can you give us some insight into the IP.Content side of things?

I do recall IPS mentioning that there will be some level of migration from IP.Content based development in 3.4.x to IPS4. Is that still the case?

Or is the expectation that everything must be re-written (or would be easier to rewrite vs trying to port)?

Is there no automation around the upgrade process to port 3.4.x IPC developed code/modules to IPS4?

I think details around the IP.Content direction and portability will certainly allow many of us to make a better decision on whether to code around 3.4.x versus waiting for IPS4, at least those of us that can afford to wait. Personally I'll be pretty disappointed if I spend a ton of hours developing custom code around 3.4.x in IP Content that is a complete throwaway for IPS4. I can deal with the loss/rewrite of what I have now, but not with the loss I will have if I continue development over the next 6-12 months only to have to do it all over again (to run on IPS4).

[PrettyPixels]

I have exactly the same questions and situation as Clover13. Is there any information you (IPS) can offer to address these concerns?

[Neil2]

Well actually there are technical reasons we cannot convert existing language strings over. You shouldn't make such broad statements without any knowledge of what you're speaking to. You make it sound like we just decided, on a whim, to not do something.

Midnight Modding has a legitimate statement and concern, and if you did not ask input from the clients then this huge modification sounds like it was done on a whim.

Many owners have customized their web-sites to make their sites feel more at home, fit their function or theme, and not a generic script forum software and now you have verified that all owners here who have changed the language strings just threw their time spent out the window, because that time and effort does not mean anything

This entire 4.0 has been blown out of proportion, but now that IPB 4.0 is being completely reconstructed what had the most influence on that decision facebook, twitter, or client input?

[Clover13]

Honestly, regardless of the influence for it...IMHO IPS4 could benefit with some revisions from the previous version and it sounds like they are on a good track for their development.

It also sounds like IPS has identified better ways with LESS code to manage the intermingled products and allow for better code management for developers (again with LESS code).

That's just the nature of development over the span of time. You write code the way you think best fits the current technology and trends, and over time both of those aspects evolve, as does your learning/thought process via trial and error, customer feedback, etc. From everything I've read, IPS has identified better ways to develop their product line and are doing that "from the ground up" in it's entirety. I've done that myself in other markets, and sometimes it's needed, and with it comes great benefits. And it is no small undertaking, so I commend IPS for taking that direction. They could have just as easily pulled a Microsoft and re-wrapped their existing code/platform to make it look different. They chose the hard way and re-wrote the entire thing!

My hope is that much of IPS4 will be more responsive in it's design (sounds like it will be) and a more isolated/discrete code/call platform (heavily AJAX/API based to allow for better resource utilization, code isolation and decoupled page design elements) versus the "full page" refresh model that exists in 3.4.x. Regarding the latter case, I do not know if that is part of the design, but it's another aspect that I'd love a yes/no on from IPS as it's a consideration on whether I drive for external custom development that I will then retrofit into IPS4 down the road. I can develop those "widgets" now (I actually have in certain small components) and integrate them later, but if there is tooling in IPS4 that already accommodates this type of development (in respect to full page/site management), it may be better to wait for it and benefit from it's coupling with the IPS4 platform versus trying to "fit" it in or "code around" it later.

[THL]

Can't wait for the fresh release of IPB4.0 , come on, its been an age!! (w00t)

[Rimi]

why are some developers getting stressed if this information has been made available to them?

Because they can't handle it.

[Joel R]

1. Can't wait to see some more blog posts -- especially posts about using Community Suite 4.0 from the user's perspective

2. Can't wait to see something totally innovative and mind-blowing -- past blog posts show content that's 'nice' but not 'whoa.'

3. Can't wait to see how IPB has shifted away from a "forum-centric" orientation into a "social and community" orientation

[Midnight Modding]

Because they can't handle it.

Being able to "handle it" has nothing to do with anything. I could ask everyone to give me $500 because I want to buy something and if they say no, I can just say they can't handle it. :)

[Rimi]

Being able to "handle it" has nothing to do with anything. I could ask everyone to give me $500 because I want to buy something and if they say no, I can just say they can't handle it. :)

That made absolutely no sense at all. xD

[Midnight Modding]

If someone doesn't "like" to work on something for 1,000 hours for no pay, it means they're sane, not that they can't handle it if they so choose. But I'm done. A few people see points on various sides, and then others want to be insulting and I have things to do.

[Davyc]

We mostly all accept that change is inevitable in many aspects of life, none more so than technology; which seems to be evolving at a far greater rate than we are as a species. People are, generally, adverse to change unless that element of change is 'seen' to be beneficial to them. Once people can see that a particular change is good for them, they more readily accept it. What drives that acceptance away is 'not knowing' and 'not knowing' has a habit of inventing problems that don't really exist, or may not be as terrible as believed.

The only way I can see forward with this change with the coming of IPS 4.0.0 is for a more consistent stream of information as to what the major changes involve and how they are going to affect those with existing forums that have, as has been pointed out, heavily customised. We've already been told that add-ons and skins developed for the 3.x.x model will not work in 4.0.0 but what we haven't been told are the listed functions that have been included in 4.0.0 that may negate the need for certain add-ons; if, indeed, that is the case.

Although it's unlikely that 4.0.0 may not follow the self-destructive route of vBulletin in terms of flawed coding that generated huge problems for it's clients, IPS may find that 4.0.0 will not be so readily accepted because of the complications it presents in incompatibility with it's previous model that may cause huge problems for their clients.

Admittedly it's a bold move, an innovative move and undoubtedly a huge technological move in terms of what we have been used to; but even in technology their has to be a friendly warm organic element to attract people. So far we haven't seen that element and have been dished up the cold stark vision of efficiency. My personal opinion (for what it's worth) is that it's time to start showing what the end user experience is going to be like.

:thumbsup:

[Midnight Modding]

I'm sure most ip.board changes will work out well.

[teraßyte]

IPS 4 is a completely new product that has been rewritten from the ground up. There is very little code used from the IPB 3.x codebase.

All the interfaces have changed, so while there may be some common strings such as "post", "forums" and so on, the actual form labelling has changed dramatically.

The new IPS 4 framework has "helpers" for forms and tables, and these "helpers" require the language keys to be in a specific format so they are automatically used.

We've put a lot of focus on labelling to make sure its consistent, so we almost always use positive phrasing "Enable this feature" whereas IPB 3 used mostly negative phrasing "Disable this feature" and so on.

IPS 4 is a new product that shares only its DNA with IPB 3.x. This means that existing mods, themes, languages and so on are not compatible in any way.

We understand that this will mean that translators will need to start again which is why we're keen to give contributors early access to beta releases so they can make a start on there IPS 4 code.

Midnight Modding has a legitimate statement and concern, and if you did not ask input from the clients then this huge modification sounds like it was done on a whim.

Many owners have customized their web-sites to make their sites feel more at home, fit their function or theme, and not a generic script forum software and now you have verified that all owners here who have changed the language strings just threw their time spent out the window, because that time and effort does not mean anything

This entire 4.0 has been blown out of proportion, but now that IPB 4.0 is being completely reconstructed what had the most influence on that decision facebook, twitter, or client input?

Matt's post above clearly says why the language packs cannot be easily imported from 3.x to 4.x, it wasn't done on a whim. Spending time in writing queries or a script that renames each language key to the new one would take a huge amount of time for a really minimal benefit, honestly it's not worth the time for me and I prefer they spend such time polishing up 4.0 itself.

In 3.x every language string is pretty much "random" without a specific format for the keys, plus when a new feature got added the option in the ACP was sometimes "enable XXX" and sometimes "disable XXX". The fact that they made everything more consistent will be good for everyone in the long run.

[bfarber]

jair101 asked if we can release the language files early. While we theoretically could release the .php language files we utilize, it would be pointless.

1. You don't have any context to know what the strings are being used for. "post" can mean a lot of different things in different languages. In English alone (at least in forum software) it could be a verb, a noun or an adjective. Just seeing random strings in a language file isn't enough.
2. You will need to translate via the ACP (or via helper tools the ACP provides) in order to export your language pack and to allow the strings to version properly.

Unfortunately just having a dump of strings in a file isn't enough to allow you to properly translate, and even if you did you would then later have to find the same strings in the ACP and copy over your translations anyways.

Clover13 asked about a better API-driving system. The backend is much more API-driven and we will be providing an API delivery mechanism (similar to our existing XML-RPC API but more robust and better, and not in XML-RPC format which confuses most people). Additionally, yes many areas are AJAX ready. Our output handler inherently understands if the request is AJAX or not and simply outputs the resulting HTML from the request without a wrapper automatically if so. So requesting a topic view page via AJAX would return the entire topic view page but without a wrapper. Same with any other page, including forms (which makes putting forms in dialogs or modals, or on full pages, equally as easy depending upon the desired workflow).

[Soniceffect]

Matt's post above clearly says why the language packs cannot be easily imported from 3.x to 4.x, it wasn't done on a whim. Spending time in writing queries or a script that renames each language key to the new one would take a huge amount of time for a really minimal benefit, honestly it's not worth the time for me and I prefer they spend such time polishing up 4.0 itself.

In 3.x every language string is pretty much "random" without a specific format for the keys, plus when a new feature got added the option in the ACP was sometimes "enable XXX" and sometimes "disable XXX". The fact that they made everything more consistent will be good for everyone in the long run.

Couldnt have said it better myself

[jair101]

jair101 asked if we can release the language files early. While we theoretically could release the .php language files we utilize, it would be pointless.

1. You don't have any context to know what the strings are being used for. "post" can mean a lot of different things in different languages. In English alone (at least in forum software) it could be a verb, a noun or an adjective. Just seeing random strings in a language file isn't enough.
2. You will need to translate via the ACP (or via helper tools the ACP provides) in order to export your language pack and to allow the strings to version properly.

Unfortunately just having a dump of strings in a file isn't enough to allow you to properly translate, and even if you did you would then later have to find the same strings in the ACP and copy over your translations anyways.

Well, thats exactly how we translate till now, thats good that you agree it is terrible :P

I read the internationalization blog post and it is much needed changes, especially the Visual Language Editor. Thats why I am not annoyed about redoing the work as big changes were needed and big changes more often than not mean starting from 0, like IPS4. Still, as I said, many translators are not contributors so it would be nice if there is a way to get early access too. I suppose I can try to release some BBCODE that noone but me uses just to get contributor status, but that feels like cheating to me.

[We are Borg]

jair101 asked if we can release the language files early. While we theoretically could release the .php language files we utilize, it would be pointless.

1. You don't have any context to know what the strings are being used for. "post" can mean a lot of different things in different languages. In English alone (at least in forum software) it could be a verb, a noun or an adjective. Just seeing random strings in a language file isn't enough.
2. You will need to translate via the ACP (or via helper tools the ACP provides) in order to export your language pack and to allow the strings to version properly.

Unfortunately just having a dump of strings in a file isn't enough to allow you to properly translate, and even if you did you would then later have to find the same strings in the ACP and copy over your translations anyways.

Clover13 asked about a better API-driving system. The backend is much more API-driven and we will be providing an API delivery mechanism (similar to our existing XML-RPC API but more robust and better, and not in XML-RPC format which confuses most people). Additionally, yes many areas are AJAX ready. Our output handler inherently understands if the request is AJAX or not and simply outputs the resulting HTML from the request without a wrapper automatically if so. So requesting a topic view page via AJAX would return the entire topic view page but without a wrapper. Same with any other page, including forms (which makes putting forms in dialogs or modals, or on full pages, equally as easy depending upon the desired workflow).

Well you are right translating with out knowing where the text is used is meaningless. What would translators benefit greatly is where text is used so you know in what file or template the text is being called from that why its easier to know where the text is being used.