_x_days_ago

I am at the latest revision on 7.1.  I am not seeing the ageing, instead I am seeing the key.  Any ideas on this one?

 I have the same error - But nothing so far has been done - just a comment that it is in Beta and deal with it. Maybe with two of us reporting it - something will get done about it.  The error is in the utils.inc.php file.  Just make sure you are using the 7.1 version of the file and not one of the latest SVN's.  

 Yes, I have updated files with the current reversions as they work on fixes.  So you are saying that the 7.1_B1 version should be used instead of the version in the SVN?

You were correct, replacing utils.inc.php fixed the problem.  So a ticket needs to be issued on this.

 RE

 You can't create a ticket for a problem that theoretically doesn't exist yet

http://www.boonex.com/forums/topic/Time-Stamp-error-in-timeline-.htm

The link AlexT pointed out should explain it. But i will mention this for those that do not understand.

You cannot just blindly update your sites files with updated ones from the SVN. Some of those updates may require database changes as well which will not be applied by simply copying files. Thats why there is a update process.

 YES - it does exist. And I'm sure it will get fixed.

 
Not really. The problem is created when using a updated copy of utils.inc.php without applying the database changes that went with the ticket on that update. So technically this bug is self inflicted and does not actually exist. Caused by improper update procedures.

Thanks for the explanation.  No, it is not a bug at all.

Now, it would really be nice if the whole ageing thing was dropped.  I don't know about other social applications such as Oxwall, I don't think it was in Elgg when I was testing it; in fact I am sure of it, but ageing should go and be replaced with date; which I did on 7.0.9 and will do as well for 7.1.  It is stupid, yes, stupid, to put ageing instead of the date.  So someone is reading an old post and it said it was posted, 1739 days ago; when in hades was that?  Do you expect your members to pull out their calculators?  It is a simple fix of course since PHP has a built in function to convert a time stamp to a date.

The same goes for Boonex's forum, I have no idea when a forum post was made because it tells me some cryptic days ago and I would have to calculate when.

So what changes do I need to make to the database?  I am not complete familiar with the complete database structure although I am examining the current 7.1 sql file.

Well, one could create a ticket but it would be rather difficult to fix a problem that does not exist. LOL.  I was lead to believe that an update broke this; it is not unheard of such a thing happening when correcting a problem.  I am not a complete idiot, only a half idiot.

They are language keys. Those new keys will be added by the installer or the updater on the next version. Or you can add the language keys manually. Refer to this change log for a list of the keys. The red keys are to be removed and the green ones added.

http://www.boonex.com/trac/dolphin/changeset/17183

EDIT:
But also keep in mind that doing so may cause errors when you do go to update to B2 when it is available because the updater will expect those keys to not be there and may trigger a error when trying to add them. So do so at your own risk.

So it appears that Changeset 17183 has to do with Russian language?  Is Russian language some part of the core system?  I don't care about Russian language so explain this to me if you have time.

The change set has changes for the English language file as well.

The format was changed to allow for better translation to other languages.

But there are indeed changes to the English language set as well.

 RE:

 Exactly.  For a while, I was updating one site from svn ever few days.  Once I saw an sql file in an svn build, I stopped.  It's more trouble than it's worth at that point.

Besides, the ticket system here is all about official releases.  You couldn't enter a ticket on a specific svn build if you wanted to.

 RE:

The way this is supposed to work, is Boonex releases B1.   We test and report problems with B1.  Boonex fixes problems with B1 and releases a new version sometime later. Boonex calls this version B2.  Repeat process.

Reporting problems with an unofficial release that you got from svn, doesn't really fit into this process, and doing so, may have the unwanted effect of slowing down development, if boonex coders start looking at every reported "bug" with every svn build.

 Deano thanks just got it right! Thanks again!